From nobody Tue Feb 1 02:59:32 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1453A2188; Tue, 1 Feb 2022 02:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_HELO_TEMPERROR=0.01, 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 zBEV9nf9g1av; Tue, 1 Feb 2022 02:59:23 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2103.outbound.protection.outlook.com [40.107.236.103]) (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 1F1403A2184; Tue, 1 Feb 2022 02:59:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I5/X+Ck6VTs1gn+k8ih0VEaNEQaGensp6zN0g24JQYzANjDSDnwK7JZnp8nBCG65nZw4tiUs4ELrB11yP6URDFm0M2loNy3gmmQxDpqRHws0ll+sn7ublIIW+cdwlBQ/9AM1agBI07RQUtAgtXInZS6d0W0afONV7OiyzOXHjY9skt6pOO6/9F47obYNlto7igXWUkU50WzNTSnBHZAtocxlgWI6gpw4sr+jabS+Qh+9gHemwAxdJ6cA+Chk31w+Y+HV2XYWFWbKhoOdu2Y7MRxR43XwyTdlF701GoVOwiFfXDOdcVqcGXHt+7K+wJ6fJAE1fWjwnkwPXVoYIpqmXA== 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=B0w/gtyyYEujxeZBLwgQAH8TGdyVc6yjVXMmXawnxT8=; b=WYb+844ijZTg2H8+M8EFcoX9PQ+ln3lryZ6pvp833cH5jq0b2SZiQ2DayuNZQF2LPo79Gq7gV2MX03R3OsJTCtoIGFwVYGkADzgnCZzYaED8IPON6ui7CRuRxjWKmfE5zQ+7nmSI1nealFzXlWIvEMFeKz/sdqB+W24glXmOVzw51HDhHOHd/ju1C0Ktw6oqY9p0yMSaRV8kgmLM4LSakXqIgnY6Z7tVdDIEjtsI3ibnoSsL33kzqU5metomCnjv1q6Q8B6iC0/exhBRT0sDFGq77M1sviU/6VFzjO46K9akl265LfBHCEWex668FFDQyo9C7sS41MOKX/IjjP4VgA== 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=B0w/gtyyYEujxeZBLwgQAH8TGdyVc6yjVXMmXawnxT8=; b=EqrS1PmPk78GN3ROiARS+JYiZxzORm6KcQllkhI3jWfT5jmRyL4tjMfJ9N8FNI5PaaWW0HipSp89Leki15erH77LlJmSRcBNPwsALGA9xdryP8FE2ixbb5H03E+JS60G/SgzCSZ6P8xXNw5ef6MSdJ2xdzYXuteGY86LhdS4PQk= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by BN6PR13MB3012.namprd13.prod.outlook.com (2603:10b6:405:7a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Tue, 1 Feb 2022 10:59:20 +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.4951.011; Tue, 1 Feb 2022 10:59:20 +0000 From: James Guichard To: Shwetha Bhandari , Greg Mirsky CC: "draft-ietf-sfc-ioam-nsh@ietf.org" , "sfc@ietf.org" , "sfc-chairs@ietf.org" Thread-Topic: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ Thread-Index: AdeULBhJRJPqyAEIQoSKEyRZsxugZSC95BWLAArMKUA= Date: Tue, 1 Feb 2022 10:59:19 +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: 44e14f8d-4c81-433c-76b4-08d9e571e5f1 x-ms-traffictypediagnostic: BN6PR13MB3012: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: 4Bd1aj2qicr029BvQNEUMgmh3nDWUbplzvrliHsNzirGqyyDrfQEVj+lkOv1xg6E9AlXo5nHbGWRFAjS7x6+sb6lTJaoN3FmWhB9s/6MK0xqqj9VPyRaBj38ER67SsPvnJSVzggynWNTN8ty0f4B14+52y94y2EBZwej8kPxHP44eXhdERoFdWZb1kc2codUHO0X87eNlhmA91NMfHGu4mHGPqF1otVyJjOGlF94mTd0wOLvaAIum6RePX++WYE9JWcc69dGB/l0h1/XqUmmzllbWCkHL1OqksUFi08t5g0GGmxIBWVIvrIIfIKdquNACR0WQwLEzpGXZZmitiBRnc0BKPBowa609LOr0RM/zlkjm82GtkYtTW1qXEPHJByFC4/4+jCRUL3qDWXGP3cKkGDqtYdI9iEj9B4U+lSUGYGJCd6PD9YkB6s8B0i9p5AZ+aM7xWkIVq6LdwPjoEWsPEbN9g1Ec7dUjsBbqdvkFFCRkunO/UjpII/VH+4urhBLy/Svfy51G75oUKz/Uxi53Wik4AwcId4yY9lRCKbbpgnMot56d+z14D0VOnmEQz5338layPWZn5qcWJJ5OtlNSHZx2VkCvgGoCuTaiX0Rt27hhvvJshv/kiNNtt6Wl+rmDJXtOnRam3awoWh6CpmRFIb45C/WRvsBsRnrVYqx1ZbCBqO4KvOSD7Vjny/9pWE5Lyk+aX/AjAqZH+wEDTbQKaDTf6UPTNhVmcX5V85ULdBtD3UVh3WPk7l2WwoEklJRAH8IO8n9g5l3b1V2okH59YzatOK5CfKDgd2evNT8rMsModPDDV8iDOJPaAEnbblToBR2LGe4riC0OZhTVjukow== 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)(166002)(38070700005)(966005)(83380400001)(316002)(110136005)(55016003)(122000001)(38100700002)(186003)(54906003)(33656002)(30864003)(9686003)(66476007)(8936002)(5660300002)(66446008)(66556008)(64756008)(8676002)(76116006)(66946007)(4326008)(2906002)(71200400001)(508600001)(6506007)(7696005)(52536014)(86362001)(53546011)(579004)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Auw4b6wMCqbBJhz23UqoPO1NzkomsmAljbqBOmrexOuyUC2OFiFIlJl2VduF?= =?us-ascii?Q?/9FDnVhndBxuCQbFemkrWrPOazveqaHNSv7DjP7UYkiILM6ycZhM0wnr9Pfh?= =?us-ascii?Q?xAC3a/5g8ImRiHhyuWYmJc+5AVOxGG9GX/qWnwnhFM1VcxvK+jPC4bVVHqqh?= =?us-ascii?Q?2mXiuCIuJImCZk4lZ4f++FjJvXPUL3ok1PJDJqMVsRMrM/KSbRadDUuSToaY?= =?us-ascii?Q?4OAwAp3N3s1UzgGSxlpTPkjfNB/RWWOr8VmRLzbF6R+TiqXl1FYpN85v+fP5?= =?us-ascii?Q?8UXe2GRmVXH0W74iBP+hVgVklVQFQvdVw3PKslTxxOS+qP6yVZQsRF5kw2Yv?= =?us-ascii?Q?jgy35LzkMUpMnJhUO8QRY4HJ3hGMI3djdNLus71HkaKNNUGIBN9ZBcL/nQrp?= =?us-ascii?Q?y3iSuXWDxTSaoaOzpLNAV7QsgfC078TJXn2CLd8X9xRlTePWcRVksZztbK5W?= =?us-ascii?Q?vd3WzygN+5pniMVWXeIEE6mpQrMWJfIofFb1ohhRJ8z8S5NFMnsPWzGiJksp?= =?us-ascii?Q?/uhbJNJZr+epBZVJuI/co/7g5lQ3LaWVb7Nd8OxlzzkIHwmKyvM+fXPFIQ7+?= =?us-ascii?Q?iNuwpF4YsU9wsQqXdZPsS0i7JMKdg5nLOI7uqemJJdhk0q9vnlI1vQv68QQ3?= =?us-ascii?Q?raq5kjJFCF9Ht6N8arh7ujtjDt1w+bfoRABmEAMz6TPdh+9cjVGGzkDkFACq?= =?us-ascii?Q?DBGDMw9WmpHztOAcqTcFcIkmMQnrUtbCyrpJjXvm6o7PhK+UePGkLw9SxqVz?= =?us-ascii?Q?UutoYyzuK1ftEokWQM/sRY1h6spiFjBNVR42qzepF44vuPGgQstnSKp3I690?= =?us-ascii?Q?Cwzb6eR5HcZk6xyaMzMsT1C3A5KzbWUV5LkeprJzVD3EM1ErbxUqUlBMKF9b?= =?us-ascii?Q?GVTVuFkSAXVWnD4zI2x4FtSVHXdIg063LUOthsHCznDpE9jJiuolIr0taita?= =?us-ascii?Q?xKhYk3pTj36nFigkbXna1bOyfxTNkspKS9xxyqVZGftrFn6R3QDgN7HLbDwX?= =?us-ascii?Q?nKbmEjjNpqPgF+XOOLJxNm7mbmeW8kyXUfG1OoJJz1OsNQa7JEhzPfmpwrIV?= =?us-ascii?Q?7aW0Bu6WTsUTDLu2g9c40EBIDftDvnETtN4CfwXdtJqpAeQQHDnvaJOwu2bL?= =?us-ascii?Q?WolXJYviPLvaifB2Ibe9QemDQJAh5neRl40AN8o1bgRpCO2kIV5rgtod8e9E?= =?us-ascii?Q?j1WhGURdC07JmyT4M6guVY6va937qnGRLADq/Lyfgig5tDOG5DiH/3/qEWEk?= =?us-ascii?Q?mRJMIg+WGKeiU85P/zthvmnKPKpyoKLSHHfMFKbbx6eVCpQmHtomzXqIPFi5?= =?us-ascii?Q?4DYdSfcc11yuUw6Ruq3c53MwOcI7HnqNAOvM4zikcxInQsftvdJM1GEhAEpL?= =?us-ascii?Q?g1IaF4vUwauqEDyJsI4v61DLs5p15YGJSJRCYV9V0PIDlIehF9Ttp9R1oAwT?= =?us-ascii?Q?COcFaZXU0hSCXuJUhhKenwapTmbYT0v3K5p2nEeBfj6mAFDlQsvD0nesXNmr?= =?us-ascii?Q?t0Ljtx2MsIsuWhSSxgQYhznxzeSEqvopTgJ4aVTUriIYEDOzTd0Vy+gPflKO?= =?us-ascii?Q?l7EkV+AsPitGBd7Uui75RFW1TsC/snKNDtHo6T5J5EmSQtS9X3ouEXtkSf2t?= =?us-ascii?Q?c/a3YfIY69xvMdHM//yHX5b8iPJ5g1t/5np9O5rrBnnA8zOLi3yfIGuBMCPG?= =?us-ascii?Q?kGydQr0jrDnAHPHh8+h1jnouOu0=3D?= Content-Type: multipart/alternative; boundary="_000_MN2PR13MB42066C22CA66B0E1F0FC3FFFD2269MN2PR13MB4206namp_" 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: 44e14f8d-4c81-433c-76b4-08d9e571e5f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2022 10:59:19.9789 (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: lyji+n/zcJXtka3E2Z//s8+2f6C6lgSN2lTIuTqeenjM7YVdmoJRz29baeAEIJt52A+O3iAg9Dto2NDOVrS9tA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR13MB3012 Archived-At: Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 10:59:31 -0000 --_000_MN2PR13MB42066C22CA66B0E1F0FC3FFFD2269MN2PR13MB4206namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shwetha & Greg, Thank you for the update. I still believe however that more work is necessary to reconcile how SFC OA= M is supposed to work. RFC 8300 says: O bit: Setting this bit indicates an OAM packet (see [RFC6291]). The actual format and processing of SFC OAM packets is outside the scope of this specification (for example, see [SFC-OAM-FRAMEWORK] for one approach). The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM packets. If we look at RFC6291 it simply describes what OAM is supposed to mean and = this is independent from SFC. The SFC-OAM-Framework (now RFC 8924) in secti= on 6.3 says: The Next Protocol field in the NSH header may be used to indicate what O= AM function is intended or what toolset is used. Any other overlay encapsulations used at the s= ervice layer must have a similar way to indicate the intended OAM function. So my reading of this is that if you take 8300 together with the framework = then 1. The O-bit MUST be set for OAM packets, and 2. The Next Protocol fie= ld may or may not be used to indicate which OAM function is to be applied. = >From this I can determine that iOAM has taken the approach of using the nex= t protocol field to indicate how to process the OAM packet and does NOT use= the NSH context headers in any way shape or form. This seems consistent wi= th the current definitions of the O-bit from RFC 8300 and processing guidel= ines from RFC 8924. However, your document says: 4.1. IOAM and the use of the NSH O-bit [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300] the O bit must be set for OAM packets and must not be set for non-OAM packets. Packets with IOAM data included MUST follow this definition, i.e. the O bit MUST NOT be set for regular customer traffic which also carries IOAM data and the O bit MUST be set for OAM packets which carry only IOAM data without any regular data payload. This text basically says that if the packet is customer traffic and happens= to carry iOAM data then it is NOT an OAM packet. What am I missing, custo= mer traffic or not, both carry iOAM data so how are they different within a= n SFC domain? In addition to the above I will note that there is still a conflict with Gr= eg's draft namely this text from section 4: * O bit set and the "Next Protocol" value does not match the value Active SFC OAM (TBA1), defined in Section 10.1: - An SFC NSH Context Header(s) contain an OAM processing instructions or data. - The "Next Protocol" field determines the type of the payload. The above text suggests to me that if the O-bit is set and the next protoco= l is not active SFC OAM then it is *required* that OAM data will be in the = NSH context headers (which is not the case for iOAM) and the next protocol = will indicate what follows the NSH header. While iOAM does follow the NSH h= eader as indicated by the next protocol there is still an expectation that = OAM is also carried in the NSH context headers. This seems to be in conflic= t with RFC 8300 AND RFC 8924. This of course is just my reading of the text and I would like to hear your= s and other folks thoughts. Jim From: Shwetha Bhandari Sent: Monday, January 31, 2022 11:25 PM To: Greg Mirsky Cc: James Guichard ; draft-ietf-sfc-ioam-ns= h@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc= -ioam-nsh/ Hi Greg, Sorry for the late action on this. https://datatracker.ietf.org/doc/html/dr= aft-ietf-sfc-ioam-nsh-07 has been now posted with the edits per this discuss= ion. Hi Jim, After Greg's review please let us know if the changes are good to progress = the draft to the next step. Thanks, Shwetha On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky > wrote: Hi Shwetha, thank you for the detailed response to my comments. Please feel free to sha= re any updates you're considering for the next version. I'll be glad to wor= k together on these. I have several follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari > wrote: Hi Greg, Sorry for the very late reply. Please find responses to your comments inlin= e @Shwetha: On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky > wrote: Dear Authors and All, I've read the current version of the draft and have some comments I'd like = to share with you. I much appreciate your thoughts on where this work shoul= d go considering developments in other IETF WGs. Please find my notes and q= uestions below: * It is stated in the Abstract that: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. But that is the case only for the pre-allocated and incremental trace optio= n types. The Direct Export option does not write telemetry data into the data packet it= self but export telemetry information in a specially constructed packet. And as we are talking about different IOAM trace options, the question of t= he scope of this document seems appropriate. There is a WGLC on two IOAM do= cuments active through September 15th at the IPPM WG. I believe that it would be= beneficial if we had a single document that describes the applicability of= IOAM in all its functionality defined by documents in IPPM WG. Of course, = that cannot be a moving target as that would not be helpful. But since the = IPPM WG discusses the progress of two IOAM documents, it could be a great t= ime to address the applicability of the Direct Export trace type and Loopback and Activ= e flags defined in draft-ietf-ippm-ioam-flags. It would be concerning to have more than one SFC= document describing the applicability of the generic IOAM mechanisms Shwetha> This is a fair point. We will revise the draft with text in the a= bstract and Section 3 IOAM-Type to be updated to include the usage of trace= and DEX options. The encapsulation of IOAM options within NSH itself in i= ts current form already supports all the IOAM Option Type defined both from= draft-ietf-ippm-ioam-data and draft-ietf-ippm-ioam-direct-export along wit= h the flags supported within the options. Hence the IOAM-data-field definit= ions in the draft will remain unchanged. GIM>> I agree that the definitions of the IOAM data-fields are invariant in= various data plane encapsulations. You likely follow the discussion of the= IAOM Direct Export and IOAM flags on the IPPM WG list. I think that for SF= C NSH, IOAM Direct Export could be as simple as "use the local policy". The= applicability of the Loopback and Active flags seems to require detailed e= xplanation by SFP actors. * The location of the IOAM header in the SFC NSH-encapsulated packet is= defined in Section 3: IOAM-Data-Fields are carried in NSH using a next protocol header which follows the NSH MD context headers. I've checked RFC 8300 but couldn't find it defines the Next Protocol header= . Also, it appears that NSH Context headers are optional. Hence my question= . Is the presence of an NSH Context header required when using IOAM? Could = you clarify which mechanism is used to identify the payload of an SFC NSH-e= ncapsulated packet as IOAM? Shwetha> We will reword it, it is not Next Protocol header but using IOAM a= s a Next Protocol as described in Section 4.1 and requested in IANA section= . Following is the proposed text to align with the RFC 8300 reference to co= ntext headers following base header and service path header: "The NSH is defined in [RFC8300]. IOAM-Data-Fields are carried in NSH usin= g a next protocol to identify IOAM data fields that follows NSH context hea= ders." GIM>> I think that RFC 8300 views data following Context Headers as NSH pay= load, not being "in NSH". * If I understand the format of the IOAM header defined in Section 3 co= rrectly, the header's length is limited by 1020 octets, while the effective= length containing IOAM options and data - 1016 octets. Is that correct? Wh= at is the recommended technique of collecting IOAM data that exceeds that l= imit? Shwetha > IOAM options inherently support specifying the size limits at the= node that added the IOAM options. While operationalizing the solution the = data types included and number of nodes expected to be adding the data shou= ld be selected. This is covered in deployment considerations draft-brockner= s-opsawg-ioam-deployment. * In Section 4.1, I've found the text reflecting the history of the dis= cussion about how to carry the IOAM header using NSH encapsulation. As the = text has no normative value, I suggest moving it into an Appendix. Shwetha > Agreed, revised draft will have this section moved to Appendix. GIM>> Thank you. * I find the rules of handling the O-bit in NSH listed in Section 4.2 i= nconsistent and confusing. The IOAM header is not part of NSH encapsulation= but is a part of the payload. But in one case, when user data follows it, = the O-bit must not be set as. If there's no user data after the IOAM header= , then the O-bit must be set. But from the perspective of NSH encapsulation= , it includes specially constructed data added for the sole purpose of coll= ecting OAM/telemetry information. Then, why, in one case, the O-bit is clea= red and in the other set if, in both cases, the NSH-encapsulated packet is = used to perform the OAM function? Shwetha > The reason for not setting the O-bit for packets that contains ac= tual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier implem= entations that do not support SFC OAM procedures SHOULD discard packets with O bit set". It will be= undesirable to discard packets with O-bit set that carry user data as IOAM= can be inserted insitu. For synthetic traffic created for OAM along with IOAM-data-fields in NSH fo= llowing the NSH OAM function with 0-bit set is desirable. GIM>> This is an interesting situation. I agree that there could be an SFC= element not supporting "SFC OAM procedures" (not clear what these are). By= the same token, would such SFC element support IOAM, be capable of process= ing IOAM without adverse impact to user data? I am not certain and it seems= that it might be better to recommend that NSH packets with IOAM be dropped= by an SFP element if it does not support "SFC OAM". What are your thoughts= ? Thanks, Shwetha I much appreciate your consideration of my comments and questions and looki= ng forward to your feedback. Regards, Greg On Wed, Aug 18, 2021 at 5:32 AM James Guichard > wrote: Dear WG: This email starts a 2 week Working Group Last Call for draft-ietf-sfc-ioam-= nsh [1]. Please read this document if you haven't read the most recent version and s= end your comments to the SFC WG list no later than September 1st 2021. If you are raising a point which you expect will be specifically debated on= the mailing list, consider using a specific email/thread for this point. Lastly, if you are an author or contributor please response to indicate whe= ther you know of any undisclosed IPR related to this document. Thanks! Jim & Joel [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_MN2PR13MB42066C22CA66B0E1F0FC3FFFD2269MN2PR13MB4206namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shwetha & Greg,

 

Thank you for the update.

 

I still believe however that more work is necessary = to reconcile how SFC OAM is supposed to work. RFC 8300 says:

 

   O bit:  Setting this bit ind= icates an OAM packet (see [RFC6291]= ).

      The actual form= at and processing of SFC OAM packets is outside the

      scope of this s= pecification (for example, see [SFC-OAM-FRAMEWORK]

      for one approac= h).

 

      The O bit MUST = be set for OAM packets and MUST NOT be set for

      non-OAM packets= .

 

If we look at RFC6291 it simply describes what OAM i= s supposed to mean and this is independent from SFC. The SFC-OAM-Framework = (now RFC 8924) in section 6.3 says:

 

   The Next Protocol field in the NS= H header may be used to indicate what OAM function is intended

   or what toolset is used.  An= y other overlay encapsulations used at the service layer must have a

   similar way to indicate the = intended OAM function.

 

So my reading of this is that if you take 8300 toget= her with the framework then 1. The O-bit MUST be set for OAM packets, and 2= . The Next Protocol field may or may not be used to indicate which OAM func= tion is to be applied. From this I can determine that iOAM has taken the approach of using the next protocol = field to indicate how to process the OAM packet and does NOT use the NSH co= ntext headers in any way shape or form. This seems consistent with the curr= ent definitions of the O-bit from RFC 8300 and processing guidelines from RFC 8924.

 

However, your document says:

 

4.1.  IOAM and the u= se of the NSH O-bit

 

   [RFC8300] defines an "O bit&= quot; for OAM packets.  Per [RFC8300= ] the O

   bit must be set for OAM packets a= nd must not be set for non-OAM

   packets.  Packets with IOAM = data included MUST follow this

   definition, i.e. the O bit MUST N= OT be set for regular customer

   traffic which also carries IOAM d= ata and the O bit MUST be set for

   OAM packets which carry only IOAM= data without any regular data

   payload.

 

This text basically says that if the packet is custo= mer traffic and happens to carry iOAM data then it is NOT an OAM packet. &n= bsp;What am I missing, customer traffic or not, both carry iOAM data so how= are they different within an SFC domain?

 

In addition to the above I will note that there is s= till a conflict with Greg’s draft namely this text from section 4:

   *  O bit set and the "N= ext Protocol" value does not match the value

      Active SFC OAM = (TBA1), defined in Section 10.1:

 

       &nbs= p; - An SFC NSH Context Header(s) contain an OAM processing

       &nbs= p; instructions or data.

 

       &nbs= p; - The "Next Protocol" field determines the type of the payload= .

 

The above text suggests to me that if the O-bit is s= et and the next protocol is not active SFC OAM then it is *required*= that OAM data will be in the NSH context headers (which is not the case fo= r iOAM) and the next protocol will indicate what follows the NSH header. While iOAM does follow the NSH heade= r as indicated by the next protocol there is still an expectation that OAM = is also carried in the NSH context headers. This seems to be in conflict wi= th RFC 8300 AND RFC 8924.

 

This of course is just my reading of the text and I = would like to hear yours and other folks thoughts.

 

Jim

 

From: Shwetha Bhandari <shwetha.bhandari@t= houghtspot.com>
Sent: Monday, January 31, 2022 11:25 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: James Guichard <james.n.guichard@futurewei.com>; draft-iet= f-sfc-ioam-nsh@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-i= etf-sfc-ioam-nsh/

 

Hi Greg,

 

Sorry for the late action on this. https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 has be= en now posted with the edits per this discussion. 

 

Hi Jim,

 

After Greg's review please let us know if the change= s are good to progress the draft to the next step.

 

Thanks,

Shwetha

 

On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Shwetha,

thank you for the detailed response to my comments. = Please feel free to share any updates you're considering for the next versi= on. I'll be glad to work together on these.

I have several follow-up notes in-lined below under = the GIM>> tag.

 

Regards,

Greg

 

On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari <= ;shwe= tha.bhandari@thoughtspot.com> wrote:

= Hi Greg,

 

= Sorry for the very late reply. Please find responses to your comments inlin= e @Shwetha:

 

 

 

On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <gregimirsky@gmail.com= > wrote:

Dear Authors and All,

I've read the current version of the draft and have = some comments I'd like to share with you. I much appreciate your thoughts o= n where this work should go considering developments in other IETF WGs. Ple= ase find my notes and questions below:

  • It is stated in the Abstract that:

   In-situ Operations, Administration, and= Maintenance (IOAM) records
   operational and telemetry information in the packet while the = packet
   traverses a path between two points in the network.=

But that is the case only for the pre-allocated and = incremental trace option types. The Direct Export option does not write telemetry data into the data p= acket itself but export telemetry information in a specially constructed pa= cket. 

And as we are talking about different IOAM trace opt= ions, the question of the scope of this document seems appropriate. Th= ere is a WGLC on two IOAM documents active through September 15th at the IPPM = WG. I believe that it would be beneficial if we had a single document that = describes the applicability of IOAM in all its functionality defined by doc= uments in IPPM WG. Of course, that cannot be a moving target as that would not be helpful. But since the IPPM= WG discusses the progress of two IOAM documents, it could be a great time = to address the applicability of the Direct Export trace type and Loopback and Active flags defined in&n= bsp;draft-ietf-ippm-ioam-flags. It would be concerning to have more than one SFC document describing the a= pplicability of the generic IOAM mechanisms

 

= Shwetha> This is a fair point. We will revise the  draft with text = in the abstract and Section 3 IOAM-Type to be updated to include the usage of trace and DEX options.  The encapsulation of IOAM options within NSH = itself in its current form already supports all the IOAM Option Type define= d both from draft-ietf-ippm-= ioam-data and draft-ietf-ippm-ioam-direct-export along with the flags supported within the options. Hence the IOAM-data-fie= ld definitions in the draft will remain unchanged. <= /p>

GIM>> I agree that the definitions of the IOAM= data-fields are invariant in various data plane encapsulations. You likely= follow the discussion of the IAOM Direct Export and IOAM flags on the IPPM= WG list. I think that for SFC NSH, IOAM Direct Export could be as simple as "use the local policy". The = applicability of the Loopback and Active flags seems to require detailed ex= planation by SFP actors.

 

 

  • The location of the IOAM header in the SFC NSH-encapsulated packet is = defined in Section 3:

   IOAM-Data-Fields are carried in NSH

   using a next protocol header which foll= ows the NSH MD context

   headers.

I've checked RFC 8300 but couldn't find it defines t= he Next Protocol header. Also, it appears that NSH Context headers are= optional. Hence my question. Is the presence of an NSH Context header requ= ired when using IOAM? Could you clarify which mechanism is used to identify the payload of an SFC NSH-encapsulated= packet as IOAM?

= Shwetha> We will reword it, it is not Next Protocol header but using IOA= M as a Next Protocol as described in Section 4.1 and requested in IANA sect= ion. Following is the proposed text to align with the RFC 8300 reference to context headers following base header and servic= e path header:

= "The NSH is defined in [RFC8300].  IOAM-Data-Fields are carried i= n NSH using a next protocol to identify IOAM data fields that follows = NSH context headers."

GIM>> I think that RFC 8300 views data followi= ng Context Headers as NSH payload, not being "in NSH". =

  • If I understand the format of the IOAM header defined in Section 3 correctl= y, the header's length is limited by 1020 octets, while the effective lengt= h containing IOAM options and data - 1016 octets. Is that correct? What is = the recommended technique of collecting IOAM data that exceeds that limit?

= Shwetha > IOAM options inherently support specifying the size limits at = the node that added the IOAM options. While operationalizing the solution t= he data types included and number of nodes expected to be adding the data should be selected. This is covered in deployment co= nsiderations draft-brockners-opsawg-ioam-deployment.=

  • In Section 4.1, I've found the text reflecting the history of the discussio= n about how to carry the IOAM header using NSH encapsulation. As the text h= as no normative value, I suggest moving it into an Appendix.

= Shwetha > Agreed, revised draft will have this section moved to Appendix= . 

GIM>> Thank you. 

  • I find the rules of handling the O-bit in NSH listed in Section 4.2 inconsi= stent and confusing. The IOAM header is not part of NSH encapsulation but i= s a part of the payload. But in one case, when user data follows it, the O-= bit must not be set as. If there's no user data after the IOAM header, then the O-bit must be set. But from t= he perspective of NSH encapsulation, it includes specially constructed data= added for the sole purpose of collecting OAM/telemetry information. Then, = why, in one case, the O-bit is cleared and in the other set if, in both cases, the NSH-encapsulated packet is use= d to perform the OAM function?

= Shwetha > The reason for not setting the O-bit for packets that contains= actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier implementations that do not support

  &n=
bsp;   SFC OAM procedures SHOULD discard packets with O bit set&q=
uot;. It will be undesirable to discard packets with O-bit set that carry u=
ser data as IOAM can be inserted insitu.
For synthetic =
traffic created for OAM along with IOAM-data-fields in NSH following the NS=
H OAM function with 0-bit set is desirable. 

 GIM>> This is an interesting situation. = I agree that there could be an SFC element not supporting "SFC OAM pro= cedures" (not clear what these are). By the same token, would such SFC= element support IOAM, be capable of processing IOAM without adverse impact to user data? I am not certain and it seems that it might b= e better to recommend that NSH packets with IOAM be dropped by an SFP eleme= nt if it does not support "SFC OAM". What are your thoughts?=

 

 

= Thanks,

= Shwetha 

I much appreciate your consideration of my comments = and questions and looking forward to your feedback.

 

Regards,

Greg

 

On Wed, Aug 18, 2021 at 5:32 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

Dear WG:

 

This email starts a 2 week Working Group Last Call for draft-ietf-= sfc-ioam-nsh [1].

 

Please read this document if you haven’t read the most recen= t version and send your comments to the SFC WG list no later than September= 1st 2021.

 

If you are raising a point which you= expect will be specifically debated on the mailing list, consider using a = specific email/thread for this point.

 

Lastly, if you are an author or cont= ributor please response to indicate whether you know of any undisclosed IPR= related to this document.

 

Thanks!

 

Jim & Joel

 

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

 

 

 

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

--_000_MN2PR13MB42066C22CA66B0E1F0FC3FFFD2269MN2PR13MB4206namp_-- From nobody Tue Feb 1 13:57:20 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB6D3A1192; Tue, 1 Feb 2022 13:57: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, 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 ou2t9lbQ427e; Tue, 1 Feb 2022 13:57:13 -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 93C3C3A11A7; Tue, 1 Feb 2022 13:57:12 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id h7so58613704ejf.1; Tue, 01 Feb 2022 13:57:12 -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=eG7pB7F0CViYelJajSMkUrW/UHHpG6jID+w4o4ACcHA=; b=B3+O1iUK5baBLcixqJvEhLjVEuyzVRdZYURF4KJRX21youUHcjze133by5LQInnZwY urETOT5JDi1OYK+kMUNJtuddE5zt1tLvLYQPwrwSHfvb/NAfwS1OQQ6qDh8w2IQUbF06 UMNH/tY87xtYJAxU1lUr3uMpSTKEBDcOKI3ui6ekqcn5vbkfZ6pGrax1Gi16GKYFrOyC ByC2YEfrEfo7nJy+LVOLUVAyFKlHgNAbtc8Cxfw+1lHG6QBEssNC28usB+ek5XWao2hn A0JcP/c3iFI0/fkbrUTSU/lCi/FYJRwog3pyvmrJJPhaex/Lqoo5zBK3p+w96BSzrB+z pNYw== 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=eG7pB7F0CViYelJajSMkUrW/UHHpG6jID+w4o4ACcHA=; b=kRMexMOFOaaz1Bx0NArmc3aANbB6vh5QLqW4/NjwMIbp3a0ohNWJ1CA2GwYWRB9sZl YTSJfDwTLNhKAqwHiFSu9IM7uvqDMf70CWdMbCnscyTgZtS9aEol2fg09EEWmrTGpX4A xRfWi/Y6tR6NR04ljAo45MsgKXv3tFTcocWDJO/hL2LR368pyZsQcx4eV0a6WK3xK/W4 I87y5Q/6CYASxImyqaWNviRs5PMTnrzjsRxciM5bJSO7p4r2wvjp1K/4LZDV3wp6SHyb dEjMEu7Xc8748Q6+YPlsfZo1bnNSn9bstOTsyALFKtXvNSdT00bboWZj6QNU+NL/tP3N YuaA== X-Gm-Message-State: AOAM5319Qw55wLQlmELYCAdJEXhPpZSGiQuiY//DcLXbcr+z4ijrOvTv ZQK+S/x5n8DCrC79m67ftd//SnKyNphNdKIbtda57DNo0XE= X-Google-Smtp-Source: ABdhPJy+VLXM67CsYaIWq1jRO9CSa6ywxu8wbPp00FPCKNub8Lp7Om4LKp/vg8wy+mPPNYXJQxTuU6SKabOjmK+CsEA= X-Received: by 2002:a17:907:234f:: with SMTP id we15mr17701631ejb.235.1643752629704; Tue, 01 Feb 2022 13:57:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 1 Feb 2022 13:56:58 -0800 Message-ID: To: Shwetha Bhandari Cc: James Guichard , draft-ietf-sfc-ioam-nsh@ietf.org, "sfc@ietf.org" , "sfc-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000979b7405d6fbfbdf" Archived-At: Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 21:57:18 -0000 --000000000000979b7405d6fbfbdf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Shwetha, thank you for your kind consideration of my comments and questions, and the work you put into addressing them; much appreciated. I find many of my comments and questions resolved. There are a few remaining and I hope you will clarify them to me. Please find my follow-up notes below: - I couldn't find how an IOAM header with Active or Loopback flags set must be handled by an SFF. - The closing of Section 4.1 can be interpreted as IOAM can be the only payload immediately following the NSH: ... the O bit MUST be set for OAM packets which carry only IOAM data without any regular data payload Would in this situation the Active flag must be set in the IOAM header? And if no "regular data payload" is present, wouldn't IOAM become not a hybrid measurement method, as it is characterized in draft-ietf-ippm-ioam-data, but, according to RFC 7799, an active OAM? Kind regards, Greg On Mon, Jan 31, 2022 at 8:24 PM Shwetha Bhandari < shwetha.bhandari@thoughtspot.com> wrote: > Hi Greg, > > Sorry for the late action on this. > https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 has been > now posted with the edits per this discussion. > > Hi Jim, > > After Greg's review please let us know if the changes are good to progres= s > the draft to the next step. > > Thanks, > Shwetha > > On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky wrote= : > >> Hi Shwetha, >> thank you for the detailed response to my comments. Please feel free to >> share any updates you're considering for the next version. I'll be glad = to >> work together on these. >> I have several follow-up notes in-lined below under the GIM>> tag. >> >> Regards, >> Greg >> >> On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari < >> shwetha.bhandari@thoughtspot.com> wrote: >> >>> Hi Greg, >>> >>> Sorry for the very late reply. Please find responses to your comments >>> inline @Shwetha: >>> >>> >>> >>> On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky >>> wrote: >>> >>>> Dear Authors and All, >>>> I've read the current version of the draft and have some comments I'd >>>> like to share with you. I much appreciate your thoughts on where this = work >>>> should go considering developments in other IETF WGs. Please find my n= otes >>>> and questions below: >>>> >>>> - It is stated in the Abstract that: >>>> >>>> In-situ Operations, Administration, and Maintenance (IOAM) records >>>> operational and telemetry information in the packet while the packe= t >>>> traverses a path between two points in the network. >>>> >>>> But that is the case only for the pre-allocated and incremental trace >>>> option types. The Direct Export option >>>> >>>> does not write telemetry data into the data packet itself but export >>>> telemetry information in a specially constructed packet. >>>> And as we are talking about different IOAM trace options, the >>>> question of the scope of this document seems appropriate. There is a >>>> WGLC on two IOAM documents >>>> >>>> active through September 15th at the IPPM WG. I believe that it would = be >>>> beneficial if we had a single document that describes the applicabilit= y of >>>> IOAM in all its functionality defined by documents in IPPM WG. Of cour= se, >>>> that cannot be a moving target as that would not be helpful. But since= the >>>> IPPM WG discusses the progress of two IOAM documents, it could be a gr= eat >>>> time to address the applicability of the Direct Export trace type >>>> >>>> and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags >>>> . >>>> It would be concerning to have more than one SFC document describing t= he >>>> applicability of the generic IOAM mechanisms >>>> >>>> >>> Shwetha> This is a fair point. We will revise the draft with text in >>> the abstract and Section 3 IOAM-Type to be updated to include the usage >>> of trace and DEX options. The encapsulation of IOAM options within NSH >>> itself in its current form already supports all the IOAM Option Type >>> defined both from draft-ietf-ippm-ioam-data and >>> draft-ietf-ippm-ioam-direct-export along with the flags supported >>> within the options. Hence the IOAM-data-field definitions in the draft = will >>> remain unchanged. >>> >> GIM>> I agree that the definitions of the IOAM data-fields are invariant >> in various data plane encapsulations. You likely follow the discussion o= f >> the IAOM Direct Export and IOAM flags on the IPPM WG list. I think that = for >> SFC NSH, IOAM Direct Export could be as simple as "use the local policy"= . >> The applicability of the Loopback and Active flags seems to require >> detailed explanation by SFP actors. >> >>> >>> >>>> >>>> >>>> - The location of the IOAM header in the SFC >>>> NSH-encapsulated packet is defined in Section 3: >>>> >>>> IOAM-Data-Fields are carried in NSH >>>> using a next protocol header which follows the NSH MD context >>>> headers. >>>> >>>> I've checked RFC 8300 but couldn't find it defines the Next Protocol >>>> header. Also, it appears that NSH Context headers are optional. Hence = my >>>> question. Is the presence of an NSH Context header required when using >>>> IOAM? Could you clarify which mechanism is used to identify the payloa= d of >>>> an SFC NSH-encapsulated packet as IOAM? >>>> >>>> Shwetha> We will reword it, it is not Next Protocol header but using >>> IOAM as a Next Protocol as described in Section 4.1 and requested in IA= NA >>> section. Following is the proposed text to align with the RFC 8300 >>> reference to context headers following base header and service path hea= der: >>> "The NSH is defined in [RFC8300]. IOAM-Data-Fields are carried in >>> NSH using a next protocol to identify IOAM data fields that follows NSH >>> context headers." >>> >> GIM>> I think that RFC 8300 views data following Context Headers as NSH >> payload, not being "in NSH". >> >>> >>>> - If I understand the format of the IOAM header defined in Section >>>> 3 correctly, the header's length is limited by 1020 octets, while t= he >>>> effective length containing IOAM options and data - 1016 octets. Is= that >>>> correct? What is the recommended technique of collecting IOAM data = that >>>> exceeds that limit? >>>> >>>> Shwetha > IOAM options inherently support specifying the size limits a= t >>> the node that added the IOAM options. While operationalizing the soluti= on >>> the data types included and number of nodes expected to be adding the d= ata >>> should be selected. This is covered in deployment >>> considerations draft-brockners-opsawg-ioam-deployment. >>> >>>> >>>> - In Section 4.1, I've found the text reflecting the history of the >>>> discussion about how to carry the IOAM header using NSH encapsulati= on. As >>>> the text has no normative value, I suggest moving it into an Append= ix. >>>> >>>> Shwetha > Agreed, revised draft will have this section moved to >>> Appendix. >>> >> GIM>> Thank you. >> >>> >>>> - I find the rules of handling the O-bit in NSH listed in Section >>>> 4.2 inconsistent and confusing. The IOAM header is not part of NSH >>>> encapsulation but is a part of the payload. But in one case, when u= ser data >>>> follows it, the O-bit must not be set as. If there's no user data a= fter the >>>> IOAM header, then the O-bit must be set. But from the perspective o= f NSH >>>> encapsulation, it includes specially constructed data added for the= sole >>>> purpose of collecting OAM/telemetry information. Then, why, in one = case, >>>> the O-bit is cleared and in the other set if, in both cases, the >>>> NSH-encapsulated packet is used to perform the OAM function? >>>> >>>> Shwetha > The reason for not setting the O-bit for packets that >>> contains actual user data is because RFC 8300 has " SF/SFF/SFC >>> Proxy/Classifier implementations that do not support >>> >>> SFC OAM procedures SHOULD discard packets with O bit set". It wil= l be undesirable to discard packets with O-bit set that carry user data as = IOAM can be inserted insitu. >>> >>> For synthetic traffic created for OAM along with IOAM-data-fields in NS= H following the NSH OAM function with 0-bit set is desirable. >>> >>> GIM>> This is an interesting situation. I agree that there could be an >> SFC element not supporting "SFC OAM procedures" (not clear what these ar= e). >> By the same token, would such SFC element support IOAM, be capable of >> processing IOAM without adverse impact to user data? I am not certain an= d >> it seems that it might be better to recommend that NSH packets with IOAM= be >> dropped by an SFP element if it does not support "SFC OAM". What are you= r >> thoughts? >> >> >>> >>> Thanks, >>> Shwetha >>> >>>> I much appreciate your consideration of my comments and questions and >>>> looking forward to your feedback. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Wed, Aug 18, 2021 at 5:32 AM James Guichard < >>>> james.n.guichard@futurewei.com> wrote: >>>> >>>>> Dear WG: >>>>> >>>>> >>>>> >>>>> This email starts a 2 week Working Group Last Call for >>>>> draft-ietf-sfc-ioam-nsh [1]. >>>>> >>>>> >>>>> >>>>> Please read this document if you haven=E2=80=99t read the most recent= version >>>>> and send your comments to the SFC WG list no later than September 1st >>>>> 2021. >>>>> >>>>> >>>>> >>>>> If you are raising a point which you expect will be specifically >>>>> debated on the mailing list, consider using a specific email/thread f= or >>>>> this point. >>>>> >>>>> >>>>> >>>>> Lastly, if you are an author or contributor please response to >>>>> indicate whether you know of any undisclosed IPR related to this docu= ment. >>>>> >>>>> >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> >>>>> Jim & Joel >>>>> >>>>> >>>>> >>>>> [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> >>>> --000000000000979b7405d6fbfbdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Shwetha,
thank you for your k= ind consideration of my comments and questions, and the work you put into a= ddressing them; much appreciated.=C2=A0
I find many of my comment= s and questions resolved. There are a few remaining and I hope you will cla= rify them to me. Please find my follow-up notes below:
  • I = couldn't find how an IOAM header with Active or Loopback flags set mu= st be handled by an SFF.
  • The closing of Section 4.1 can be interpre= ted=C2=A0as IOAM can be the only payload immediately following the NSH:
... the O bit MUST be set for
=C2=A0 =C2=A0OAM packets which carry only IOAM data without any regul= ar data
=C2=A0 =C2=A0payload
Would= in this situation the Active flag must be set in the IOAM header? And if n= o "regular data payload" is present, wouldn't IOAM become not= a hybrid measurement method, as it is characterized in draft-ietf-ippm-ioa= m-data, but, according to RFC 7799, an active OAM?

Kind regards,
Greg

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 31, 2022 at 8:24 PM Shweth= a Bhandari <shwetha.= bhandari@thoughtspot.com> wrote:
Hi Greg,

Sorry = for the late action on this. https://datatracker.ietf.o= rg/doc/html/draft-ietf-sfc-ioam-nsh-07 has been now posted with the edi= ts per this discussion.=C2=A0

Hi Jim,

After Greg's review please let us know if the changes = are good to progress the draft to the next step.

T= hanks,
Shwetha

On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky &= lt;gregimirsky@g= mail.com> wrote:
Hi Shwetha,
= thank you for the detailed response to my comments. Please feel free to sha= re any updates you're considering for the next version. I'll be gla= d to work together on these.
I have several follow-up notes in-li= ned below under the GIM>> tag.

Regards,
Greg

On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari <shwetha.bha= ndari@thoughtspot.com> wrote:
Hi Greg,

Sorry for the very late reply. Please find responses = to your comments inline @Shwetha:



On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear = Authors and All,
I've read the current version of the draft and hav= e some comments I'd like to share with you. I much appreciate your thou= ghts on where this work should go considering developments in other IETF WG= s. Please find my notes and questions below:
  • It is stated= in the Abstract that:
=C2=A0 =C2=A0In-situ Operations, Administra= tion, and Maintenance (IOAM) records
=C2=A0 =C2=A0operational and teleme= try information in the packet while the packet
=C2=A0 =C2=A0traverses a = path between two points in the network.
But that is t= he case only for the pre-allocated and incremental trace option=C2=A0types.= The = Direct Export option does not write telemetry=C2=A0data into the data p= acket itself but export telemetry information in a specially constructed pa= cket.=C2=A0
And as we are talking about different IOAM trace opti= ons, the question=C2=A0of the scope of this document seems appropriate. The= re is a WGLC on two IOAM documents active through September 15th at the I= PPM WG. I believe that it would be beneficial if we had a single document t= hat describes the applicability of IOAM in all its functionality defined by= documents in IPPM WG. Of course, that cannot be a moving target as that wo= uld not be helpful. But since the IPPM WG discusses the progress of two IOA= M documents, it could be a great time to address the applicability of the Direct= Export trace type and Loopback and Active flags defined in=C2=A0draft-ietf-ippm-ioa= m-flags. It would be concerning to have more than one SFC document desc= ribing the applicability of the generic IOAM mechanisms
<= /div>

Shwetha> This is a fair point. We will revise = the=C2=A0 draft with text in the abstract and Section 3 IOAM-Type=C2=A0to be= updated to include the usage of trace and DEX options.=C2=A0 The encapsula= tion of IOAM options within NSH itself in its current form already supports= all the IOAM Option Type defined both from draft-ietf-ippm-ioam-data and=C2=A0draft-ietf-ippm-ioam-direct-export along with the flags supported within the options. Hence the IOAM-d= ata-field definitions in the draft will remain unchanged.=C2=A0
GIM>> I agree that the definitions of = the IOAM data-fields are invariant in various data plane encapsulations. Yo= u likely follow the discussion of the IAOM Direct Export and IOAM flags on = the IPPM WG list. I think that for SFC NSH, IOAM Direct Export could be as = simple as "use the local policy". The applicability of the Loopba= ck and Active flags seems to require detailed explanation by SFP actors.

=C2=A0
  • The location of the IOAM header in the SFC NSH-encapsulated= =C2=A0packet is defined in Section 3:
=C2=A0 =C2=A0IOAM-Data= -Fields are carried in NSH
=C2=A0 =C2=A0using a next protocol hea= der which follows the NSH MD context
=C2=A0 =C2=A0headers.
<= /blockquote>
I've checked RFC 8300 but couldn't find it defines the = Next Protocol header. Also, it appears that NSH Context headers=C2=A0are op= tional. Hence my question. Is the presence of an NSH Context header require= d when using IOAM? Could you clarify which mechanism is used to identify th= e payload of an SFC NSH-encapsulated packet as IOAM?
Shwetha> We wi= ll reword it, it is not Next Protocol header but using IOAM as a Next Proto= col as described in Section 4.1 and requested in IANA section. Following is= the proposed text to align with the RFC 8300 reference to context headers = following base header and service path header:
"The NSH is defined in [RFC8300].=C2=A0 IOAM-Data-Field= s are carried in NSH=C2=A0using a next protocol to identify IOAM data field= s that follows NSH context headers."
GIM>> I think that RFC 8300 views data following Context Hea= ders as NSH payload, not being "in NSH".=C2=A0
  • If I understand the format of the IOAM header defined in Section= 3 correctly, the header's length is limited by 1020 octets, while the = effective length containing IOAM options and data - 1016 octets. Is that co= rrect? What is the recommended technique of collecting IOAM data that excee= ds that limit?
Shwetha > IOAM options inherently support specifying the size limits= at the node that added the IOAM options. While operationalizing the soluti= on the data types included and number of nodes expected to be adding the da= ta should be selected. This is covered in deployment considerations=C2=A0dr= aft-brockners-opsawg-ioam-deployment.
  • In Section 4.1, I= 9;ve found the text reflecting the history of the discussion about how to c= arry the IOAM header using NSH encapsulation. As the text has no normative = value, I suggest moving it into an Appendix.
Shwetha > Agreed, revised draft will h= ave this section moved to Appendix.=C2=A0
GIM>> Thank you.=C2=A0
  • I find t= he rules of handling the O-bit in NSH listed in Section 4.2 inconsistent an= d confusing. The IOAM header is not part of NSH encapsulation but is a part= of the payload. But in one case, when user data follows it, the O-bit must= not be set as. If there's no user data after the IOAM header, then the= O-bit must be set. But from the perspective of NSH encapsulation, it inclu= des specially constructed data added for the sole purpose of collecting OAM= /telemetry information. Then, why, in one case, the O-bit is cleared and in= the other set if, in both cases, the NSH-encapsulated packet is used to pe= rform the OAM function?
Shwetha > The reason for not setting the O-bit for packet= s that contains actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier implementations tha= t do not support
      SFC OAM procedures SH=
OULD discard packets with O bit set". It will be undesirable to discar=
d packets with O-bit set that carry user data as IOAM can be inserted insit=
u.
For synthetic traffic created for OAM along with IOAM-data-=
fields in NSH following the NSH OAM function with 0-bit set is desirable.  =
=C2=A0GIM>> This is an interestin= g situation. I agree that there could be an SFC element not supporting &quo= t;SFC OAM procedures" (not clear what these are). By the same token, w= ould such SFC element support IOAM, be capable of processing IOAM without a= dverse impact to user data? I am not certain and it seems that it might be = better to recommend that NSH packets with IOAM be dropped by an SFP element= if it does not support "SFC OAM". What are your thoughts?
<= div>=C2=A0

Thanks,
Shwetha=C2= =A0
I much appreciate your consideration of my comments and question= s and looking forward to your feedback.

Rega= rds,
Greg

On Wed, Aug 18, 2021 at 5:32 AM James Guichard <= ;james.= n.guichard@futurewei.com> wrote:

Dear WG:

=C2=A0

This email starts a 2 week Working Group Last Call f= or draft-ietf-sfc-ioam-nsh [1].

=C2=A0

Please read this document if you haven=E2=80=99t rea= d the most recent version and send your comments to the SFC WG list no late= r than September 1st 2021.

=C2=A0

If you are raisi= ng a point which you expect will be specifically debated on the mailing lis= t, consider using a specific email/thread for this point.

=C2=A0=

Lastly, if you a= re an author or contributor please response to indicate whether you know of= any undisclosed IPR related to this document.

=C2=A0

Thanks!

=C2=A0

Jim & Joel

=C2=A0

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.i= etf.org/mailman/listinfo/sfc
--000000000000979b7405d6fbfbdf-- From nobody Wed Feb 2 07:29:28 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1423A124C for ; Wed, 2 Feb 2022 07:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thoughtspot.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 Adyy_Y2m6tDU for ; Wed, 2 Feb 2022 07:29:22 -0800 (PST) Received: from mx0a-0055fe01.pphosted.com (mx0a-0055fe01.pphosted.com [205.220.164.104]) (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 363CD3A124B for ; Wed, 2 Feb 2022 07:29:20 -0800 (PST) Received: from pps.filterd (m0211451.ppops.net [127.0.0.1]) by mx0b-0055fe01.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 2126c97s022525 for ; Wed, 2 Feb 2022 07:29:20 -0800 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by mx0b-0055fe01.pphosted.com (PPS) with ESMTPS id 3dydb9a84p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 02 Feb 2022 07:29:19 -0800 Received: by mail-qk1-f197.google.com with SMTP id a134-20020ae9e88c000000b0047ebe47102dso14722968qkg.18 for ; Wed, 02 Feb 2022 07:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thoughtspot.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E6olY9HsTKpo8QnfXVeeDaWNgDolDIEALnHeLmbrPyQ=; b=hBJ8tVMcQwoqXeIz2UEnsTE7l45jlqE0AbndWiMSAt+lSCtBDXnRjleiKkCDNZAcSB d4u1x4JOdoaK9glD/FnbRXSLDwse+GMnWbZ9maZL7vWMZAtAf0qpFIGWESazhz9KOthZ BqYRjZ2V4h1UD0zJnWHwzfwYW36ZMx0Na1MOnQK1fs9qucYAaL+DkEZwQhWkG1PCxW81 I/R2ZEEGRsPiVDhNssMLh9Xp5GprEmn3LZzhmErps8QDBoO/OeR4efUsuwICDaD7i/x0 TzzIRGNEGtpS+5Gimu28oCyqpvFbe5HoIMYA/lOxRK3duy7lwY/ClJP+dzyprpN7gR+d 6/bQ== 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=E6olY9HsTKpo8QnfXVeeDaWNgDolDIEALnHeLmbrPyQ=; b=AnXJ2vKytGj2cPskaNwr1jN63SME+5L409bbvOKq0cU6cpnMBqETF8XeIN/0B2+Qqj 23PqeAsR/cZnb3MUiX6kUGIO0qKtB5PywhavtHrwdMWvssmQNkQ13mOdFXXICMfSLBrK kTJzYrxiy/te3attxA1tec4MRyltBqwptWimHi6XQPpYw3LeL8qkVam0I9MmrOtCUY+f wSoUQ9vM0kERF7cCj1IW6VivG7KfxBuMoT0tZpJVLaStHmljOZMU5z42L14BEpqMn6ls IDVkyMj7y3E8hi9Nku8OMn4fxG9CtYntcY+gdoTqgkc6GCH7EcLp5brcRvh7zBb9M+Y6 h5ug== X-Gm-Message-State: AOAM530bmiZQLjlYqlrnGmD5ko2s2fQ6o2tM2GEx+M4nQw5HST7Af6Ll Y5PUI7XMsBtpCxlCuWnRFzw5PITaU5ME/geMflNsimuzJfqQC68toyVMQlBsHMSiCTIKh5C4aJr 4JQ1bkbN7Gz7xKUSkqKU= X-Received: by 2002:a37:94d:: with SMTP id 74mr20651864qkj.598.1643815757961; Wed, 02 Feb 2022 07:29:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJxPDTJdOUMGat9sVErzFJ8rUkDGV0PJA5m+Qfdhl3VBF7cDUACsW4rjWLmpZdIWxNqsMREbN45Et1bZe62mWg8= X-Received: by 2002:a37:94d:: with SMTP id 74mr20651835qkj.598.1643815757516; Wed, 02 Feb 2022 07:29:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Shwetha Bhandari Date: Wed, 2 Feb 2022 20:59:04 +0530 Message-ID: To: James Guichard Cc: Greg Mirsky , "draft-ietf-sfc-ioam-nsh@ietf.org" , "sfc@ietf.org" , "sfc-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004da65305d70aae4f" X-Proofpoint-GUID: AC5yQrgxGGcHM9KETG2Ooe2U5UdfTcVA X-Proofpoint-ORIG-GUID: AC5yQrgxGGcHM9KETG2Ooe2U5UdfTcVA 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-02_07,2022-02-01_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 spamscore=0 bulkscore=5 suspectscore=0 phishscore=0 lowpriorityscore=0 clxscore=1015 adultscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202020085 Archived-At: Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 15:29:27 -0000 --0000000000004da65305d70aae4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jim, Greg, Thanks for the follow up. 1) On O-bit: I am a bit confused about the O-bit feedback. Are you suggesting that it should not be a consideration for IOAM as it is handled as a next protocol and not as NSH context headers? What should a SFC element handle a packet containing IOAM as next header and does not implement IOAM and hence does not understand IOAM? I think O-bit helps in such situations to help such elements decide to drop or forward without processing the IOAM header. Let me know if that is not the case and if simply not considering O-bit in the context of IOAM is what you would recommend. 2) Active or Loopback flags - there is nothing specific for NSH on how the flags are to be handled. The IOAM specific fields are to be handled as recommended by the respective IOAM drafts. Do you see any specific NSH considerations to be documented for IOAM fields? Thanks, Shwetha On Tue, Feb 1, 2022 at 4:29 PM James Guichard < james.n.guichard@futurewei.com> wrote: > Hi Shwetha & Greg, > > > > Thank you for the update. > > > > I still believe however that more work is necessary to reconcile how SFC > OAM is supposed to work. RFC 8300 says: > > > > O bit: Setting this bit indicates an OAM packet (see [RFC6291 > > ]). > > The actual format and processing of SFC OAM packets is outside the > > scope of this specification (for example, see [SFC-OAM-FRAMEWORK > > ] > > for one approach). > > > > The O bit MUST be set for OAM packets and MUST NOT be set for > > non-OAM packets. > > > > If we look at RFC6291 it simply describes what OAM is supposed to mean an= d > this is independent from SFC. The SFC-OAM-Framework (now RFC 8924) in > section 6.3 says: > > > > The Next Protocol field in the NSH header may be used to indicate what > OAM function is intended > > or what toolset is used. Any other overlay encapsulations used at the > service layer must have a > > similar way to indicate the intended OAM function. > > > > So my reading of this is that if you take 8300 together with the framewor= k > then 1. The O-bit MUST be set for OAM packets, and 2. The Next Protocol > field may or may not be used to indicate which OAM function is to be > applied. From this I can determine that iOAM has taken the approach of > using the next protocol field to indicate how to process the OAM packet a= nd > does NOT use the NSH context headers in any way shape or form. This seems > consistent with the current definitions of the O-bit from RFC 8300 and > processing guidelines from RFC 8924. > > > > However, your document says: > > > > *4.1 > . > IOAM and the use of the NSH O-bit* > > > > [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300 > ] > the O > > bit must be set for OAM packets and must not be set for non-OAM > > packets. Packets with IOAM data included MUST follow this > > definition, i.e. the O bit MUST NOT be set for regular customer > > traffic which also carries IOAM data and the O bit MUST be set for > > OAM packets which carry only IOAM data without any regular data > > payload. > > > > This text basically says that if the packet is customer traffic and > happens to carry iOAM data then it is NOT an OAM packet. What am I > missing, customer traffic or not, both carry iOAM data so how are they > different within an SFC domain? > > > > In addition to the above I will note that there is still a conflict with > Greg=E2=80=99s draft namely this text from section 4: > > * O bit set and the "Next Protocol" value does not match the value > > Active SFC OAM (TBA1), defined in Section 10.1 > > : > > > > - An SFC NSH Context Header(s) contain an OAM processing > > instructions or data. > > > > - The "Next Protocol" field determines the type of the payload. > > > > The above text suggests to me that if the O-bit is set and the next > protocol is not active SFC OAM then it is **required** that OAM data will > be in the NSH context headers (which is not the case for iOAM) and the ne= xt > protocol will indicate what follows the NSH header. While iOAM does follo= w > the NSH header as indicated by the next protocol there is still an > expectation that OAM is also carried in the NSH context headers. This see= ms > to be in conflict with RFC 8300 AND RFC 8924. > > > > This of course is just my reading of the text and I would like to hear > yours and other folks thoughts. > > > > Jim > > > > *From:* Shwetha Bhandari > *Sent:* Monday, January 31, 2022 11:25 PM > *To:* Greg Mirsky > *Cc:* James Guichard ; > draft-ietf-sfc-ioam-nsh@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org > *Subject:* Re: [sfc] WGLC for > https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ > > > > > Hi Greg, > > > > Sorry for the late action on this. > https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 > > has been now posted with the edits per this discussion. > > > > Hi Jim, > > > > After Greg's review please let us know if the changes are good to progres= s > the draft to the next step. > > > > Thanks, > > Shwetha > > > > On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky wrote= : > > Hi Shwetha, > > thank you for the detailed response to my comments. Please feel free to > share any updates you're considering for the next version. I'll be glad t= o > work together on these. > > I have several follow-up notes in-lined below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari < > shwetha.bhandari@thoughtspot.com> wrote: > > Hi Greg, > > > > Sorry for the very late reply. Please find responses to your comments > inline @Shwetha: > > > > > > > > On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky wrote: > > Dear Authors and All, > > I've read the current version of the draft and have some comments I'd lik= e > to share with you. I much appreciate your thoughts on where this work > should go considering developments in other IETF WGs. Please find my note= s > and questions below: > > - It is stated in the Abstract that: > > In-situ Operations, Administration, and Maintenance (IOAM) records > operational and telemetry information in the packet while the packet > traverses a path between two points in the network. > > But that is the case only for the pre-allocated and incremental trace > option types. The Direct Export option > > does not write telemetry data into the data packet itself but export > telemetry information in a specially constructed packet. > > And as we are talking about different IOAM trace options, the question of > the scope of this document seems appropriate. There is a WGLC on two IOAM > documents > > active through September 15th at the IPPM WG. I believe that it would be > beneficial if we had a single document that describes the applicability o= f > IOAM in all its functionality defined by documents in IPPM WG. Of course, > that cannot be a moving target as that would not be helpful. But since th= e > IPPM WG discusses the progress of two IOAM documents, it could be a great > time to address the applicability of the Direct Export trace type > > and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags > . > It would be concerning to have more than one SFC document describing the > applicability of the generic IOAM mechanisms > > > > Shwetha> This is a fair point. We will revise the draft with text in the > abstract and Section 3 IOAM-Type to be updated to include the usage of > trace and DEX options. The encapsulation of IOAM options within NSH itse= lf > in its current form already supports all the IOAM Option Type defined bot= h > from draft-ietf-ippm-ioam-data and draft-ietf-ippm-ioam-direct-export > along with the flags supported within the options. Hence the > IOAM-data-field definitions in the draft will remain unchanged. > > GIM>> I agree that the definitions of the IOAM data-fields are invariant > in various data plane encapsulations. You likely follow the discussion of > the IAOM Direct Export and IOAM flags on the IPPM WG list. I think that f= or > SFC NSH, IOAM Direct Export could be as simple as "use the local policy". > The applicability of the Loopback and Active flags seems to require > detailed explanation by SFP actors. > > > > > > > - The location of the IOAM header in the SFC NSH-encapsulated packet > is defined in Section 3: > > IOAM-Data-Fields are carried in NSH > > using a next protocol header which follows the NSH MD context > > headers. > > I've checked RFC 8300 but couldn't find it defines the Next Protocol > header. Also, it appears that NSH Context headers are optional. Hence my > question. Is the presence of an NSH Context header required when using > IOAM? Could you clarify which mechanism is used to identify the payload o= f > an SFC NSH-encapsulated packet as IOAM? > > Shwetha> We will reword it, it is not Next Protocol header but using IOAM > as a Next Protocol as described in Section 4.1 and requested in IANA > section. Following is the proposed text to align with the RFC 8300 > reference to context headers following base header and service path heade= r: > > "The NSH is defined in [RFC8300]. IOAM-Data-Fields are carried in > NSH using a next protocol to identify IOAM data fields that follows NSH > context headers." > > GIM>> I think that RFC 8300 views data following Context Headers as NSH > payload, not being "in NSH". > > > - If I understand the format of the IOAM header defined in Section 3 > correctly, the header's length is limited by 1020 octets, while the > effective length containing IOAM options and data - 1016 octets. Is th= at > correct? What is the recommended technique of collecting IOAM data tha= t > exceeds that limit? > > Shwetha > IOAM options inherently support specifying the size limits at > the node that added the IOAM options. While operationalizing the solution > the data types included and number of nodes expected to be adding the dat= a > should be selected. This is covered in deployment > considerations draft-brockners-opsawg-ioam-deployment. > > > - In Section 4.1, I've found the text reflecting the history of the > discussion about how to carry the IOAM header using NSH encapsulation.= As > the text has no normative value, I suggest moving it into an Appendix. > > Shwetha > Agreed, revised draft will have this section moved to Appendix. > > GIM>> Thank you. > > > - I find the rules of handling the O-bit in NSH listed in Section 4.2 > inconsistent and confusing. The IOAM header is not part of NSH > encapsulation but is a part of the payload. But in one case, when user= data > follows it, the O-bit must not be set as. If there's no user data afte= r the > IOAM header, then the O-bit must be set. But from the perspective of N= SH > encapsulation, it includes specially constructed data added for the so= le > purpose of collecting OAM/telemetry information. Then, why, in one cas= e, > the O-bit is cleared and in the other set if, in both cases, the > NSH-encapsulated packet is used to perform the OAM function? > > Shwetha > The reason for not setting the O-bit for packets that contains > actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier > implementations that do not support > > SFC OAM procedures SHOULD discard packets with O bit set". It will = be undesirable to discard packets with O-bit set that carry user data as IO= AM can be inserted insitu. > > For synthetic traffic created for OAM along with IOAM-data-fields in NSH = following the NSH OAM function with 0-bit set is desirable. > > GIM>> This is an interesting situation. I agree that there could be an > SFC element not supporting "SFC OAM procedures" (not clear what these are= ). > By the same token, would such SFC element support IOAM, be capable of > processing IOAM without adverse impact to user data? I am not certain and > it seems that it might be better to recommend that NSH packets with IOAM = be > dropped by an SFP element if it does not support "SFC OAM". What are your > thoughts? > > > > > > Thanks, > > Shwetha > > I much appreciate your consideration of my comments and questions and > looking forward to your feedback. > > > > Regards, > > Greg > > > > On Wed, Aug 18, 2021 at 5:32 AM James Guichard < > james.n.guichard@futurewei.com> wrote: > > Dear WG: > > > > This email starts a 2 week Working Group Last Call for > draft-ietf-sfc-ioam-nsh [1]. > > > > Please read this document if you haven=E2=80=99t read the most recent ver= sion and > send your comments to the SFC WG list no later than September 1st 2021. > > > > If you are raising a point which you expect will be specifically debated > on the mailing list, consider using a specific email/thread for this poin= t. > > > > Lastly, if you are an author or contributor please response to indicate > whether you know of any undisclosed IPR related to this document. > > > > Thanks! > > > > Jim & Joel > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ > > > > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > --0000000000004da65305d70aae4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim, Greg,

Thanks for the follo= w up.
1) On O-bit: I am a bit confused about the O-bit feedback. = Are you suggesting that it should not be a consideration for IOAM as it is = handled as a next protocol and not as NSH context headers?
What s= hould a SFC element handle a packet containing IOAM as next header and does= not implement IOAM and hence does not understand IOAM? I think O-bit helps= in such situations to help such elements decide to drop or forward without= processing the IOAM header.
Let me know if that is not the case = and if simply not considering O-bit in the context of IOAM is what you woul= d recommend.
2) Active or Loopback flags=C2=A0- there is nothing specific= =C2=A0for NSH on how the flags are to be handled.=C2=A0 The IOAM specific f= ields are to be handled as recommended by the respective IOAM drafts. Do yo= u see any specific NSH considerations to be documented for IOAM fields?

Thanks,
Shwetha





<= /div>
O= n Tue, Feb 1, 2022 at 4:29 PM James Guichard <james.n.guichard@futurewei.com> wrote:

Hi Shwetha & Greg,

=C2=A0

Thank you for the update.

=C2=A0

I still believe however that more work is necessary = to reconcile how SFC OAM is supposed to work. RFC 8300 says:

=C2=A0

=C2=A0=C2=A0 O bit:=C2=A0 Setting this bit indic= ates an OAM packet (see [RFC6291]).<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The actual format= and processing of SFC OAM packets is outside the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scope of this spe= cification (for example, see [SFC-OAM-FRAMEWORK]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for one approach)= .

=C2=A0

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0The O bit MUST be= set for OAM packets and MUST NOT be set for

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 non-OAM packets.<= u>

=C2=A0

If we look at RFC6291 it simply describes what OAM i= s supposed to mean and this is independent from SFC. The SFC-OAM-Framework = (now RFC 8924) in section 6.3 says:

=C2=A0

=C2=A0=C2=A0 The Next Protocol field in the NSH = header may be used to indicate what OAM function is intended<= /span>

=C2=A0=C2=A0 or what toolset is used.=C2=A0 Any = other overlay encapsulations used at the service layer must have a

=C2=A0=C2=A0=C2=A0similar way to indicate the in= tended OAM function.

=C2=A0

So my reading of this is that if you take 8300 toget= her with the framework then 1. The O-bit MUST be set for OAM packets, and 2= . The Next Protocol field may or may not be used to indicate which OAM func= tion is to be applied. From this I can determine that iOAM has taken the approach of using the next protocol = field to indicate how to process the OAM packet and does NOT use the NSH co= ntext headers in any way shape or form. This seems consistent with the curr= ent definitions of the O-bit from RFC 8300 and processing guidelines from RFC 8924.

=C2=A0

However, your document says:

=C2=A0

4.1.=C2=A0 IOAM and the use of the N= SH O-bit

=C2=A0

=C2=A0=C2=A0 [RFC8300] defines an "O bit&qu= ot; for OAM packets.=C2=A0 Per [RFC8300] the O

=C2=A0=C2=A0 bit must be set for OAM packets and= must not be set for non-OAM

=C2=A0=C2=A0 packets.=C2=A0 Packets with IOAM da= ta included MUST follow this

=C2=A0=C2=A0 definition, i.e. the O bit MUST NOT= be set for regular customer

=C2=A0=C2=A0 traffic which also carries IOAM dat= a and the O bit MUST be set for

=C2=A0=C2=A0 OAM packets which carry only IOAM d= ata without any regular data

=C2=A0=C2=A0 payload.

=C2=A0

This text basically says that if the packet is custo= mer traffic and happens to carry iOAM data then it is NOT an OAM packet.=C2= =A0 What am I missing, customer traffic or not, both carry iOAM data so how= are they different within an SFC domain?

=C2=A0

In addition to the above I will note that there is s= till a conflict with Greg=E2=80=99s draft namely this text from section 4:<= span style=3D"font-size:10pt;font-family:"Courier New";color:blac= k">

=C2=A0=C2=A0 *=C2=A0 O bit set and the "Nex= t Protocol" value does not match the value

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Active SFC OAM (T= BA1), defined in Section 10.1:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - An SFC NSH Context Header(s) contain an OAM processing

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= instructions or data.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - The "Next Protocol" field determines the type of the payload.<= u>

=C2=A0

The above text suggests to me that if the O-bit is s= et and the next protocol is not active SFC OAM then it is *required*= that OAM data will be in the NSH context headers (which is not the case fo= r iOAM) and the next protocol will indicate what follows the NSH header. While iOAM does follow the NSH heade= r as indicated by the next protocol there is still an expectation that OAM = is also carried in the NSH context headers. This seems to be in conflict wi= th RFC 8300 AND RFC 8924.

=C2=A0

This of course is just my reading of the text and I = would like to hear yours and other folks thoughts.

=C2=A0

Jim

=C2=A0

From: Shwetha Bhandari <shwetha.bhandari@though= tspot.com>
Sent: Monday, January 31, 2022 11:25 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: James Guichard <james.n.guichard@futurewei.com>; draft-ietf-sfc-io= am-nsh@ietf.org; sfc@= ietf.org; sfc-= chairs@ietf.org
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh= /

=C2=A0

Hi Greg,

=C2=A0

Sorry for the late action on this. https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 has be= en now posted with the edits per this discussion.=C2=A0

=C2=A0

Hi Jim,

=C2=A0

After Greg's review please let us know if the ch= anges are good to progress the draft to the next step.

=C2=A0

Thanks,

Shwetha

=C2=A0

On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

Hi Shwetha,

thank you for the detailed response to my comments. = Please feel free to share any updates you're considering for the next v= ersion. I'll be glad to work together on these.

I have several follow-up notes in-lined below under = the GIM>> tag.

=C2=A0

Regards,

Greg

=C2=A0

On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari <= ;shwe= tha.bhandari@thoughtspot.com> wrote:

= Hi Greg,

=C2=A0

= Sorry for the very late reply. Please find responses to your comments inlin= e @Shwetha:

=C2=A0

=C2=A0

=C2=A0

On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <gregimirsky@gmail.com= > wrote:

Dear Authors and All,

I've read the current version of the draft and h= ave some comments I'd like to share with you. I much appreciate your th= oughts on where this work should go considering developments in other IETF = WGs. Please find my notes and questions below:

  • It is stated in the Abstract that:

=C2=A0 =C2=A0In-situ Operations, Administration, and= Maintenance (IOAM) records
=C2=A0 =C2=A0operational and telemetry information in the packet while the = packet
=C2=A0 =C2=A0traverses a path between two points in the network.<= /u>

But that is the case only for the pre-allocated and = incremental trace option=C2=A0types. The Direct Export option does not write telemetry=C2=A0data into the data p= acket itself but export telemetry information in a specially constructed pa= cket.=C2=A0

And as we are talking about different IOAM trace opt= ions, the question=C2=A0of the scope of this document seems appropriate. Th= ere is a WGLC on two IOAM documents active through September 15th at the IPPM = WG. I believe that it would be beneficial if we had a single document that = describes the applicability of IOAM in all its functionality defined by doc= uments in IPPM WG. Of course, that cannot be a moving target as that would not be helpful. But since the IPPM= WG discusses the progress of two IOAM documents, it could be a great time = to address the applicability of the Direct Export trace type and Loopback and Active flags defined in= =C2=A0draft-ietf-ippm-ioam-flags. It would be concerning to have more than one SFC document describing the a= pplicability of the generic IOAM mechanisms

=C2=A0

= Shwetha> This is a fair point. We will revise the=C2=A0 draft with text = in the abstract and Section 3 IOAM-Type=C2=A0to be updated to include the usage of trace and DEX options.=C2=A0 The encapsulation of IOAM options within NSH = itself in its current form already supports all the IOAM Option Type define= d both from draft-i= etf-ippm-ioam-data and=C2=A0draft-ietf-ippm-ioam-direct-export along with the flags supported within the options. Hence the IOAM-data-fie= ld definitions in the draft will remain unchanged.=C2=A0

GIM>> I agree that the definitions of the IOAM= data-fields are invariant in various data plane encapsulations. You likely= follow the discussion of the IAOM Direct Export and IOAM flags on the IPPM= WG list. I think that for SFC NSH, IOAM Direct Export could be as simple as "use the local policy". The = applicability of the Loopback and Active flags seems to require detailed ex= planation by SFP actors.

=C2=A0

=C2=A0

  • The location of the IOAM header in the SFC NSH-encapsulated=C2=A0packet is = defined in Section 3:

=C2=A0 =C2=A0IOAM-Data-Fields are carried in NSH<= /u>

=C2=A0 =C2=A0using a next protocol header which foll= ows the NSH MD context

=C2=A0 =C2=A0headers.

I've checked RFC 8300 but couldn't find it d= efines the Next Protocol header. Also, it appears that NSH Context headers= =C2=A0are optional. Hence my question. Is the presence of an NSH Context he= ader required when using IOAM? Could you clarify which mechanism is used to identify the payload of an SFC NSH-encapsulated= packet as IOAM?

= Shwetha> We will reword it, it is not Next Protocol header but using IOA= M as a Next Protocol as described in Section 4.1 and requested in IANA sect= ion. Following is the proposed text to align with the RFC 8300 reference to context headers following base header and servic= e path header:

= "The NSH is defined in [RFC8300].=C2=A0 IOAM-Data-Fields are carried i= n NSH=C2=A0using a next protocol to identify IOAM data fields that follows = NSH context headers."

GIM>> I think that RFC 8300 views data followi= ng Context Headers as NSH payload, not being "in NSH".=C2=A0

  • If I understand the format of the IOAM header defined in Section 3 correctl= y, the header's length is limited by 1020 octets, while the effective l= ength containing IOAM options and data - 1016 octets. Is that correct? What= is the recommended technique of collecting IOAM data that exceeds that limit?

= Shwetha > IOAM options inherently support specifying the size limits at = the node that added the IOAM options. While operationalizing the solution t= he data types included and number of nodes expected to be adding the data should be selected. This is covered in deployment co= nsiderations=C2=A0draft-brockners-opsawg-ioam-deployment.<= /u>

  • In Section 4.1, I've found the text reflecting the history of the discu= ssion about how to carry the IOAM header using NSH encapsulation. As the te= xt has no normative value, I suggest moving it into an Appendix.<= /u>

= Shwetha > Agreed, revised draft will have this section moved to Appendix= .=C2=A0

GIM>> Thank you.=C2=A0

  • I find the rules of handling the O-bit in NSH listed in Section 4.2 inconsi= stent and confusing. The IOAM header is not part of NSH encapsulation but i= s a part of the payload. But in one case, when user data follows it, the O-= bit must not be set as. If there's no user data after the IOAM header, then the O-bit must be set. But from t= he perspective of NSH encapsulation, it includes specially constructed data= added for the sole purpose of collecting OAM/telemetry information. Then, = why, in one case, the O-bit is cleared and in the other set if, in both cases, the NSH-encapsulated packet is use= d to perform the OAM function?

= Shwetha > The reason for not setting the O-bit for packets that contains= actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier implementations that do not support

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 SFC OAM procedures SHOULD discard packets with O bit set=
". It will be undesirable to discard packets with O-bit set that carry=
 user data as IOAM can be inserted insitu.
For synthetic =
traffic created for OAM along with IOAM-data-fields in NSH following the NS=
H OAM function with 0-bit set is desirable.=C2=A0

=C2=A0GIM>> This is an interesting situation. = I agree that there could be an SFC element not supporting "SFC OAM pro= cedures" (not clear what these are). By the same token, would such SFC= element support IOAM, be capable of processing IOAM without adverse impact to user data? I am not certain and it seems that it might b= e better to recommend that NSH packets with IOAM be dropped by an SFP eleme= nt if it does not support "SFC OAM". What are your thoughts?

=C2=A0

=C2=A0

= Thanks,

= Shwetha=C2=A0

I much appreciate your consideration of my comments = and questions and looking forward to your feedback.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Aug 18, 2021 at 5:32 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

Dear WG:

=C2=A0

This email starts a 2 week Working Group Last Call f= or draft-ietf-sfc-ioam-nsh [1].

=C2=A0

Please read this document if you haven=E2=80=99t rea= d the most recent version and send your comments to the SFC WG list no late= r than September 1st 2021.

=C2=A0

If you are raisi= ng a point which you expect will be specifically debated on the mailing lis= t, consider using a specific email/thread for this point.<= /u>

=C2=A0=

Lastly, if you a= re an author or contributor please response to indicate whether you know of= any undisclosed IPR related to this document.

=C2=A0

Thanks!

=C2=A0

Jim & Joel

=C2=A0

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/=

=C2=A0

=C2=A0

=C2=A0

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

--0000000000004da65305d70aae4f-- From nobody Wed Feb 2 08:28:56 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60D93A14F6; Wed, 2 Feb 2022 08:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] 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 gb_lHM-dE99D; Wed, 2 Feb 2022 08:28:50 -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 6114C3A14F7; Wed, 2 Feb 2022 08:28:49 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id jx6so67752364ejb.0; Wed, 02 Feb 2022 08:28:49 -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=9tcB2oquhndghQaJzwbmkeq34EsHrAYQSYXcq2hQ2u8=; b=Duh7/GMrZK6ExL0fejjG75ZxykpRrpSYsMkwBDOKyvcoBYn5cSIkWXSni5FHrJZGhV 2bncBftTSjbFlKfRJf/IHZDNJKtBg2BsH3Mc9F7hW0JCTneffK4QLeHSBkHS1TjVO3RI 3Hlk1LoZmt4suZjela/51aktRR2UiRfzjg7qCwkrg0jbBL61+SX5yLjf295m5ohSdJtN P3121To/KoW1sdGMZIvDMDwEIKmvuYX90pePVuo9Tmj2RvWIKVUxaxFJrQ8eBKQiF+U4 7LshpB9t+zSiRl5ME6DSbPy1yEBbvrhbdPfEdst9hGVPcYy/3ucsPLJn51me7iWxLBWQ PmmA== 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=9tcB2oquhndghQaJzwbmkeq34EsHrAYQSYXcq2hQ2u8=; b=M+5fzQLcDkv9wc5a3Zt4j8dX2MT/EdkJ0lYhUfPsvNNeGxSihqNUm/JBnOxm0XJCC0 SjD2Us2hdGsuYCzO/2fIjJcXOU8/5pVLiAY1jDvHLIm8PkDRRHS53MlFQvAp2/tjLEsW APlrD8g7tzbz9Xfqy4NLjTmZZ49R0R/plVsGZr97qKF8Rs338V89WeVwenPdu2YVCtPg Pg9JYc6RTgNEQvoq0T4zmJZKDHA9/Ca7+vGhWsQo83mspX0qeLgSFqJ8zA6uX70glql+ OBUDitVM+jkos8ugBFGIqsui3yiKiDqsCRx0qtgwqwA4Y2iJRO64l1rhgLxMOQk7z1X7 Q4ng== X-Gm-Message-State: AOAM533dAXhTvbjd1nVc0nkD8QhzfaMSkNhmF2GIID0Vfta3LZrnnAmW 1nc+2yPPG5a7NqpNa5003kIaU3xUbNOG9dlI13rOTlHB X-Google-Smtp-Source: ABdhPJymJkadV8Nd3NV0pfbR4W24gO1QMiRlPLtD3d9AODIQw1uo2kx6WXGAhD/4eHlZdWzDidCUU0sPOywXeX2Vx00= X-Received: by 2002:a17:907:160f:: with SMTP id hb15mr24498953ejc.213.1643819325372; Wed, 02 Feb 2022 08:28:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Wed, 2 Feb 2022 08:28:34 -0800 Message-ID: To: Shwetha Bhandari Cc: James Guichard , "draft-ietf-sfc-ioam-nsh@ietf.org" , "sfc@ietf.org" , "sfc-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f6bcf305d70b82a2" Archived-At: Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 16:28:55 -0000 --000000000000f6bcf305d70b82a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Shwetha, thank you for your questions. Please find my notes in-line below under the GIM>> tag. Regards, Greg On Wed, Feb 2, 2022 at 7:29 AM Shwetha Bhandari < shwetha.bhandari@thoughtspot.com> wrote: > Hi Jim, Greg, > > Thanks for the follow up. > 1) On O-bit: I am a bit confused about the O-bit feedback. Are you > suggesting that it should not be a consideration for IOAM as it is handle= d > as a next protocol and not as NSH context headers? > What should a SFC element handle a packet containing IOAM as next header > and does not implement IOAM and hence does not understand IOAM? I think > O-bit helps in such situations to help such elements decide to drop or > forward without processing the IOAM header. > GIM>> I cannot find the text in the draft suggesting that an SFF that does not support IOAM may forward the packet with the NSH Next Protocol field equal to IOAM protocol identifier. Could you help me find it? > Let me know if that is not the case and if simply not considering O-bit i= n > the context of IOAM is what you would recommend. > 2) Active or Loopback flags > - > there is nothing specific for NSH on how the flags are to be handled. Th= e > IOAM specific fields are to be handled as recommended by the respective > IOAM drafts. Do you see any specific NSH considerations to be documented > for IOAM fields? > GIM>> For example, if the Loopback IOAM flag is set, the node is required to send a copy of the packet back to the IOAM encapsulating node. It is not clear to me how an SFF learns the identity of the IOAM encapsulating node and how it encapsulates the loopbacked packet. Can you help me find how it is supposed to work in the NSH? > > Thanks, > Shwetha > > > > > > > > On Tue, Feb 1, 2022 at 4:29 PM James Guichard < > james.n.guichard@futurewei.com> wrote: > >> Hi Shwetha & Greg, >> >> >> >> Thank you for the update. >> >> >> >> I still believe however that more work is necessary to reconcile how SFC >> OAM is supposed to work. RFC 8300 says: >> >> >> >> O bit: Setting this bit indicates an OAM packet (see [RFC6291 >> >> ]). >> >> The actual format and processing of SFC OAM packets is outside the >> >> scope of this specification (for example, see [SFC-OAM-FRAMEWORK >> >> ] >> >> for one approach). >> >> >> >> The O bit MUST be set for OAM packets and MUST NOT be set for >> >> non-OAM packets. >> >> >> >> If we look at RFC6291 it simply describes what OAM is supposed to mean >> and this is independent from SFC. The SFC-OAM-Framework (now RFC 8924) i= n >> section 6.3 says: >> >> >> >> The Next Protocol field in the NSH header may be used to indicate wha= t >> OAM function is intended >> >> or what toolset is used. Any other overlay encapsulations used at th= e >> service layer must have a >> >> similar way to indicate the intended OAM function. >> >> >> >> So my reading of this is that if you take 8300 together with the >> framework then 1. The O-bit MUST be set for OAM packets, and 2. The Next >> Protocol field may or may not be used to indicate which OAM function is = to >> be applied. From this I can determine that iOAM has taken the approach o= f >> using the next protocol field to indicate how to process the OAM packet = and >> does NOT use the NSH context headers in any way shape or form. This seem= s >> consistent with the current definitions of the O-bit from RFC 8300 and >> processing guidelines from RFC 8924. >> >> >> >> However, your document says: >> >> >> >> *4.1 >> . >> IOAM and the use of the NSH O-bit* >> >> >> >> [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300 >> ] >> the O >> >> bit must be set for OAM packets and must not be set for non-OAM >> >> packets. Packets with IOAM data included MUST follow this >> >> definition, i.e. the O bit MUST NOT be set for regular customer >> >> traffic which also carries IOAM data and the O bit MUST be set for >> >> OAM packets which carry only IOAM data without any regular data >> >> payload. >> >> >> >> This text basically says that if the packet is customer traffic and >> happens to carry iOAM data then it is NOT an OAM packet. What am I >> missing, customer traffic or not, both carry iOAM data so how are they >> different within an SFC domain? >> >> >> >> In addition to the above I will note that there is still a conflict with >> Greg=E2=80=99s draft namely this text from section 4: >> >> * O bit set and the "Next Protocol" value does not match the value >> >> Active SFC OAM (TBA1), defined in Section 10.1 >> >> : >> >> >> >> - An SFC NSH Context Header(s) contain an OAM processing >> >> instructions or data. >> >> >> >> - The "Next Protocol" field determines the type of the payload. >> >> >> >> The above text suggests to me that if the O-bit is set and the next >> protocol is not active SFC OAM then it is **required** that OAM data >> will be in the NSH context headers (which is not the case for iOAM) and = the >> next protocol will indicate what follows the NSH header. While iOAM does >> follow the NSH header as indicated by the next protocol there is still a= n >> expectation that OAM is also carried in the NSH context headers. This se= ems >> to be in conflict with RFC 8300 AND RFC 8924. >> >> >> >> This of course is just my reading of the text and I would like to hear >> yours and other folks thoughts. >> >> >> >> Jim >> >> >> >> *From:* Shwetha Bhandari >> *Sent:* Monday, January 31, 2022 11:25 PM >> *To:* Greg Mirsky >> *Cc:* James Guichard ; >> draft-ietf-sfc-ioam-nsh@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org >> *Subject:* Re: [sfc] WGLC for >> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >> >> >> >> >> Hi Greg, >> >> >> >> Sorry for the late action on this. >> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 >> >> has been now posted with the edits per this discussion. >> >> >> >> Hi Jim, >> >> >> >> After Greg's review please let us know if the changes are good to >> progress the draft to the next step. >> >> >> >> Thanks, >> >> Shwetha >> >> >> >> On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky >> wrote: >> >> Hi Shwetha, >> >> thank you for the detailed response to my comments. Please feel free to >> share any updates you're considering for the next version. I'll be glad = to >> work together on these. >> >> I have several follow-up notes in-lined below under the GIM>> tag. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari < >> shwetha.bhandari@thoughtspot.com> wrote: >> >> Hi Greg, >> >> >> >> Sorry for the very late reply. Please find responses to your comments >> inline @Shwetha: >> >> >> >> >> >> >> >> On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky wrote= : >> >> Dear Authors and All, >> >> I've read the current version of the draft and have some comments I'd >> like to share with you. I much appreciate your thoughts on where this wo= rk >> should go considering developments in other IETF WGs. Please find my not= es >> and questions below: >> >> - It is stated in the Abstract that: >> >> In-situ Operations, Administration, and Maintenance (IOAM) records >> operational and telemetry information in the packet while the packet >> traverses a path between two points in the network. >> >> But that is the case only for the pre-allocated and incremental trace >> option types. The Direct Export option >> >> does not write telemetry data into the data packet itself but export >> telemetry information in a specially constructed packet. >> >> And as we are talking about different IOAM trace options, the question o= f >> the scope of this document seems appropriate. There is a WGLC on two >> IOAM documents >> >> active through September 15th at the IPPM WG. I believe that it would be >> beneficial if we had a single document that describes the applicability = of >> IOAM in all its functionality defined by documents in IPPM WG. Of course= , >> that cannot be a moving target as that would not be helpful. But since t= he >> IPPM WG discusses the progress of two IOAM documents, it could be a grea= t >> time to address the applicability of the Direct Export trace type >> >> and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags >> . >> It would be concerning to have more than one SFC document describing the >> applicability of the generic IOAM mechanisms >> >> >> >> Shwetha> This is a fair point. We will revise the draft with text in th= e >> abstract and Section 3 IOAM-Type to be updated to include the usage of >> trace and DEX options. The encapsulation of IOAM options within NSH its= elf >> in its current form already supports all the IOAM Option Type defined bo= th >> from draft-ietf-ippm-ioam-data and draft-ietf-ippm-ioam-direct-export >> along with the flags supported within the options. Hence the >> IOAM-data-field definitions in the draft will remain unchanged. >> >> GIM>> I agree that the definitions of the IOAM data-fields are invariant >> in various data plane encapsulations. You likely follow the discussion o= f >> the IAOM Direct Export and IOAM flags on the IPPM WG list. I think that = for >> SFC NSH, IOAM Direct Export could be as simple as "use the local policy"= . >> The applicability of the Loopback and Active flags seems to require >> detailed explanation by SFP actors. >> >> >> >> >> >> >> - The location of the IOAM header in the SFC NSH-encapsulated packet >> is defined in Section 3: >> >> IOAM-Data-Fields are carried in NSH >> >> using a next protocol header which follows the NSH MD context >> >> headers. >> >> I've checked RFC 8300 but couldn't find it defines the Next Protocol >> header. Also, it appears that NSH Context headers are optional. Hence my >> question. Is the presence of an NSH Context header required when using >> IOAM? Could you clarify which mechanism is used to identify the payload = of >> an SFC NSH-encapsulated packet as IOAM? >> >> Shwetha> We will reword it, it is not Next Protocol header but using IOA= M >> as a Next Protocol as described in Section 4.1 and requested in IANA >> section. Following is the proposed text to align with the RFC 8300 >> reference to context headers following base header and service path head= er: >> >> "The NSH is defined in [RFC8300]. IOAM-Data-Fields are carried in >> NSH using a next protocol to identify IOAM data fields that follows NSH >> context headers." >> >> GIM>> I think that RFC 8300 views data following Context Headers as NSH >> payload, not being "in NSH". >> >> >> - If I understand the format of the IOAM header defined in Section 3 >> correctly, the header's length is limited by 1020 octets, while the >> effective length containing IOAM options and data - 1016 octets. Is t= hat >> correct? What is the recommended technique of collecting IOAM data th= at >> exceeds that limit? >> >> Shwetha > IOAM options inherently support specifying the size limits at >> the node that added the IOAM options. While operationalizing the solutio= n >> the data types included and number of nodes expected to be adding the da= ta >> should be selected. This is covered in deployment >> considerations draft-brockners-opsawg-ioam-deployment. >> >> >> - In Section 4.1, I've found the text reflecting the history of the >> discussion about how to carry the IOAM header using NSH encapsulation= . As >> the text has no normative value, I suggest moving it into an Appendix= . >> >> Shwetha > Agreed, revised draft will have this section moved to Appendix= . >> >> GIM>> Thank you. >> >> >> - I find the rules of handling the O-bit in NSH listed in Section 4.2 >> inconsistent and confusing. The IOAM header is not part of NSH >> encapsulation but is a part of the payload. But in one case, when use= r data >> follows it, the O-bit must not be set as. If there's no user data aft= er the >> IOAM header, then the O-bit must be set. But from the perspective of = NSH >> encapsulation, it includes specially constructed data added for the s= ole >> purpose of collecting OAM/telemetry information. Then, why, in one ca= se, >> the O-bit is cleared and in the other set if, in both cases, the >> NSH-encapsulated packet is used to perform the OAM function? >> >> Shwetha > The reason for not setting the O-bit for packets that contains >> actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier >> implementations that do not support >> >> SFC OAM procedures SHOULD discard packets with O bit set". It will= be undesirable to discard packets with O-bit set that carry user data as I= OAM can be inserted insitu. >> >> For synthetic traffic created for OAM along with IOAM-data-fields in NSH= following the NSH OAM function with 0-bit set is desirable. >> >> GIM>> This is an interesting situation. I agree that there could be an >> SFC element not supporting "SFC OAM procedures" (not clear what these ar= e). >> By the same token, would such SFC element support IOAM, be capable of >> processing IOAM without adverse impact to user data? I am not certain an= d >> it seems that it might be better to recommend that NSH packets with IOAM= be >> dropped by an SFP element if it does not support "SFC OAM". What are you= r >> thoughts? >> >> >> >> >> >> Thanks, >> >> Shwetha >> >> I much appreciate your consideration of my comments and questions and >> looking forward to your feedback. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Wed, Aug 18, 2021 at 5:32 AM James Guichard < >> james.n.guichard@futurewei.com> wrote: >> >> Dear WG: >> >> >> >> This email starts a 2 week Working Group Last Call for >> draft-ietf-sfc-ioam-nsh [1]. >> >> >> >> Please read this document if you haven=E2=80=99t read the most recent ve= rsion and >> send your comments to the SFC WG list no later than September 1st 2021. >> >> >> >> If you are raising a point which you expect will be specifically debated >> on the mailing list, consider using a specific email/thread for this poi= nt. >> >> >> >> Lastly, if you are an author or contributor please response to indicate >> whether you know of any undisclosed IPR related to this document. >> >> >> >> Thanks! >> >> >> >> Jim & Joel >> >> >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >> >> >> >> >> >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> --000000000000f6bcf305d70b82a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Shwetha,
thank you for your q= uestions. Please find my notes in-line below under the GIM>> tag.

Regards,
Greg

On Wed, Feb 2, 2022 at 7= :29 AM Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> wrote:
Hi Jim, Greg,
Thanks for the follow up.
1) On O-bit: I am a bi= t confused about the O-bit feedback. Are you suggesting that it should not = be a consideration for IOAM as it is handled as a next protocol and not as = NSH context headers?
What should a SFC element handle a packet co= ntaining IOAM as next header and does not implement IOAM and hence does not= understand IOAM? I think O-bit helps in such situations to help such eleme= nts decide to drop or forward without processing the IOAM header.
GIM>> I cannot find the text in the draft s= uggesting that an SFF that does not support IOAM may forward the packet wit= h the NSH Next Protocol field equal to IOAM protocol identifier. Could you = help me find it?
Let me know if that is not the case and if simply n= ot considering O-bit in the context of IOAM is what you would recommend.
2) Ac= tive or Loopback flags=C2=A0- there is nothing specific=C2=A0for NSH on= how the flags are to be handled.=C2=A0 The IOAM specific fields are to be = handled as recommended by the respective IOAM drafts. Do you see any specif= ic NSH considerations to be documented for IOAM fields?
GIM>> For example, if the Loopback IOAM flag is set, = the node is required to send a copy of the packet back to the IOAM encapsul= ating node. It is not clear to me how an SFF learns the identity of the IOA= M encapsulating node and how it encapsulates the loopbacked packet. Can you= help me find how it is supposed to work in the NSH?=C2=A0

Thanks,
Shwetha






On Tue, Feb 1, 20= 22 at 4:29 PM James Guichard <james.n.guichard@futurewei.com> wrote:
=

Hi Shwetha & Greg,

=C2=A0

Thank you for the update.

=C2=A0

I still believe however that more work is necessary = to reconcile how SFC OAM is supposed to work. RFC 8300 says:

=C2=A0

=C2=A0=C2=A0 O bit:=C2=A0 Setting this bit indic= ates an OAM packet (see [RFC6291]).<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The actual format= and processing of SFC OAM packets is outside the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scope of this spe= cification (for example, see [SFC-OAM-FRAMEWORK]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for one approach)= .

=C2=A0

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0The O bit MUST be= set for OAM packets and MUST NOT be set for

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 non-OAM packets.<= u>

=C2=A0

If we look at RFC6291 it simply describes what OAM i= s supposed to mean and this is independent from SFC. The SFC-OAM-Framework = (now RFC 8924) in section 6.3 says:

=C2=A0

=C2=A0=C2=A0 The Next Protocol field in the NSH = header may be used to indicate what OAM function is intended<= /span>

=C2=A0=C2=A0 or what toolset is used.=C2=A0 Any = other overlay encapsulations used at the service layer must have a

=C2=A0=C2=A0=C2=A0similar way to indicate the in= tended OAM function.

=C2=A0

So my reading of this is that if you take 8300 toget= her with the framework then 1. The O-bit MUST be set for OAM packets, and 2= . The Next Protocol field may or may not be used to indicate which OAM func= tion is to be applied. From this I can determine that iOAM has taken the approach of using the next protocol = field to indicate how to process the OAM packet and does NOT use the NSH co= ntext headers in any way shape or form. This seems consistent with the curr= ent definitions of the O-bit from RFC 8300 and processing guidelines from RFC 8924.

=C2=A0

However, your document says:

=C2=A0

4.1.=C2=A0 IOAM and the use of the N= SH O-bit

=C2=A0

=C2=A0=C2=A0 [RFC8300] defines an "O bit&qu= ot; for OAM packets.=C2=A0 Per [RFC8300] the O

=C2=A0=C2=A0 bit must be set for OAM packets and= must not be set for non-OAM

=C2=A0=C2=A0 packets.=C2=A0 Packets with IOAM da= ta included MUST follow this

=C2=A0=C2=A0 definition, i.e. the O bit MUST NOT= be set for regular customer

=C2=A0=C2=A0 traffic which also carries IOAM dat= a and the O bit MUST be set for

=C2=A0=C2=A0 OAM packets which carry only IOAM d= ata without any regular data

=C2=A0=C2=A0 payload.

=C2=A0

This text basically says that if the packet is custo= mer traffic and happens to carry iOAM data then it is NOT an OAM packet.=C2= =A0 What am I missing, customer traffic or not, both carry iOAM data so how= are they different within an SFC domain?

=C2=A0

In addition to the above I will note that there is s= till a conflict with Greg=E2=80=99s draft namely this text from section 4:<= span style=3D"font-size:10pt;font-family:"Courier New";color:blac= k">

=C2=A0=C2=A0 *=C2=A0 O bit set and the "Nex= t Protocol" value does not match the value

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Active SFC OAM (T= BA1), defined in Section 10.1:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - An SFC NSH Context Header(s) contain an OAM processing

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= instructions or data.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - The "Next Protocol" field determines the type of the payload.<= u>

=C2=A0

The above text suggests to me that if the O-bit is s= et and the next protocol is not active SFC OAM then it is *required*= that OAM data will be in the NSH context headers (which is not the case fo= r iOAM) and the next protocol will indicate what follows the NSH header. While iOAM does follow the NSH heade= r as indicated by the next protocol there is still an expectation that OAM = is also carried in the NSH context headers. This seems to be in conflict wi= th RFC 8300 AND RFC 8924.

=C2=A0

This of course is just my reading of the text and I = would like to hear yours and other folks thoughts.

=C2=A0

Jim

=C2=A0

From: Shwetha Bhandari <shwetha.bhandari@though= tspot.com>
Sent: Monday, January 31, 2022 11:25 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: James Guichard <james.n.guichard@futurewei.com>; draft-ietf-sfc-io= am-nsh@ietf.org; sfc@= ietf.org; sfc-= chairs@ietf.org
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh= /

=C2=A0

Hi Greg,

=C2=A0

Sorry for the late action on this. https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 has be= en now posted with the edits per this discussion.=C2=A0

=C2=A0

Hi Jim,

=C2=A0

After Greg's review please let us know if the ch= anges are good to progress the draft to the next step.

=C2=A0

Thanks,

Shwetha

=C2=A0

On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

Hi Shwetha,

thank you for the detailed response to my comments. = Please feel free to share any updates you're considering for the next v= ersion. I'll be glad to work together on these.

I have several follow-up notes in-lined below under = the GIM>> tag.

=C2=A0

Regards,

Greg

=C2=A0

On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari <= ;shwe= tha.bhandari@thoughtspot.com> wrote:

= Hi Greg,

=C2=A0

= Sorry for the very late reply. Please find responses to your comments inlin= e @Shwetha:

=C2=A0

=C2=A0

=C2=A0

On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <gregimirsky@gmail.com= > wrote:

Dear Authors and All,

I've read the current version of the draft and h= ave some comments I'd like to share with you. I much appreciate your th= oughts on where this work should go considering developments in other IETF = WGs. Please find my notes and questions below:

  • It is stated in the Abstract that:

=C2=A0 =C2=A0In-situ Operations, Administration, and= Maintenance (IOAM) records
=C2=A0 =C2=A0operational and telemetry information in the packet while the = packet
=C2=A0 =C2=A0traverses a path between two points in the network.<= /u>

But that is the case only for the pre-allocated and = incremental trace option=C2=A0types. The Direct Export option does not write telemetry=C2=A0data into the data p= acket itself but export telemetry information in a specially constructed pa= cket.=C2=A0

And as we are talking about different IOAM trace opt= ions, the question=C2=A0of the scope of this document seems appropriate. Th= ere is a WGLC on two IOAM documents active through September 15th at the IPPM = WG. I believe that it would be beneficial if we had a single document that = describes the applicability of IOAM in all its functionality defined by doc= uments in IPPM WG. Of course, that cannot be a moving target as that would not be helpful. But since the IPPM= WG discusses the progress of two IOAM documents, it could be a great time = to address the applicability of the Direct Export trace type and Loopback and Active flags defined in= =C2=A0draft-ietf-ippm-ioam-flags. It would be concerning to have more than one SFC document describing the a= pplicability of the generic IOAM mechanisms

=C2=A0

= Shwetha> This is a fair point. We will revise the=C2=A0 draft with text = in the abstract and Section 3 IOAM-Type=C2=A0to be updated to include the usage of trace and DEX options.=C2=A0 The encapsulation of IOAM options within NSH = itself in its current form already supports all the IOAM Option Type define= d both from draft-i= etf-ippm-ioam-data and=C2=A0draft-ietf-ippm-ioam-direct-export along with the flags supported within the options. Hence the IOAM-data-fie= ld definitions in the draft will remain unchanged.=C2=A0

GIM>> I agree that the definitions of the IOAM= data-fields are invariant in various data plane encapsulations. You likely= follow the discussion of the IAOM Direct Export and IOAM flags on the IPPM= WG list. I think that for SFC NSH, IOAM Direct Export could be as simple as "use the local policy". The = applicability of the Loopback and Active flags seems to require detailed ex= planation by SFP actors.

=C2=A0

=C2=A0

  • The location of the IOAM header in the SFC NSH-encapsulated=C2=A0packet is = defined in Section 3:

=C2=A0 =C2=A0IOAM-Data-Fields are carried in NSH<= /u>

=C2=A0 =C2=A0using a next protocol header which foll= ows the NSH MD context

=C2=A0 =C2=A0headers.

I've checked RFC 8300 but couldn't find it d= efines the Next Protocol header. Also, it appears that NSH Context headers= =C2=A0are optional. Hence my question. Is the presence of an NSH Context he= ader required when using IOAM? Could you clarify which mechanism is used to identify the payload of an SFC NSH-encapsulated= packet as IOAM?

= Shwetha> We will reword it, it is not Next Protocol header but using IOA= M as a Next Protocol as described in Section 4.1 and requested in IANA sect= ion. Following is the proposed text to align with the RFC 8300 reference to context headers following base header and servic= e path header:

= "The NSH is defined in [RFC8300].=C2=A0 IOAM-Data-Fields are carried i= n NSH=C2=A0using a next protocol to identify IOAM data fields that follows = NSH context headers."

GIM>> I think that RFC 8300 views data followi= ng Context Headers as NSH payload, not being "in NSH".=C2=A0

  • If I understand the format of the IOAM header defined in Section 3 correctl= y, the header's length is limited by 1020 octets, while the effective l= ength containing IOAM options and data - 1016 octets. Is that correct? What= is the recommended technique of collecting IOAM data that exceeds that limit?

= Shwetha > IOAM options inherently support specifying the size limits at = the node that added the IOAM options. While operationalizing the solution t= he data types included and number of nodes expected to be adding the data should be selected. This is covered in deployment co= nsiderations=C2=A0draft-brockners-opsawg-ioam-deployment.<= /u>

  • In Section 4.1, I've found the text reflecting the history of the discu= ssion about how to carry the IOAM header using NSH encapsulation. As the te= xt has no normative value, I suggest moving it into an Appendix.<= /u>

= Shwetha > Agreed, revised draft will have this section moved to Appendix= .=C2=A0

GIM>> Thank you.=C2=A0

  • I find the rules of handling the O-bit in NSH listed in Section 4.2 inconsi= stent and confusing. The IOAM header is not part of NSH encapsulation but i= s a part of the payload. But in one case, when user data follows it, the O-= bit must not be set as. If there's no user data after the IOAM header, then the O-bit must be set. But from t= he perspective of NSH encapsulation, it includes specially constructed data= added for the sole purpose of collecting OAM/telemetry information. Then, = why, in one case, the O-bit is cleared and in the other set if, in both cases, the NSH-encapsulated packet is use= d to perform the OAM function?

= Shwetha > The reason for not setting the O-bit for packets that contains= actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier implementations that do not support

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 SFC OAM procedures SHOULD discard packets with O bit set=
". It will be undesirable to discard packets with O-bit set that carry=
 user data as IOAM can be inserted insitu.
For synthetic =
traffic created for OAM along with IOAM-data-fields in NSH following the NS=
H OAM function with 0-bit set is desirable.=C2=A0

=C2=A0GIM>> This is an interesting situation. = I agree that there could be an SFC element not supporting "SFC OAM pro= cedures" (not clear what these are). By the same token, would such SFC= element support IOAM, be capable of processing IOAM without adverse impact to user data? I am not certain and it seems that it might b= e better to recommend that NSH packets with IOAM be dropped by an SFP eleme= nt if it does not support "SFC OAM". What are your thoughts?

=C2=A0

=C2=A0

= Thanks,

= Shwetha=C2=A0

I much appreciate your consideration of my comments = and questions and looking forward to your feedback.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Aug 18, 2021 at 5:32 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

Dear WG:

=C2=A0

This email starts a 2 week Working Group Last Call f= or draft-ietf-sfc-ioam-nsh [1].

=C2=A0

Please read this document if you haven=E2=80=99t rea= d the most recent version and send your comments to the SFC WG list no late= r than September 1st 2021.

=C2=A0

If you are raisi= ng a point which you expect will be specifically debated on the mailing lis= t, consider using a specific email/thread for this point.<= /u>

=C2=A0=

Lastly, if you a= re an author or contributor please response to indicate whether you know of= any undisclosed IPR related to this document.

=C2=A0

Thanks!

=C2=A0

Jim & Joel

=C2=A0

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/=

=C2=A0

=C2=A0

=C2=A0

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

--000000000000f6bcf305d70b82a2-- From nobody Wed Feb 2 10:36:46 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF193A19D0; Wed, 2 Feb 2022 10:36:35 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUSV66V7mHzn; Wed, 2 Feb 2022 10:36:30 -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 AE2383A19D5; Wed, 2 Feb 2022 10:36:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RLwmwN5xu0D8a5+o5g59iIGO9xZG4lq3pRfEMQfLtl/PRBAjrXnFIoBdi05belhfgo+l1mCBHdIa1w04AeozwNu7wFKJZGn+Sqd7P5rK2KGxJRnJzgwBP9XCJQLy4FSs6zMJGMl5h9mgTa5lkkLETmToN9/f13GBM4Cj7nd56QzL/OquRYLxwLLhWdggertVHORaJqRoxBvCVcW3mN2RsD+12jf5CGabHJAXVLz8d5mChJnr3wBkVJ8FdaBHQFR1GsB8P4ofPANNXXqEZ1GL/Lm5Iy7L43IUBmh4O9Lt5ieLuR9J4G/2CjKmCo5hr+podJzmQjr0Wf/MsbTo18VWyQ== 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=W7nuZwNkoB6KEkI9Tgs+o1sfbNC2bnvFduIJDMh5OKU=; b=O/jFsYbwEsExMt0/XwTRVyGTvShBXwlGiOEPxIyv+akFcpWW01DSfV6cd02+2sdf63iW1zqHfuSRFFuUMIVbqfwSuFQ0zOOq8RshDC3K6KpZt6Y9vnKa0BU3ZkERJh8M1WlNN3rAU1P0aQn8Gfn9UpQZw1KymB4KsfIje+k6/JktdEfJnRbrBnvGof3hLA800wXysaZbCNDEZNrIvqFVfuC+Y+7/JcWPyZ/AvJWlQrtlVxPjT5nzeO9D6tbg/ZkSX2X2a3qMn5sbubP2TKhazVRam1EbUShu1R/syQO/1QOjy+KbZnjxhackhvm12epT/62C9QiJp3QQ/NHdHojcMA== 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=W7nuZwNkoB6KEkI9Tgs+o1sfbNC2bnvFduIJDMh5OKU=; b=gcIbybs1eAPvXlsCwDBBHYpNJAzuTmiX/02EAwn4nv3UkliXwOXHdv/x/K4OpH2yGzzBxp1UeRQlJU2v+6Ge/LLkPBudC72NSSJQ6Ku5EigBj/jNiGF4i5Uv+CIfvjViqEmc2E8vMn7JefUndQjhxw39Bo5q9Q0B8PYsuUlG6Vk= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by MN2PR13MB2832.namprd13.prod.outlook.com (2603:10b6:208:f1::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.11; Wed, 2 Feb 2022 18:36:26 +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.4951.012; Wed, 2 Feb 2022 18:36:26 +0000 From: James Guichard To: "sfc@ietf.org" CC: "sfc-chairs@ietf.org" Thread-Topic: Progression of OAM work in the SFC WG Thread-Index: AdgYYtG+l/ju054uSCa0IEDodR5p4A== Date: Wed, 2 Feb 2022 18:36:26 +0000 Message-ID: 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: 59c233d7-13a9-4873-aec6-08d9e67aebe3 x-ms-traffictypediagnostic: MN2PR13MB2832: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: bohp8rR4hVP6lmtFLd1JqVCz/ayCf3bj2OIT/wB6hIN2RpvOVU2D2orVxfnUBQ0V+gGRyTGppsGzQO9uHWmcHoJmfNCfF+jKaWJAHIWCVpnTnu8HtIYrPM5tBXih/7k/1U2JulPPleitZuCRyYrVc5jvnvlX1n+BydGr5qosjbx8Ed0wSADCpe91WB2koRJFsBqTLpi5zLb2KIC9i5lM4Rmu/cOcBlOwtfwotGfK23J8X1mLUs0TVhxMtCmLIplq4JoendAGkmKsDkgctb7kvahCHkPZYDRvxyRbU3s2+1mobqMnwb9d/g47seRu2TU5KVTdXeqTQzFya42LM0W1OaFApgx6Wc9HohHYIVkMeE/zv6sFRy0CYaivf7IVbeYF1PHJerQcaXQrXkqBvSTY+TI+ryt2RLGKO0uy+kqPu3zotBk3Lz1lS7pvOF2YDCnkaxBnWlaQRXUATySm9PZS5xa9wanajdqknJuPBvD9g8CVPdh8TZ6DSA7XLHjEPUFFlTheqV+kLjrBErPiW7CXzpZ08XC7zC0tEmFoaTrQenlcjrmoKwER+vfpN9cXYEX+XbO/bBKP/60Yf/3DTKvGz4XbfF8w3uA0DAQJ40RrgU15pHgG9CkBZljWandGZDAjMo2ZwUmrI3W5pymUocrG+/DmeKHIZ1/RSN/i3MydwCH1Gw/oi2DcIVPGfKpxgQ4czw0KOuhGrEGgAgMjdqvDEdLCVnFryRQdCTF7zRkMLLTOLEI4K4/zEG9FAreRt6H4 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)(71200400001)(55016003)(66556008)(83380400001)(4326008)(450100002)(186003)(6506007)(7696005)(86362001)(8936002)(8676002)(66446008)(66946007)(508600001)(64756008)(76116006)(33656002)(9686003)(6916009)(316002)(66476007)(2906002)(38100700002)(122000001)(5660300002)(38070700005)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?R7UoM7RDhWYQIVhfLyyM0FDo3iKHCnrCt0KkuXpVYpRgTwCYVilY7SviotEe?= =?us-ascii?Q?8un+OFkQhAZPjVtxWZF0fAjP+/2Bx3cViYB6krBlJh/ENjuPv8I37eooxts4?= =?us-ascii?Q?TNd+rfK4w0m6p0wcVm8D1j+ldgt5Xgvy610v+kWiNGGPebMT0bzl8VW4RHF4?= =?us-ascii?Q?qZnEhMcxWzbFWKGs0+Zib9MH5xL+levIfz8qOXs6PM2ml3HuWCA1GqAX5uTA?= =?us-ascii?Q?2Qo+QfEdXqR8qH2NKWt2pcoc3+iqtlhj4G4vca4IFxNaW0zPu5M+PyA9lKFV?= =?us-ascii?Q?3SLwYJEYNFZqP1RrfI8RZ4BTHuQjCpAuto6Xgsro4zmc1NPgqZmlY7UyWXbC?= =?us-ascii?Q?ii85j6EXEHg5e3KmdfKLiD0qd46Swj7eEQVf0/2hrT6aS1nnmzGQyMTXenMe?= =?us-ascii?Q?10fQAfxKaKWJ/EyXmQUKs3wf5pjOmKhLv/N39p2sAnHWxSVc2L6c3tIJ1wTk?= =?us-ascii?Q?4ERYlRCsFfcQVIhJuexaMGX/TjfI1ZKP2MUpYnaM5WYXxgWr2pP1KWj9IOaF?= =?us-ascii?Q?o8cVi8ev2GuF4htF2PtnT/b/ok+yWewIn61c2qRRP3d2pI2x8HJNvr7DUF1V?= =?us-ascii?Q?+6r4kepxszSIvUssv6P15WR89ngu+D5ZNKN4pJz8869xzeQ0eKOZjkWEvwqD?= =?us-ascii?Q?vJ0TI95D7cjTD2xbndI0K+8B1TzidJM1+g4tz1CdT4BjIZkXlxKpiH1pyJYD?= =?us-ascii?Q?2LpC3sTANEzO9ySNYjCYz8FZXbruRQpkChhlSeYOIVt4YEOQQCpIWHvFj4TY?= =?us-ascii?Q?uCxbi6YQuPolu2dyGtgA3yCTVxEizItKL+cnYDu9cPRaKesWO+RA4hr1IoHP?= =?us-ascii?Q?3mpPntxZAccrrPdBnCdIa9cMioKjwh3I2KUyvADckWcce4pVe7Meq+mbfNpP?= =?us-ascii?Q?iisLYNZOBMBQjK6Wb0KEXPTRXPdFP2zGVTr/EWunZjHtDg9VjT+za4cs9p8s?= =?us-ascii?Q?AXx147QbeoH+Ett6HeA+9DC8aQ5jIeULgQQxfGqtuomYgolDRWNkxOi/nLEv?= =?us-ascii?Q?mJWJ82M3qCfAFVTgW2ybuZsP1EOYENhfXMf1/6/NX5mrxtuRHu3yr3dOTBr3?= =?us-ascii?Q?SmpXFqQTzgfa4Rbh35xCEr+xxGjXdSZcMqEw6J3HKTNLvWYm2zT4NaQ0wVcB?= =?us-ascii?Q?LJ1ojajCQlQXVHwZiMUxEbcDASWATh2z23ONu+DegUSvmd11/JPxJICN3TQE?= =?us-ascii?Q?4CRBPqHybT7z7xvH5Yi4XHDiDSzs2wdPlX+mJKky1zKiqACrZKtrPOAdTJ9X?= =?us-ascii?Q?TEz/zXxF198hhTMOln+TSIAyJj5Odc3sCHvmD2zIrY5N76CNPWPZeknwcpxU?= =?us-ascii?Q?H/pdoEt7P8KYwGHeZdA2Kd69oM6K2U+q8LaipvUwbVLyb2CDizTL7E/qXv6/?= =?us-ascii?Q?IimovzUJR+FjUXS4Ca2RJD2Ump6gkItOWXl3amwMlUFD3I0bcP5WQNvlXa/S?= =?us-ascii?Q?2yrmm2fcylMABQSKXnjtkkg3UXTPy+JxGEx3CBsCf2Vq1EySA2ox8J/AOhKY?= =?us-ascii?Q?MsZLKOQmvQFVe4rwcbHXR3P8/Q7Zu8nz/IBf8u9TAkRngLC81Z/KoWTOJkK7?= =?us-ascii?Q?1HAAA+b4NpftDGatHBWzQNSkrgNbRule9izMg5+6j5xuW3qh8+tjvWmQXN1p?= =?us-ascii?Q?vA1goWW/OgerSWVs9bJvFB34RkCdqFNmi60EyEcia31fuLZgJ4KM1vLCQ7Jx?= =?us-ascii?Q?Djy6KDOC7lzVQ2auAca5/vWz/xQ=3D?= Content-Type: multipart/alternative; boundary="_000_MN2PR13MB4206A3B910C9CE55867DA10BD2279MN2PR13MB4206namp_" 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: 59c233d7-13a9-4873-aec6-08d9e67aebe3 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2022 18:36:26.6976 (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: Z0l+VrLoJxVHV7+2b+iZVS9Onteq7Op/OaUWAfVkLFNRw549L//TGSYje1wo7L/vGKYrbhxRvIdZFNkNBkUkVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2832 Archived-At: Subject: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 18:36:44 -0000 --_000_MN2PR13MB4206A3B910C9CE55867DA10BD2279MN2PR13MB4206namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG: Having reviewed all of the OAM related documents in our WG, the chairs woul= d like to provide a few comments to hopefully generate discussion and forwa= rd progress of this work: 1) The chairs have reviewed the O bit definition in RFC 8300. That definit= ion is at best open to interpretation and therefore incomplete. For exampl= e, the clear intention is only to mark packets which are intended for SFC O= AM at the SFC service layer. But that is not what the current text says. = There is also, unfortunately, ambiguity as to what constitutes an OAM packe= t. So it is reasonable for documents to update 8300 to clarify the exact a= pplicability and action for the O-bit. 2) However, related to point 1), we can't have multiple documents updating = the definition differently. As such, the authors of the SFC iOAM draft and= the SFC multi-layer-oam draft need to come together and figure out what th= e clarification is for the definition of that bit. We do not believe as cha= irs that either of these documents can move forward from the WG until such = clarity has been reached. 3) Related to the SFC iOAM, we need a clear definition of iOAM. There seem= to be differences between the definitions in published RFCs, the usage (wh= ich is not a definition) in the SFC draft, and the various ippm drafts. An= y such definition will need to be vetted with the ippm working group. Again, it would be good if members of the working group beyond the two auth= or teams spoke up about their readings of the documents, and their understa= ndings of what we need. Yours, Jim and Joel --_000_MN2PR13MB4206A3B910C9CE55867DA10BD2279MN2PR13MB4206namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG:

 

Having reviewed all of the OAM related documents in = our WG, the chairs would like to provide a few comments to hopefully genera= te discussion and forward progress of this work:

 

1) The chairs have reviewed the O bit definition in = RFC 8300.  That definition is at best open to interpretation and there= fore incomplete.  For example, the clear intention is only to mark pac= kets which are intended for SFC OAM at the SFC service layer.  But that is not what the current text says.  The= re is also, unfortunately, ambiguity as to what constitutes an OAM packet.&= nbsp; So it is reasonable for documents to update 8300 to clarify the exact= applicability and action for the O-bit.

 

2) However, related to point 1), we can't have multi= ple documents updating the definition differently.  As such, the autho= rs of the SFC iOAM draft and the SFC multi-layer-oam draft need to come tog= ether and figure out what the clarification is for the definition of that bit. We do not believe as chairs that either= of these documents can move forward from the WG until such clarity has bee= n reached.

 

3) Related to the SFC iOAM, we need a clear definiti= on of iOAM.  There seem to be differences between the definitions in p= ublished RFCs, the usage (which is not a definition) in the SFC draft, and = the various ippm drafts.  Any such definition will need to be vetted with the ippm working group.

 

Again, it would be good if members of the working gr= oup beyond the two author teams spoke up about their readings of the docume= nts, and their understandings of what we need.

 

Yours,

Jim and Joel

 

 

 

--_000_MN2PR13MB4206A3B910C9CE55867DA10BD2279MN2PR13MB4206namp_-- From nobody Wed Feb 2 14:42:39 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B423A23D3; Wed, 2 Feb 2022 14:42:37 -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 t5EVrdG65pw0; Wed, 2 Feb 2022 14:42:32 -0800 (PST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7E53A23CF; Wed, 2 Feb 2022 14:42:32 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id p15so1830797ejc.7; Wed, 02 Feb 2022 14:42:32 -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=PKpBETFtymaQ7QlbdXIon9JZaaHpY4qgCWsORrYhrZM=; b=nelEYXtHxGazv5GZcIGMoWQzo5ofozXVv0Nst3shyCPKtPXrEsk+jB3XT0qjKax1z5 hakU2kjKxRaRiKfMaghEZ8SBy9zrCha9Lain04kD4q4p/4EGh3XUWGJC4dSvO3HDupnh oYiz3BRb1cutFTLkXQ2H8+ZTUd1E9HKmlbaqrQ3jARKmMKm2q9NAA1t6BxalFdrtGuv2 QVlfvt5diNRK7TZLjyCIXwHW+P4l995VIk+5zw78mrWhbcSd7GzpVJK11q+GcXG0FrrH UceMAqecS5+PR1fmfDznqGbzkpkkHBmydEMS2mtZaOfYTmdoyP4WUB83QxrkbQJtQ6sw eJ9Q== 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=PKpBETFtymaQ7QlbdXIon9JZaaHpY4qgCWsORrYhrZM=; b=PzEkq7XZHlfDW3PYoCvzJR+d3L9Zgzs35Ox47IwlFp2BS9gEbryD3EKumjGhuMGXbj LZMZTziBoOYZVnxDUVIMxq2hijb1UAUrr2IA2UvS5XXtbyWYlz89NPTJkkORs+7UvpxC Wel4WSVOI4G9NT2FP1Lg52KekXm/dlNomyULeLAgcKvA3hIVIvc+gd4E/2V7fpOsdIen 8vYO0rgMnX5kTMUnhMI+5RZshFy6/vn3s5IYgFDntUrSsToQyG5V6bsgWTVJkqxvTzqh G4CJJAkW6QnxI7Vuuw29r63j4SxjKIpkHFBXSMTTkhgoIwMDRw3yj1+dGeB6GAO9WPmJ 3dmQ== X-Gm-Message-State: AOAM532+ri3/plW0nTWe1ObLvhFCGgbZKtWnZehj5dBMuB0p/S6iAnrI RA7w8r3UPRmrDUca0/WNaYyzi7VFRA15UUz1HTpEzA/J X-Google-Smtp-Source: ABdhPJxGCqFzcIAml4k4rjnQI1pZ9NS3r+IQa80PV29UDX2wyXW/PWU4XiIv+i8t1wkI1j9+DPGk9dheWT0kKdxzx/U= X-Received: by 2002:a17:907:6e16:: with SMTP id sd22mr23486609ejc.172.1643841749777; Wed, 02 Feb 2022 14:42:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Wed, 2 Feb 2022 14:42:18 -0800 Message-ID: To: James Guichard Cc: "sfc@ietf.org" , "sfc-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000090001205d710bb60" Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 22:42:37 -0000 --00000000000090001205d710bb60 Content-Type: text/plain; charset="UTF-8" Thank you, Jim and Joel, for guiding the SFC OAM work and pointing out the issue that must be addressed. I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I understand these documents, the Active SFC OAM and IOAM are identified by the respective values for the NSH Next Protocol field (to be assigned by IANA). At the same time, so far no OAM-specific meta data TLV has been defined. Thus, it appears that one way forward could be to not involve the O bit in the active SFC OAM or IOAM altogether. In other words, to deprecate the NSH O bit. I greatly appreciate your comments on the proposal to deprecate the NSH O bit. Regards, Greg On Wed, Feb 2, 2022 at 10:36 AM James Guichard < james.n.guichard@futurewei.com> wrote: > Hi WG: > > > > Having reviewed all of the OAM related documents in our WG, the chairs > would like to provide a few comments to hopefully generate discussion and > forward progress of this work: > > > > 1) The chairs have reviewed the O bit definition in RFC 8300. That > definition is at best open to interpretation and therefore incomplete. For > example, the clear intention is only to mark packets which are intended for > SFC OAM at the SFC service layer. But that is not what the current text > says. There is also, unfortunately, ambiguity as to what constitutes an > OAM packet. So it is reasonable for documents to update 8300 to clarify > the exact applicability and action for the O-bit. > > > > 2) However, related to point 1), we can't have multiple documents updating > the definition differently. As such, the authors of the SFC iOAM draft and > the SFC multi-layer-oam draft need to come together and figure out what the > clarification is for the definition of that bit. We do not believe as > chairs that either of these documents can move forward from the WG until > such clarity has been reached. > > > > 3) Related to the SFC iOAM, we need a clear definition of iOAM. There > seem to be differences between the definitions in published RFCs, the usage > (which is not a definition) in the SFC draft, and the various ippm drafts. > Any such definition will need to be vetted with the ippm working group. > > > > Again, it would be good if members of the working group beyond the two > author teams spoke up about their readings of the documents, and their > understandings of what we need. > > > > Yours, > > Jim and Joel > > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --00000000000090001205d710bb60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, Jim and Joel, for guiding the SFC OAM work and = pointing out the issue that must be addressed.

I've = reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I understand = these documents, the Active SFC OAM and IOAM are identified by the respecti= ve values for the NSH Next Protocol field (to be assigned by IANA). At the = same time, so far no OAM-specific meta data TLV has been defined. Thus, it = appears that one way forward could be to not involve the O bit in the activ= e SFC OAM or IOAM altogether. In other words, to deprecate the NSH O bit.

I greatly appreciate your comments on the proposal = to deprecate the NSH O bit.

Regards,
Gre= g

On Wed, Feb 2, 2022 at 10:36 AM James Guichard <james.n.guichard@futurewei.com> wro= te:

Hi WG:

=C2=A0

Having reviewed all of the OAM related documents in = our WG, the chairs would like to provide a few comments to hopefully genera= te discussion and forward progress of this work:

=C2=A0

1) The chairs have reviewed the O bit definition in = RFC 8300.=C2=A0 That definition is at best open to interpretation and there= fore incomplete.=C2=A0 For example, the clear intention is only to mark pac= kets which are intended for SFC OAM at the SFC service layer.=C2=A0 But that is not what the current text says.=C2=A0 The= re is also, unfortunately, ambiguity as to what constitutes an OAM packet.= =C2=A0 So it is reasonable for documents to update 8300 to clarify the exac= t applicability and action for the O-bit.

=C2=A0

2) However, related to point 1), we can't have m= ultiple documents updating the definition differently.=C2=A0 As such, the a= uthors of the SFC iOAM draft and the SFC multi-layer-oam draft need to come= together and figure out what the clarification is for the definition of that bit. We do not believe as chairs that either= of these documents can move forward from the WG until such clarity has bee= n reached.

=C2=A0

3) Related to the SFC iOAM, we need a clear definiti= on of iOAM.=C2=A0 There seem to be differences between the definitions in p= ublished RFCs, the usage (which is not a definition) in the SFC draft, and = the various ippm drafts.=C2=A0 Any such definition will need to be vetted with the ippm working group.

=C2=A0

Again, it would be good if members of the working gr= oup beyond the two author teams spoke up about their readings of the docume= nts, and their understandings of what we need.

=C2=A0

Yours,

Jim and Joel

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--00000000000090001205d710bb60-- From nobody Wed Feb 2 17:18:42 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B2C3A11A0; Wed, 2 Feb 2022 17:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] 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 ADpmPfUOhEz8; Wed, 2 Feb 2022 17:18:32 -0800 (PST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441ED3A117A; Wed, 2 Feb 2022 17:18:31 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id jx6so3119020ejb.0; Wed, 02 Feb 2022 17:18:31 -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=TPyAvt9GgeemjSZ0e2+jTpDAqdOqX5LDLDK2S8wDnDc=; b=m0TDeUtNkrjni0EAG9ZxSpxSj058B61l3gzmy+DVDjyOQDXZa8e1b0KFw3dXXEDFR1 I05s8SbjAVtiryMuzp8NK9wGcxMNtHufrqgDAU18zwwAPVelKzY7tNkZZxa79h9I5oJn KDDWmubriuTVFAti+k1OKBTYTYpS12PJJy6l0gF0zOK/ymRIrXec55R9rV9oR1ybs72v iX++ArGWQJP3hKr1Gfd7QODOX8p0pSf/R/PfwhOD6RwXevwDNTBljIrr7bneSulBDCvi cCRgaZYRU6KXA6wKfQbpky9Am0+pY2LvoNoAq8Da/C5wQpyNuVgcBrYt/h45MToL7/VO MaSA== 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=TPyAvt9GgeemjSZ0e2+jTpDAqdOqX5LDLDK2S8wDnDc=; b=xSNlQH3f31Ui6J4UQCkDbjgRYNiaao454tCeCFK9T0j6ZcwAgQoieLPcWRP4j0z3sc B5+IPY4wlxuuoTU3Y+Z3EEH6xlonW+8vZk3Wj5OMAFGqSahREIfd8k4eTXKff5pExSj0 MT2U45hoKYCFzp3lcBvTh/3z/TEcl+OYL4xW1/Y3vBi7byL8QR6CC4ifRbkwvAVQq/Od V+Qo1G7/wbnyoIdsEL4fZqiV6oPlI5pVmSiNFfahzX3kGtXCHRRlg6Gi3kEo6+l+I41y imkPu8MlBWiY8BTDl1YzROt+Vmbamh0lDxhfd+y7VKP4sG974Ff90sPLYx5idEBsM8q2 d3Rg== X-Gm-Message-State: AOAM533EsZOeK9jCM5xueAhPcJbPWXRRYfoq8zA1KLTZVIWnxFASjMz+ 8icvL7GmJBYdFaZ73UQnGB0qXn+hU5bQ2KeE6P82xM/UQY8= X-Google-Smtp-Source: ABdhPJxLEQgzUInmbq8fy+XsLhCAt+cqpdYBDaBZPeJy4o4px62PJvRKJca6YgRBjHNiP93ppCZH9AtQex/bD9pxJYQ= X-Received: by 2002:a17:907:72d2:: with SMTP id du18mr26898999ejc.506.1643851108545; Wed, 02 Feb 2022 17:18:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Wed, 2 Feb 2022 17:18:16 -0800 Message-ID: To: Shwetha Bhandari Cc: James Guichard , "draft-ietf-sfc-ioam-nsh@ietf.org" , "sfc@ietf.org" , "sfc-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006376fe05d712e9a0" Archived-At: Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 01:18:40 -0000 --0000000000006376fe05d712e9a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Shwetha, I have one more question. As the draft now mentions the option of using IOAM Direct Export to collect the IOAM data, it might be helpful reflecting that in the figure on p.2. I think that the caption "IOAM Option and Data Space" might be reworded to "IOAM Option and Optional Data Space". What are your thoughts? Regards, Greg On Wed, Feb 2, 2022 at 7:29 AM Shwetha Bhandari < shwetha.bhandari@thoughtspot.com> wrote: > Hi Jim, Greg, > > Thanks for the follow up. > 1) On O-bit: I am a bit confused about the O-bit feedback. Are you > suggesting that it should not be a consideration for IOAM as it is handle= d > as a next protocol and not as NSH context headers? > What should a SFC element handle a packet containing IOAM as next header > and does not implement IOAM and hence does not understand IOAM? I think > O-bit helps in such situations to help such elements decide to drop or > forward without processing the IOAM header. > Let me know if that is not the case and if simply not considering O-bit i= n > the context of IOAM is what you would recommend. > 2) Active or Loopback flags > - > there is nothing specific for NSH on how the flags are to be handled. Th= e > IOAM specific fields are to be handled as recommended by the respective > IOAM drafts. Do you see any specific NSH considerations to be documented > for IOAM fields? > > Thanks, > Shwetha > > > > > > > > On Tue, Feb 1, 2022 at 4:29 PM James Guichard < > james.n.guichard@futurewei.com> wrote: > >> Hi Shwetha & Greg, >> >> >> >> Thank you for the update. >> >> >> >> I still believe however that more work is necessary to reconcile how SFC >> OAM is supposed to work. RFC 8300 says: >> >> >> >> O bit: Setting this bit indicates an OAM packet (see [RFC6291 >> >> ]). >> >> The actual format and processing of SFC OAM packets is outside the >> >> scope of this specification (for example, see [SFC-OAM-FRAMEWORK >> >> ] >> >> for one approach). >> >> >> >> The O bit MUST be set for OAM packets and MUST NOT be set for >> >> non-OAM packets. >> >> >> >> If we look at RFC6291 it simply describes what OAM is supposed to mean >> and this is independent from SFC. The SFC-OAM-Framework (now RFC 8924) i= n >> section 6.3 says: >> >> >> >> The Next Protocol field in the NSH header may be used to indicate wha= t >> OAM function is intended >> >> or what toolset is used. Any other overlay encapsulations used at th= e >> service layer must have a >> >> similar way to indicate the intended OAM function. >> >> >> >> So my reading of this is that if you take 8300 together with the >> framework then 1. The O-bit MUST be set for OAM packets, and 2. The Next >> Protocol field may or may not be used to indicate which OAM function is = to >> be applied. From this I can determine that iOAM has taken the approach o= f >> using the next protocol field to indicate how to process the OAM packet = and >> does NOT use the NSH context headers in any way shape or form. This seem= s >> consistent with the current definitions of the O-bit from RFC 8300 and >> processing guidelines from RFC 8924. >> >> >> >> However, your document says: >> >> >> >> *4.1 >> . >> IOAM and the use of the NSH O-bit* >> >> >> >> [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300 >> ] >> the O >> >> bit must be set for OAM packets and must not be set for non-OAM >> >> packets. Packets with IOAM data included MUST follow this >> >> definition, i.e. the O bit MUST NOT be set for regular customer >> >> traffic which also carries IOAM data and the O bit MUST be set for >> >> OAM packets which carry only IOAM data without any regular data >> >> payload. >> >> >> >> This text basically says that if the packet is customer traffic and >> happens to carry iOAM data then it is NOT an OAM packet. What am I >> missing, customer traffic or not, both carry iOAM data so how are they >> different within an SFC domain? >> >> >> >> In addition to the above I will note that there is still a conflict with >> Greg=E2=80=99s draft namely this text from section 4: >> >> * O bit set and the "Next Protocol" value does not match the value >> >> Active SFC OAM (TBA1), defined in Section 10.1 >> >> : >> >> >> >> - An SFC NSH Context Header(s) contain an OAM processing >> >> instructions or data. >> >> >> >> - The "Next Protocol" field determines the type of the payload. >> >> >> >> The above text suggests to me that if the O-bit is set and the next >> protocol is not active SFC OAM then it is **required** that OAM data >> will be in the NSH context headers (which is not the case for iOAM) and = the >> next protocol will indicate what follows the NSH header. While iOAM does >> follow the NSH header as indicated by the next protocol there is still a= n >> expectation that OAM is also carried in the NSH context headers. This se= ems >> to be in conflict with RFC 8300 AND RFC 8924. >> >> >> >> This of course is just my reading of the text and I would like to hear >> yours and other folks thoughts. >> >> >> >> Jim >> >> >> >> *From:* Shwetha Bhandari >> *Sent:* Monday, January 31, 2022 11:25 PM >> *To:* Greg Mirsky >> *Cc:* James Guichard ; >> draft-ietf-sfc-ioam-nsh@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org >> *Subject:* Re: [sfc] WGLC for >> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >> >> >> >> >> Hi Greg, >> >> >> >> Sorry for the late action on this. >> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 >> >> has been now posted with the edits per this discussion. >> >> >> >> Hi Jim, >> >> >> >> After Greg's review please let us know if the changes are good to >> progress the draft to the next step. >> >> >> >> Thanks, >> >> Shwetha >> >> >> >> On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky >> wrote: >> >> Hi Shwetha, >> >> thank you for the detailed response to my comments. Please feel free to >> share any updates you're considering for the next version. I'll be glad = to >> work together on these. >> >> I have several follow-up notes in-lined below under the GIM>> tag. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari < >> shwetha.bhandari@thoughtspot.com> wrote: >> >> Hi Greg, >> >> >> >> Sorry for the very late reply. Please find responses to your comments >> inline @Shwetha: >> >> >> >> >> >> >> >> On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky wrote= : >> >> Dear Authors and All, >> >> I've read the current version of the draft and have some comments I'd >> like to share with you. I much appreciate your thoughts on where this wo= rk >> should go considering developments in other IETF WGs. Please find my not= es >> and questions below: >> >> - It is stated in the Abstract that: >> >> In-situ Operations, Administration, and Maintenance (IOAM) records >> operational and telemetry information in the packet while the packet >> traverses a path between two points in the network. >> >> But that is the case only for the pre-allocated and incremental trace >> option types. The Direct Export option >> >> does not write telemetry data into the data packet itself but export >> telemetry information in a specially constructed packet. >> >> And as we are talking about different IOAM trace options, the question o= f >> the scope of this document seems appropriate. There is a WGLC on two >> IOAM documents >> >> active through September 15th at the IPPM WG. I believe that it would be >> beneficial if we had a single document that describes the applicability = of >> IOAM in all its functionality defined by documents in IPPM WG. Of course= , >> that cannot be a moving target as that would not be helpful. But since t= he >> IPPM WG discusses the progress of two IOAM documents, it could be a grea= t >> time to address the applicability of the Direct Export trace type >> >> and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags >> . >> It would be concerning to have more than one SFC document describing the >> applicability of the generic IOAM mechanisms >> >> >> >> Shwetha> This is a fair point. We will revise the draft with text in th= e >> abstract and Section 3 IOAM-Type to be updated to include the usage of >> trace and DEX options. The encapsulation of IOAM options within NSH its= elf >> in its current form already supports all the IOAM Option Type defined bo= th >> from draft-ietf-ippm-ioam-data and draft-ietf-ippm-ioam-direct-export >> along with the flags supported within the options. Hence the >> IOAM-data-field definitions in the draft will remain unchanged. >> >> GIM>> I agree that the definitions of the IOAM data-fields are invariant >> in various data plane encapsulations. You likely follow the discussion o= f >> the IAOM Direct Export and IOAM flags on the IPPM WG list. I think that = for >> SFC NSH, IOAM Direct Export could be as simple as "use the local policy"= . >> The applicability of the Loopback and Active flags seems to require >> detailed explanation by SFP actors. >> >> >> >> >> >> >> - The location of the IOAM header in the SFC NSH-encapsulated packet >> is defined in Section 3: >> >> IOAM-Data-Fields are carried in NSH >> >> using a next protocol header which follows the NSH MD context >> >> headers. >> >> I've checked RFC 8300 but couldn't find it defines the Next Protocol >> header. Also, it appears that NSH Context headers are optional. Hence my >> question. Is the presence of an NSH Context header required when using >> IOAM? Could you clarify which mechanism is used to identify the payload = of >> an SFC NSH-encapsulated packet as IOAM? >> >> Shwetha> We will reword it, it is not Next Protocol header but using IOA= M >> as a Next Protocol as described in Section 4.1 and requested in IANA >> section. Following is the proposed text to align with the RFC 8300 >> reference to context headers following base header and service path head= er: >> >> "The NSH is defined in [RFC8300]. IOAM-Data-Fields are carried in >> NSH using a next protocol to identify IOAM data fields that follows NSH >> context headers." >> >> GIM>> I think that RFC 8300 views data following Context Headers as NSH >> payload, not being "in NSH". >> >> >> - If I understand the format of the IOAM header defined in Section 3 >> correctly, the header's length is limited by 1020 octets, while the >> effective length containing IOAM options and data - 1016 octets. Is t= hat >> correct? What is the recommended technique of collecting IOAM data th= at >> exceeds that limit? >> >> Shwetha > IOAM options inherently support specifying the size limits at >> the node that added the IOAM options. While operationalizing the solutio= n >> the data types included and number of nodes expected to be adding the da= ta >> should be selected. This is covered in deployment >> considerations draft-brockners-opsawg-ioam-deployment. >> >> >> - In Section 4.1, I've found the text reflecting the history of the >> discussion about how to carry the IOAM header using NSH encapsulation= . As >> the text has no normative value, I suggest moving it into an Appendix= . >> >> Shwetha > Agreed, revised draft will have this section moved to Appendix= . >> >> GIM>> Thank you. >> >> >> - I find the rules of handling the O-bit in NSH listed in Section 4.2 >> inconsistent and confusing. The IOAM header is not part of NSH >> encapsulation but is a part of the payload. But in one case, when use= r data >> follows it, the O-bit must not be set as. If there's no user data aft= er the >> IOAM header, then the O-bit must be set. But from the perspective of = NSH >> encapsulation, it includes specially constructed data added for the s= ole >> purpose of collecting OAM/telemetry information. Then, why, in one ca= se, >> the O-bit is cleared and in the other set if, in both cases, the >> NSH-encapsulated packet is used to perform the OAM function? >> >> Shwetha > The reason for not setting the O-bit for packets that contains >> actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier >> implementations that do not support >> >> SFC OAM procedures SHOULD discard packets with O bit set". It will= be undesirable to discard packets with O-bit set that carry user data as I= OAM can be inserted insitu. >> >> For synthetic traffic created for OAM along with IOAM-data-fields in NSH= following the NSH OAM function with 0-bit set is desirable. >> >> GIM>> This is an interesting situation. I agree that there could be an >> SFC element not supporting "SFC OAM procedures" (not clear what these ar= e). >> By the same token, would such SFC element support IOAM, be capable of >> processing IOAM without adverse impact to user data? I am not certain an= d >> it seems that it might be better to recommend that NSH packets with IOAM= be >> dropped by an SFP element if it does not support "SFC OAM". What are you= r >> thoughts? >> >> >> >> >> >> Thanks, >> >> Shwetha >> >> I much appreciate your consideration of my comments and questions and >> looking forward to your feedback. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Wed, Aug 18, 2021 at 5:32 AM James Guichard < >> james.n.guichard@futurewei.com> wrote: >> >> Dear WG: >> >> >> >> This email starts a 2 week Working Group Last Call for >> draft-ietf-sfc-ioam-nsh [1]. >> >> >> >> Please read this document if you haven=E2=80=99t read the most recent ve= rsion and >> send your comments to the SFC WG list no later than September 1st 2021. >> >> >> >> If you are raising a point which you expect will be specifically debated >> on the mailing list, consider using a specific email/thread for this poi= nt. >> >> >> >> Lastly, if you are an author or contributor please response to indicate >> whether you know of any undisclosed IPR related to this document. >> >> >> >> Thanks! >> >> >> >> Jim & Joel >> >> >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >> >> >> >> >> >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> --0000000000006376fe05d712e9a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Shwetha,
I have o= ne more question. As the draft now mentions the option of using IOAM Direct= Export to collect the IOAM data, it might be helpful reflecting that in th= e figure on p.2. I think that the caption "IOAM Option and Data Space&= quot; might be reworded=C2=A0to "IOAM Option and Optional Data Space&q= uot;.
What are your thoughts?

Regards,
Greg

On Wed, Feb 2, 2022 at 7:29 AM Shwetha Bhand= ari <shwetha.bhandar= i@thoughtspot.com> wrote:
Hi Jim, Greg,

Tha= nks for the follow up.
1) On O-bit: I am a bit confused about the= O-bit feedback. Are you suggesting that it should not be a consideration f= or IOAM as it is handled as a next protocol and not as NSH context headers?=
What should a SFC element handle a packet containing IOAM as nex= t header and does not implement IOAM and hence does not understand IOAM? I = think O-bit helps in such situations to help such elements decide to drop o= r forward without processing the IOAM header.
Let me know if that= is not the case and if simply not considering O-bit in the context of IOAM= is what you would recommend.
2) Active or Loopback flags=C2=A0- there is = nothing specific=C2=A0for NSH on how the flags are to be handled.=C2=A0 The= IOAM specific fields are to be handled as recommended by the respective IO= AM drafts. Do you see any specific NSH considerations to be documented for = IOAM fields?

Thanks,
Shwetha
<= br>




<= br>

On Tue, Feb 1, 2022 at 4:29 PM James Guichard <james.n.guicha= rd@futurewei.com> wrote:

Hi Shwetha & Greg,

=C2=A0

Thank you for the update.

=C2=A0

I still believe however that more work is necessary = to reconcile how SFC OAM is supposed to work. RFC 8300 says:

=C2=A0

=C2=A0=C2=A0 O bit:=C2=A0 Setting this bit indic= ates an OAM packet (see [RFC6291]).<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The actual format= and processing of SFC OAM packets is outside the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scope of this spe= cification (for example, see [SFC-OAM-FRAMEWORK]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for one approach)= .

=C2=A0

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0The O bit MUST be= set for OAM packets and MUST NOT be set for

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 non-OAM packets.<= u>

=C2=A0

If we look at RFC6291 it simply describes what OAM i= s supposed to mean and this is independent from SFC. The SFC-OAM-Framework = (now RFC 8924) in section 6.3 says:

=C2=A0

=C2=A0=C2=A0 The Next Protocol field in the NSH = header may be used to indicate what OAM function is intended<= /span>

=C2=A0=C2=A0 or what toolset is used.=C2=A0 Any = other overlay encapsulations used at the service layer must have a

=C2=A0=C2=A0=C2=A0similar way to indicate the in= tended OAM function.

=C2=A0

So my reading of this is that if you take 8300 toget= her with the framework then 1. The O-bit MUST be set for OAM packets, and 2= . The Next Protocol field may or may not be used to indicate which OAM func= tion is to be applied. From this I can determine that iOAM has taken the approach of using the next protocol = field to indicate how to process the OAM packet and does NOT use the NSH co= ntext headers in any way shape or form. This seems consistent with the curr= ent definitions of the O-bit from RFC 8300 and processing guidelines from RFC 8924.

=C2=A0

However, your document says:

=C2=A0

4.1.=C2=A0 IOAM and the use of the N= SH O-bit

=C2=A0

=C2=A0=C2=A0 [RFC8300] defines an "O bit&qu= ot; for OAM packets.=C2=A0 Per [RFC8300] the O

=C2=A0=C2=A0 bit must be set for OAM packets and= must not be set for non-OAM

=C2=A0=C2=A0 packets.=C2=A0 Packets with IOAM da= ta included MUST follow this

=C2=A0=C2=A0 definition, i.e. the O bit MUST NOT= be set for regular customer

=C2=A0=C2=A0 traffic which also carries IOAM dat= a and the O bit MUST be set for

=C2=A0=C2=A0 OAM packets which carry only IOAM d= ata without any regular data

=C2=A0=C2=A0 payload.

=C2=A0

This text basically says that if the packet is custo= mer traffic and happens to carry iOAM data then it is NOT an OAM packet.=C2= =A0 What am I missing, customer traffic or not, both carry iOAM data so how= are they different within an SFC domain?

=C2=A0

In addition to the above I will note that there is s= till a conflict with Greg=E2=80=99s draft namely this text from section 4:<= span style=3D"font-size:10pt;font-family:"Courier New";color:blac= k">

=C2=A0=C2=A0 *=C2=A0 O bit set and the "Nex= t Protocol" value does not match the value

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Active SFC OAM (T= BA1), defined in Section 10.1:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - An SFC NSH Context Header(s) contain an OAM processing

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= instructions or data.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - The "Next Protocol" field determines the type of the payload.<= u>

=C2=A0

The above text suggests to me that if the O-bit is s= et and the next protocol is not active SFC OAM then it is *required*= that OAM data will be in the NSH context headers (which is not the case fo= r iOAM) and the next protocol will indicate what follows the NSH header. While iOAM does follow the NSH heade= r as indicated by the next protocol there is still an expectation that OAM = is also carried in the NSH context headers. This seems to be in conflict wi= th RFC 8300 AND RFC 8924.

=C2=A0

This of course is just my reading of the text and I = would like to hear yours and other folks thoughts.

=C2=A0

Jim

=C2=A0

From: Shwetha Bhandari <shwetha.bhandari@though= tspot.com>
Sent: Monday, January 31, 2022 11:25 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: James Guichard <james.n.guichard@futurewei.com>; draft-ietf-sfc-io= am-nsh@ietf.org; sfc@= ietf.org; sfc-= chairs@ietf.org
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh= /

=C2=A0

Hi Greg,

=C2=A0

Sorry for the late action on this. https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 has be= en now posted with the edits per this discussion.=C2=A0

=C2=A0

Hi Jim,

=C2=A0

After Greg's review please let us know if the ch= anges are good to progress the draft to the next step.

=C2=A0

Thanks,

Shwetha

=C2=A0

On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

Hi Shwetha,

thank you for the detailed response to my comments. = Please feel free to share any updates you're considering for the next v= ersion. I'll be glad to work together on these.

I have several follow-up notes in-lined below under = the GIM>> tag.

=C2=A0

Regards,

Greg

=C2=A0

On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari <= ;shwe= tha.bhandari@thoughtspot.com> wrote:

= Hi Greg,

=C2=A0

= Sorry for the very late reply. Please find responses to your comments inlin= e @Shwetha:

=C2=A0

=C2=A0

=C2=A0

On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <gregimirsky@gmail.com= > wrote:

Dear Authors and All,

I've read the current version of the draft and h= ave some comments I'd like to share with you. I much appreciate your th= oughts on where this work should go considering developments in other IETF = WGs. Please find my notes and questions below:

  • It is stated in the Abstract that:

=C2=A0 =C2=A0In-situ Operations, Administration, and= Maintenance (IOAM) records
=C2=A0 =C2=A0operational and telemetry information in the packet while the = packet
=C2=A0 =C2=A0traverses a path between two points in the network.<= /u>

But that is the case only for the pre-allocated and = incremental trace option=C2=A0types. The Direct Export option does not write telemetry=C2=A0data into the data p= acket itself but export telemetry information in a specially constructed pa= cket.=C2=A0

And as we are talking about different IOAM trace opt= ions, the question=C2=A0of the scope of this document seems appropriate. Th= ere is a WGLC on two IOAM documents active through September 15th at the IPPM = WG. I believe that it would be beneficial if we had a single document that = describes the applicability of IOAM in all its functionality defined by doc= uments in IPPM WG. Of course, that cannot be a moving target as that would not be helpful. But since the IPPM= WG discusses the progress of two IOAM documents, it could be a great time = to address the applicability of the Direct Export trace type and Loopback and Active flags defined in= =C2=A0draft-ietf-ippm-ioam-flags. It would be concerning to have more than one SFC document describing the a= pplicability of the generic IOAM mechanisms

=C2=A0

= Shwetha> This is a fair point. We will revise the=C2=A0 draft with text = in the abstract and Section 3 IOAM-Type=C2=A0to be updated to include the usage of trace and DEX options.=C2=A0 The encapsulation of IOAM options within NSH = itself in its current form already supports all the IOAM Option Type define= d both from draft-i= etf-ippm-ioam-data and=C2=A0draft-ietf-ippm-ioam-direct-export along with the flags supported within the options. Hence the IOAM-data-fie= ld definitions in the draft will remain unchanged.=C2=A0

GIM>> I agree that the definitions of the IOAM= data-fields are invariant in various data plane encapsulations. You likely= follow the discussion of the IAOM Direct Export and IOAM flags on the IPPM= WG list. I think that for SFC NSH, IOAM Direct Export could be as simple as "use the local policy". The = applicability of the Loopback and Active flags seems to require detailed ex= planation by SFP actors.

=C2=A0

=C2=A0

  • The location of the IOAM header in the SFC NSH-encapsulated=C2=A0packet is = defined in Section 3:

=C2=A0 =C2=A0IOAM-Data-Fields are carried in NSH<= /u>

=C2=A0 =C2=A0using a next protocol header which foll= ows the NSH MD context

=C2=A0 =C2=A0headers.

I've checked RFC 8300 but couldn't find it d= efines the Next Protocol header. Also, it appears that NSH Context headers= =C2=A0are optional. Hence my question. Is the presence of an NSH Context he= ader required when using IOAM? Could you clarify which mechanism is used to identify the payload of an SFC NSH-encapsulated= packet as IOAM?

= Shwetha> We will reword it, it is not Next Protocol header but using IOA= M as a Next Protocol as described in Section 4.1 and requested in IANA sect= ion. Following is the proposed text to align with the RFC 8300 reference to context headers following base header and servic= e path header:

= "The NSH is defined in [RFC8300].=C2=A0 IOAM-Data-Fields are carried i= n NSH=C2=A0using a next protocol to identify IOAM data fields that follows = NSH context headers."

GIM>> I think that RFC 8300 views data followi= ng Context Headers as NSH payload, not being "in NSH".=C2=A0

  • If I understand the format of the IOAM header defined in Section 3 correctl= y, the header's length is limited by 1020 octets, while the effective l= ength containing IOAM options and data - 1016 octets. Is that correct? What= is the recommended technique of collecting IOAM data that exceeds that limit?

= Shwetha > IOAM options inherently support specifying the size limits at = the node that added the IOAM options. While operationalizing the solution t= he data types included and number of nodes expected to be adding the data should be selected. This is covered in deployment co= nsiderations=C2=A0draft-brockners-opsawg-ioam-deployment.<= /u>

  • In Section 4.1, I've found the text reflecting the history of the discu= ssion about how to carry the IOAM header using NSH encapsulation. As the te= xt has no normative value, I suggest moving it into an Appendix.<= /u>

= Shwetha > Agreed, revised draft will have this section moved to Appendix= .=C2=A0

GIM>> Thank you.=C2=A0

  • I find the rules of handling the O-bit in NSH listed in Section 4.2 inconsi= stent and confusing. The IOAM header is not part of NSH encapsulation but i= s a part of the payload. But in one case, when user data follows it, the O-= bit must not be set as. If there's no user data after the IOAM header, then the O-bit must be set. But from t= he perspective of NSH encapsulation, it includes specially constructed data= added for the sole purpose of collecting OAM/telemetry information. Then, = why, in one case, the O-bit is cleared and in the other set if, in both cases, the NSH-encapsulated packet is use= d to perform the OAM function?

= Shwetha > The reason for not setting the O-bit for packets that contains= actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier implementations that do not support

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 SFC OAM procedures SHOULD discard packets with O bit set=
". It will be undesirable to discard packets with O-bit set that carry=
 user data as IOAM can be inserted insitu.
For synthetic =
traffic created for OAM along with IOAM-data-fields in NSH following the NS=
H OAM function with 0-bit set is desirable.=C2=A0

=C2=A0GIM>> This is an interesting situation. = I agree that there could be an SFC element not supporting "SFC OAM pro= cedures" (not clear what these are). By the same token, would such SFC= element support IOAM, be capable of processing IOAM without adverse impact to user data? I am not certain and it seems that it might b= e better to recommend that NSH packets with IOAM be dropped by an SFP eleme= nt if it does not support "SFC OAM". What are your thoughts?

=C2=A0

=C2=A0

= Thanks,

= Shwetha=C2=A0

I much appreciate your consideration of my comments = and questions and looking forward to your feedback.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Aug 18, 2021 at 5:32 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

Dear WG:

=C2=A0

This email starts a 2 week Working Group Last Call f= or draft-ietf-sfc-ioam-nsh [1].

=C2=A0

Please read this document if you haven=E2=80=99t rea= d the most recent version and send your comments to the SFC WG list no late= r than September 1st 2021.

=C2=A0

If you are raisi= ng a point which you expect will be specifically debated on the mailing lis= t, consider using a specific email/thread for this point.<= /u>

=C2=A0=

Lastly, if you a= re an author or contributor please response to indicate whether you know of= any undisclosed IPR related to this document.

=C2=A0

Thanks!

=C2=A0

Jim & Joel

=C2=A0

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/=

=C2=A0

=C2=A0

=C2=A0

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

--0000000000006376fe05d712e9a0-- From nobody Wed Feb 9 06:57:45 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986943A0A36 for ; Wed, 9 Feb 2022 06:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 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_NONE=0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thoughtspot.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 cVstC5Y-w4Q3 for ; Wed, 9 Feb 2022 06:57:38 -0800 (PST) Received: from mx0a-0055fe01.pphosted.com (mx0a-0055fe01.pphosted.com [205.220.164.104]) (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 78E0B3A0A25 for ; Wed, 9 Feb 2022 06:57:37 -0800 (PST) Received: from pps.filterd (m0211451.ppops.net [127.0.0.1]) by mx0b-0055fe01.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 2199mwfl026691 for ; Wed, 9 Feb 2022 06:57:36 -0800 Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by mx0b-0055fe01.pphosted.com (PPS) with ESMTPS id 3e461hsapx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 09 Feb 2022 06:57:35 -0800 Received: by mail-qt1-f199.google.com with SMTP id w25-20020ac84d19000000b002d2966d66a8so1860216qtv.18 for ; Wed, 09 Feb 2022 06:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thoughtspot.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M/+k/P99GV2IxZt/OgO3JeRDywJCUdpFQoaalbVJaBc=; b=l4LcEXJxrBYD3hcT3S3ezhN3D/flu0WYyfJ9zhTkO76ibPYdgOV3mbdDikQtRIbxek 4iujVe/3ItgIOyunvu9hUL2uHDIlqKn00GKGfMWIb5zhAmKYu0kzux20W/br9cJsyjyS wee83W4mddrOMiwVKx8VNKRrKl2GPLuP7WpG6hLQ9dnd6QNe5fnTm2f1ST3CE55fwilK SLIh0/+Ifjhg4Dq49+JPnOc1FUVxcy6ZLnoirThjDL6vOc7nhPrY8ugWaIovB3namvXV uIA11WF7mHSq4kF6uiTyzVJYtubp8b4FBqdlxsvgvpCZ4uujtqCBVN6/NHFmd3NpD83v V+dg== 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=M/+k/P99GV2IxZt/OgO3JeRDywJCUdpFQoaalbVJaBc=; b=GmMwLouA4MF9ja2XIorKBDgHKnbQPkeXj7nc+tePBkjunnYJsoAQHMnfKVuC8Ut0n5 lMGzsfhL+mPjVlPRwoGR8YvGD2YjFwgGihAfMderjBg9D25Bc9Z3fwsC78VwGxFqwC9I eNYwRGfA4rUPT4LZyBJRHszSjUS9+GagjVFjxOzH0PSNZn7/TEsCfu7VnaARNDpc109C sxK+Lbk2CrulTCYSIAv/eBb7hMCVFoROlKku7uiWDTTAURvNzHT97nC5aLtnV1jq8rrR WS+700Z1XojnFQvnWtCwaqEuHyOKOmI+Y77spPV6mDKyLZdhl62cCghSLQMEGA+B7G5j Cveg== X-Gm-Message-State: AOAM532fIXh1vIQ5sAJwQ+ThaGzMb9Fn5a5slnAKSx26fS58eATJfoL9 pmWrp0d59RbBzZzSbcHDyxneH4+FVamxgsgkv0B79P3EsNXrLIlZPgPC3vVHOhfIBywt8Cgs1e1 bWpgLiL1KrcMHeUCV6go= X-Received: by 2002:a05:620a:a16:: with SMTP id i22mr1277943qka.376.1644418654254; Wed, 09 Feb 2022 06:57:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJyK1ZQrf4Slikqtx24Z6mBsVeC1v+eHXK+24IG3EgHsPSICCq7VgL2/gDMc8Jyx/Bqfn2QCzIDdYVZ3CzPP4K8= X-Received: by 2002:a05:620a:a16:: with SMTP id i22mr1277926qka.376.1644418653751; Wed, 09 Feb 2022 06:57:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Shwetha Bhandari Date: Wed, 9 Feb 2022 20:27:21 +0530 Message-ID: To: Greg Mirsky Cc: James Guichard , "draft-ietf-sfc-ioam-nsh@ietf.org" , "sfc@ietf.org" , "sfc-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b8236305d7970d9e" X-Proofpoint-GUID: sSeu_-T03qFn5ViOHeQLlTenSndWIsQx X-Proofpoint-ORIG-GUID: sSeu_-T03qFn5ViOHeQLlTenSndWIsQx 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-09_08,2022-02-09_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 clxscore=1015 mlxlogscore=999 phishscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 spamscore=0 bulkscore=5 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202090084 Archived-At: Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 14:57:44 -0000 --000000000000b8236305d7970d9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jim, On the O bit handling, are you suggesting that the O-bit for IOAM, that is carried as a next protocol following NSH header, is not applicable? Would removing the section on O-bit considerations resolve your concern? Hi Greg, >I have one more question. As the draft now mentions the option of using IOAM Direct Export to collect the IOAM data, it might be helpful reflecting that in the figure on p.2. I think that the caption "IOAM Option and Data Space" might be reworded to "IOAM Option and Optional Data Space". What are your thoughts? Yes, that will make it accurate. I will update the diagram and publish a new version. >I cannot find the text in the draft suggesting that an SFF that does not support IOAM may forward the packet with the NSH Next Protocol field equal to IOAM protocol identifier. Could you help me find it? Can you suggest text to help with this ? This would be a generic problem for NSH implementation when a next protocol is set to a value it does not understand. What should is recommended action in this situation? > For example, if the Loopback IOAM flag is set, the node is required to send a copy of the packet back to the IOAM encapsulating node. It is not clear to me how an SFF learns the identity of the IOAM encapsulating node and how it encapsulates the loopbacked packet. Can you help me find how it is supposed to work in the NSH? https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags#section-4.= 2 : A Loopback flag that is set indicates to the transit nodes processing this option that they are to create a copy of the received packet and send the copy back to the source of the packet. Given this is explained in the flag handling, do you see a need to define it again in NSH? IMHO the explanation of flag handling is quite generic for any packet based transport. Please share your thoughts and text suggestions to improve the draft for flag handling if it requires clarification. Thanks, Shwetha On Thu, Feb 3, 2022 at 6:48 AM Greg Mirsky wrote: > Hi Shwetha, > I have one more question. As the draft now mentions the option of using > IOAM Direct Export to collect the IOAM data, it might be helpful reflecti= ng > that in the figure on p.2. I think that the caption "IOAM Option and Data > Space" might be reworded to "IOAM Option and Optional Data Space". > What are your thoughts? > > Regards, > Greg > > On Wed, Feb 2, 2022 at 7:29 AM Shwetha Bhandari < > shwetha.bhandari@thoughtspot.com> wrote: > >> Hi Jim, Greg, >> >> Thanks for the follow up. >> 1) On O-bit: I am a bit confused about the O-bit feedback. Are you >> suggesting that it should not be a consideration for IOAM as it is handl= ed >> as a next protocol and not as NSH context headers? >> What should a SFC element handle a packet containing IOAM as next header >> and does not implement IOAM and hence does not understand IOAM? I think >> O-bit helps in such situations to help such elements decide to drop or >> forward without processing the IOAM header. >> Let me know if that is not the case and if simply not considering O-bit >> in the context of IOAM is what you would recommend. >> 2) Active or Loopback flags >> - >> there is nothing specific for NSH on how the flags are to be handled. T= he >> IOAM specific fields are to be handled as recommended by the respective >> IOAM drafts. Do you see any specific NSH considerations to be documented >> for IOAM fields? >> >> Thanks, >> Shwetha >> >> >> >> >> >> >> >> On Tue, Feb 1, 2022 at 4:29 PM James Guichard < >> james.n.guichard@futurewei.com> wrote: >> >>> Hi Shwetha & Greg, >>> >>> >>> >>> Thank you for the update. >>> >>> >>> >>> I still believe however that more work is necessary to reconcile how SF= C >>> OAM is supposed to work. RFC 8300 says: >>> >>> >>> >>> O bit: Setting this bit indicates an OAM packet (see [RFC6291 >>> >>> ]). >>> >>> The actual format and processing of SFC OAM packets is outside th= e >>> >>> scope of this specification (for example, see [SFC-OAM-FRAMEWORK >>> >>> ] >>> >>> for one approach). >>> >>> >>> >>> The O bit MUST be set for OAM packets and MUST NOT be set for >>> >>> non-OAM packets. >>> >>> >>> >>> If we look at RFC6291 it simply describes what OAM is supposed to mean >>> and this is independent from SFC. The SFC-OAM-Framework (now RFC 8924) = in >>> section 6.3 says: >>> >>> >>> >>> The Next Protocol field in the NSH header may be used to indicate >>> what OAM function is intended >>> >>> or what toolset is used. Any other overlay encapsulations used at >>> the service layer must have a >>> >>> similar way to indicate the intended OAM function. >>> >>> >>> >>> So my reading of this is that if you take 8300 together with the >>> framework then 1. The O-bit MUST be set for OAM packets, and 2. The Nex= t >>> Protocol field may or may not be used to indicate which OAM function is= to >>> be applied. From this I can determine that iOAM has taken the approach = of >>> using the next protocol field to indicate how to process the OAM packet= and >>> does NOT use the NSH context headers in any way shape or form. This see= ms >>> consistent with the current definitions of the O-bit from RFC 8300 and >>> processing guidelines from RFC 8924. >>> >>> >>> >>> However, your document says: >>> >>> >>> >>> *4.1 >>> . >>> IOAM and the use of the NSH O-bit* >>> >>> >>> >>> [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300 >>> ] >>> the O >>> >>> bit must be set for OAM packets and must not be set for non-OAM >>> >>> packets. Packets with IOAM data included MUST follow this >>> >>> definition, i.e. the O bit MUST NOT be set for regular customer >>> >>> traffic which also carries IOAM data and the O bit MUST be set for >>> >>> OAM packets which carry only IOAM data without any regular data >>> >>> payload. >>> >>> >>> >>> This text basically says that if the packet is customer traffic and >>> happens to carry iOAM data then it is NOT an OAM packet. What am I >>> missing, customer traffic or not, both carry iOAM data so how are they >>> different within an SFC domain? >>> >>> >>> >>> In addition to the above I will note that there is still a conflict wit= h >>> Greg=E2=80=99s draft namely this text from section 4: >>> >>> * O bit set and the "Next Protocol" value does not match the value >>> >>> Active SFC OAM (TBA1), defined in Section 10.1 >>> >>> : >>> >>> >>> >>> - An SFC NSH Context Header(s) contain an OAM processing >>> >>> instructions or data. >>> >>> >>> >>> - The "Next Protocol" field determines the type of the payload= . >>> >>> >>> >>> The above text suggests to me that if the O-bit is set and the next >>> protocol is not active SFC OAM then it is **required** that OAM data >>> will be in the NSH context headers (which is not the case for iOAM) and= the >>> next protocol will indicate what follows the NSH header. While iOAM doe= s >>> follow the NSH header as indicated by the next protocol there is still = an >>> expectation that OAM is also carried in the NSH context headers. This s= eems >>> to be in conflict with RFC 8300 AND RFC 8924. >>> >>> >>> >>> This of course is just my reading of the text and I would like to hear >>> yours and other folks thoughts. >>> >>> >>> >>> Jim >>> >>> >>> >>> *From:* Shwetha Bhandari >>> *Sent:* Monday, January 31, 2022 11:25 PM >>> *To:* Greg Mirsky >>> *Cc:* James Guichard ; >>> draft-ietf-sfc-ioam-nsh@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org >>> *Subject:* Re: [sfc] WGLC for >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >>> >>> >>> >>> >>> Hi Greg, >>> >>> >>> >>> Sorry for the late action on this. >>> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 >>> >>> has been now posted with the edits per this discussion. >>> >>> >>> >>> Hi Jim, >>> >>> >>> >>> After Greg's review please let us know if the changes are good to >>> progress the draft to the next step. >>> >>> >>> >>> Thanks, >>> >>> Shwetha >>> >>> >>> >>> On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky >>> wrote: >>> >>> Hi Shwetha, >>> >>> thank you for the detailed response to my comments. Please feel free to >>> share any updates you're considering for the next version. I'll be glad= to >>> work together on these. >>> >>> I have several follow-up notes in-lined below under the GIM>> tag. >>> >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari < >>> shwetha.bhandari@thoughtspot.com> wrote: >>> >>> Hi Greg, >>> >>> >>> >>> Sorry for the very late reply. Please find responses to your comments >>> inline @Shwetha: >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky >>> wrote: >>> >>> Dear Authors and All, >>> >>> I've read the current version of the draft and have some comments I'd >>> like to share with you. I much appreciate your thoughts on where this w= ork >>> should go considering developments in other IETF WGs. Please find my no= tes >>> and questions below: >>> >>> - It is stated in the Abstract that: >>> >>> In-situ Operations, Administration, and Maintenance (IOAM) records >>> operational and telemetry information in the packet while the packet >>> traverses a path between two points in the network. >>> >>> But that is the case only for the pre-allocated and incremental trace >>> option types. The Direct Export option >>> >>> does not write telemetry data into the data packet itself but export >>> telemetry information in a specially constructed packet. >>> >>> And as we are talking about different IOAM trace options, the >>> question of the scope of this document seems appropriate. There is a >>> WGLC on two IOAM documents >>> >>> active through September 15th at the IPPM WG. I believe that it would b= e >>> beneficial if we had a single document that describes the applicability= of >>> IOAM in all its functionality defined by documents in IPPM WG. Of cours= e, >>> that cannot be a moving target as that would not be helpful. But since = the >>> IPPM WG discusses the progress of two IOAM documents, it could be a gre= at >>> time to address the applicability of the Direct Export trace type >>> >>> and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags >>> . >>> It would be concerning to have more than one SFC document describing th= e >>> applicability of the generic IOAM mechanisms >>> >>> >>> >>> Shwetha> This is a fair point. We will revise the draft with text in >>> the abstract and Section 3 IOAM-Type to be updated to include the usage >>> of trace and DEX options. The encapsulation of IOAM options within NSH >>> itself in its current form already supports all the IOAM Option Type >>> defined both from draft-ietf-ippm-ioam-data and draft-ietf-ippm-ioam-di= rect-export >>> along with the flags supported within the options. Hence the >>> IOAM-data-field definitions in the draft will remain unchanged. >>> >>> GIM>> I agree that the definitions of the IOAM data-fields are invarian= t >>> in various data plane encapsulations. You likely follow the discussion = of >>> the IAOM Direct Export and IOAM flags on the IPPM WG list. I think that= for >>> SFC NSH, IOAM Direct Export could be as simple as "use the local policy= ". >>> The applicability of the Loopback and Active flags seems to require >>> detailed explanation by SFP actors. >>> >>> >>> >>> >>> >>> >>> - The location of the IOAM header in the SFC NSH-encapsulated packet >>> is defined in Section 3: >>> >>> IOAM-Data-Fields are carried in NSH >>> >>> using a next protocol header which follows the NSH MD context >>> >>> headers. >>> >>> I've checked RFC 8300 but couldn't find it defines the Next Protocol >>> header. Also, it appears that NSH Context headers are optional. Hence m= y >>> question. Is the presence of an NSH Context header required when using >>> IOAM? Could you clarify which mechanism is used to identify the payload= of >>> an SFC NSH-encapsulated packet as IOAM? >>> >>> Shwetha> We will reword it, it is not Next Protocol header but using >>> IOAM as a Next Protocol as described in Section 4.1 and requested in IA= NA >>> section. Following is the proposed text to align with the RFC 8300 >>> reference to context headers following base header and service path hea= der: >>> >>> "The NSH is defined in [RFC8300]. IOAM-Data-Fields are carried in >>> NSH using a next protocol to identify IOAM data fields that follows NSH >>> context headers." >>> >>> GIM>> I think that RFC 8300 views data following Context Headers as NSH >>> payload, not being "in NSH". >>> >>> >>> - If I understand the format of the IOAM header defined in Section 3 >>> correctly, the header's length is limited by 1020 octets, while the >>> effective length containing IOAM options and data - 1016 octets. Is = that >>> correct? What is the recommended technique of collecting IOAM data t= hat >>> exceeds that limit? >>> >>> Shwetha > IOAM options inherently support specifying the size limits at >>> the node that added the IOAM options. While operationalizing the soluti= on >>> the data types included and number of nodes expected to be adding the d= ata >>> should be selected. This is covered in deployment >>> considerations draft-brockners-opsawg-ioam-deployment. >>> >>> >>> - In Section 4.1, I've found the text reflecting the history of the >>> discussion about how to carry the IOAM header using NSH encapsulatio= n. As >>> the text has no normative value, I suggest moving it into an Appendi= x. >>> >>> Shwetha > Agreed, revised draft will have this section moved to >>> Appendix. >>> >>> GIM>> Thank you. >>> >>> >>> - I find the rules of handling the O-bit in NSH listed in Section >>> 4.2 inconsistent and confusing. The IOAM header is not part of NSH >>> encapsulation but is a part of the payload. But in one case, when us= er data >>> follows it, the O-bit must not be set as. If there's no user data af= ter the >>> IOAM header, then the O-bit must be set. But from the perspective of= NSH >>> encapsulation, it includes specially constructed data added for the = sole >>> purpose of collecting OAM/telemetry information. Then, why, in one c= ase, >>> the O-bit is cleared and in the other set if, in both cases, the >>> NSH-encapsulated packet is used to perform the OAM function? >>> >>> Shwetha > The reason for not setting the O-bit for packets that contain= s >>> actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier >>> implementations that do not support >>> >>> SFC OAM procedures SHOULD discard packets with O bit set". It wil= l be undesirable to discard packets with O-bit set that carry user data as = IOAM can be inserted insitu. >>> >>> For synthetic traffic created for OAM along with IOAM-data-fields in NS= H following the NSH OAM function with 0-bit set is desirable. >>> >>> GIM>> This is an interesting situation. I agree that there could be an >>> SFC element not supporting "SFC OAM procedures" (not clear what these a= re). >>> By the same token, would such SFC element support IOAM, be capable of >>> processing IOAM without adverse impact to user data? I am not certain a= nd >>> it seems that it might be better to recommend that NSH packets with IOA= M be >>> dropped by an SFP element if it does not support "SFC OAM". What are yo= ur >>> thoughts? >>> >>> >>> >>> >>> >>> Thanks, >>> >>> Shwetha >>> >>> I much appreciate your consideration of my comments and questions and >>> looking forward to your feedback. >>> >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> On Wed, Aug 18, 2021 at 5:32 AM James Guichard < >>> james.n.guichard@futurewei.com> wrote: >>> >>> Dear WG: >>> >>> >>> >>> This email starts a 2 week Working Group Last Call for >>> draft-ietf-sfc-ioam-nsh [1]. >>> >>> >>> >>> Please read this document if you haven=E2=80=99t read the most recent v= ersion >>> and send your comments to the SFC WG list no later than September 1st >>> 2021. >>> >>> >>> >>> If you are raising a point which you expect will be specifically debate= d >>> on the mailing list, consider using a specific email/thread for this po= int. >>> >>> >>> >>> Lastly, if you are an author or contributor please response to indicate >>> whether you know of any undisclosed IPR related to this document. >>> >>> >>> >>> Thanks! >>> >>> >>> >>> Jim & Joel >>> >>> >>> >>> [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> --000000000000b8236305d7970d9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim,

On the O bit handling, are you = suggesting that the O-bit for IOAM, that is carried as a next protocol foll= owing=C2=A0NSH header, is not applicable? Would removing the section on O-b= it considerations resolve your concern?

Hi Greg,

>I have one more question. As the draft now ment= ions the option of using IOAM Direct Export to collect the IOAM data, it mi= ght be helpful reflecting that in the figure on p.2. I think that the capti= on "IOAM Option and Data Space" might be reworded=C2=A0to "I= OAM Option and Optional Data Space".
What are your thoughts?=
Yes, that will make it accurate. I will update the diagram and p= ublish a new version.

>I cannot find the text i= n the draft suggesting that an SFF that does not support IOAM may forward t= he packet with the NSH Next Protocol field equal to IOAM protocol identifie= r. Could you help me find it?
Can you suggest text to help with t= his ? This would be a generic problem for NSH implementation when a next pr= otocol is set to a value it does not understand. What should is recommended= action in this situation?


> For= example, if the Loopback IOAM flag is set, the node is required to send a = copy of the packet back to the IOAM encapsulating node. It is not clear to = me how an SFF learns the identity of the IOAM encapsulating node and how it= encapsulates the loopbacked packet. Can you help me find how it is suppose= d to work in the NSH?=C2=A0
A Loopback flag that is= set indicates to the transit nodes processing this option that they are to create a copy of the received packet and send the copy back to the source of the packet.
Given t= his is explained in the flag handling, do you see a need to define it again= in NSH? IMHO the explanation of flag handling is quite generic for any pac= ket based transport.
Please share your thoughts and text suggesti= ons to improve the draft for flag handling if it requires clarification.=C2= =A0


Thanks,
Shwetha
=

= On Thu, Feb 3, 2022 at 6:48 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Shwetha,
I have one more question. As the draft now mentio= ns the option of using IOAM Direct Export to collect the IOAM data, it migh= t be helpful reflecting that in the figure on p.2. I think that the caption= "IOAM Option and Data Space" might be reworded=C2=A0to "IOA= M Option and Optional Data Space".
What are your thoughts?

Regards,
Greg

=
On Wed, Fe= b 2, 2022 at 7:29 AM Shwetha Bhandari <shwetha.bhandari@thoughtspot.com&g= t; wrote:
Hi Jim, Greg,

Thanks for the follow up.<= /div>
1) On O-bit: I am a bit confused about the O-bit feedback. Are yo= u suggesting that it should not be a consideration for IOAM as it is handle= d as a next protocol and not as NSH context headers?
What should = a SFC element handle a packet containing IOAM as next header and does not i= mplement IOAM and hence does not understand IOAM? I think O-bit helps in su= ch situations to help such elements decide to drop or forward without proce= ssing the IOAM header.
Let me know if that is not the case and if= simply not considering O-bit in the context of IOAM is what you would reco= mmend.
2) Active or Loopback flags=C2=A0- there is nothing specific=C2=A0f= or NSH on how the flags are to be handled.=C2=A0 The IOAM specific fields a= re to be handled as recommended by the respective IOAM drafts. Do you see a= ny specific NSH considerations to be documented for IOAM fields?
=
Thanks,
Shwetha






On Tue, = Feb 1, 2022 at 4:29 PM James Guichard <james.n.guichard@futurewei.com> w= rote:

Hi Shwetha & Greg,

=C2=A0

Thank you for the update.

=C2=A0

I still believe however that more work is necessary = to reconcile how SFC OAM is supposed to work. RFC 8300 says:

=C2=A0

=C2=A0=C2=A0 O bit:=C2=A0 Setting this bit indic= ates an OAM packet (see [RFC6291]).<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The actual format= and processing of SFC OAM packets is outside the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scope of this spe= cification (for example, see [SFC-OAM-FRAMEWORK]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for one approach)= .

=C2=A0

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0The O bit MUST be= set for OAM packets and MUST NOT be set for

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 non-OAM packets.<= u>

=C2=A0

If we look at RFC6291 it simply describes what OAM i= s supposed to mean and this is independent from SFC. The SFC-OAM-Framework = (now RFC 8924) in section 6.3 says:

=C2=A0

=C2=A0=C2=A0 The Next Protocol field in the NSH = header may be used to indicate what OAM function is intended<= /span>

=C2=A0=C2=A0 or what toolset is used.=C2=A0 Any = other overlay encapsulations used at the service layer must have a

=C2=A0=C2=A0=C2=A0similar way to indicate the in= tended OAM function.

=C2=A0

So my reading of this is that if you take 8300 toget= her with the framework then 1. The O-bit MUST be set for OAM packets, and 2= . The Next Protocol field may or may not be used to indicate which OAM func= tion is to be applied. From this I can determine that iOAM has taken the approach of using the next protocol = field to indicate how to process the OAM packet and does NOT use the NSH co= ntext headers in any way shape or form. This seems consistent with the curr= ent definitions of the O-bit from RFC 8300 and processing guidelines from RFC 8924.

=C2=A0

However, your document says:

=C2=A0

4.1.=C2=A0 IOAM and the use of the N= SH O-bit

=C2=A0

=C2=A0=C2=A0 [RFC8300] defines an "O bit&qu= ot; for OAM packets.=C2=A0 Per [RFC8300] the O

=C2=A0=C2=A0 bit must be set for OAM packets and= must not be set for non-OAM

=C2=A0=C2=A0 packets.=C2=A0 Packets with IOAM da= ta included MUST follow this

=C2=A0=C2=A0 definition, i.e. the O bit MUST NOT= be set for regular customer

=C2=A0=C2=A0 traffic which also carries IOAM dat= a and the O bit MUST be set for

=C2=A0=C2=A0 OAM packets which carry only IOAM d= ata without any regular data

=C2=A0=C2=A0 payload.

=C2=A0

This text basically says that if the packet is custo= mer traffic and happens to carry iOAM data then it is NOT an OAM packet.=C2= =A0 What am I missing, customer traffic or not, both carry iOAM data so how= are they different within an SFC domain?

=C2=A0

In addition to the above I will note that there is s= till a conflict with Greg=E2=80=99s draft namely this text from section 4:<= span style=3D"font-size:10pt;font-family:"Courier New";color:blac= k">

=C2=A0=C2=A0 *=C2=A0 O bit set and the "Nex= t Protocol" value does not match the value

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Active SFC OAM (T= BA1), defined in Section 10.1:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - An SFC NSH Context Header(s) contain an OAM processing

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= instructions or data.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - The "Next Protocol" field determines the type of the payload.<= u>

=C2=A0

The above text suggests to me that if the O-bit is s= et and the next protocol is not active SFC OAM then it is *required*= that OAM data will be in the NSH context headers (which is not the case fo= r iOAM) and the next protocol will indicate what follows the NSH header. While iOAM does follow the NSH heade= r as indicated by the next protocol there is still an expectation that OAM = is also carried in the NSH context headers. This seems to be in conflict wi= th RFC 8300 AND RFC 8924.

=C2=A0

This of course is just my reading of the text and I = would like to hear yours and other folks thoughts.

=C2=A0

Jim

=C2=A0

From: Shwetha Bhandari <shwetha.bhandari@though= tspot.com>
Sent: Monday, January 31, 2022 11:25 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: James Guichard <james.n.guichard@futurewei.com>; draft-ietf-sfc-io= am-nsh@ietf.org; sfc@= ietf.org; sfc-= chairs@ietf.org
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh= /

=C2=A0

Hi Greg,

=C2=A0

Sorry for the late action on this. https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 has be= en now posted with the edits per this discussion.=C2=A0

=C2=A0

Hi Jim,

=C2=A0

After Greg's review please let us know if the ch= anges are good to progress the draft to the next step.

=C2=A0

Thanks,

Shwetha

=C2=A0

On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

Hi Shwetha,

thank you for the detailed response to my comments. = Please feel free to share any updates you're considering for the next v= ersion. I'll be glad to work together on these.

I have several follow-up notes in-lined below under = the GIM>> tag.

=C2=A0

Regards,

Greg

=C2=A0

On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari <= ;shwe= tha.bhandari@thoughtspot.com> wrote:

= Hi Greg,

=C2=A0

= Sorry for the very late reply. Please find responses to your comments inlin= e @Shwetha:

=C2=A0

=C2=A0

=C2=A0

On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <gregimirsky@gmail.com= > wrote:

Dear Authors and All,

I've read the current version of the draft and h= ave some comments I'd like to share with you. I much appreciate your th= oughts on where this work should go considering developments in other IETF = WGs. Please find my notes and questions below:

  • It is stated in the Abstract that:

=C2=A0 =C2=A0In-situ Operations, Administration, and= Maintenance (IOAM) records
=C2=A0 =C2=A0operational and telemetry information in the packet while the = packet
=C2=A0 =C2=A0traverses a path between two points in the network.<= /u>

But that is the case only for the pre-allocated and = incremental trace option=C2=A0types. The Direct Export option does not write telemetry=C2=A0data into the data p= acket itself but export telemetry information in a specially constructed pa= cket.=C2=A0

And as we are talking about different IOAM trace opt= ions, the question=C2=A0of the scope of this document seems appropriate. Th= ere is a WGLC on two IOAM documents active through September 15th at the IPPM = WG. I believe that it would be beneficial if we had a single document that = describes the applicability of IOAM in all its functionality defined by doc= uments in IPPM WG. Of course, that cannot be a moving target as that would not be helpful. But since the IPPM= WG discusses the progress of two IOAM documents, it could be a great time = to address the applicability of the Direct Export trace type and Loopback and Active flags defined in= =C2=A0draft-ietf-ippm-ioam-flags. It would be concerning to have more than one SFC document describing the a= pplicability of the generic IOAM mechanisms

=C2=A0

= Shwetha> This is a fair point. We will revise the=C2=A0 draft with text = in the abstract and Section 3 IOAM-Type=C2=A0to be updated to include the usage of trace and DEX options.=C2=A0 The encapsulation of IOAM options within NSH = itself in its current form already supports all the IOAM Option Type define= d both from draft-i= etf-ippm-ioam-data and=C2=A0draft-ietf-ippm-ioam-direct-export along with the flags supported within the options. Hence the IOAM-data-fie= ld definitions in the draft will remain unchanged.=C2=A0

GIM>> I agree that the definitions of the IOAM= data-fields are invariant in various data plane encapsulations. You likely= follow the discussion of the IAOM Direct Export and IOAM flags on the IPPM= WG list. I think that for SFC NSH, IOAM Direct Export could be as simple as "use the local policy". The = applicability of the Loopback and Active flags seems to require detailed ex= planation by SFP actors.

=C2=A0

=C2=A0

  • The location of the IOAM header in the SFC NSH-encapsulated=C2=A0packet is = defined in Section 3:

=C2=A0 =C2=A0IOAM-Data-Fields are carried in NSH<= /u>

=C2=A0 =C2=A0using a next protocol header which foll= ows the NSH MD context

=C2=A0 =C2=A0headers.

I've checked RFC 8300 but couldn't find it d= efines the Next Protocol header. Also, it appears that NSH Context headers= =C2=A0are optional. Hence my question. Is the presence of an NSH Context he= ader required when using IOAM? Could you clarify which mechanism is used to identify the payload of an SFC NSH-encapsulated= packet as IOAM?

= Shwetha> We will reword it, it is not Next Protocol header but using IOA= M as a Next Protocol as described in Section 4.1 and requested in IANA sect= ion. Following is the proposed text to align with the RFC 8300 reference to context headers following base header and servic= e path header:

= "The NSH is defined in [RFC8300].=C2=A0 IOAM-Data-Fields are carried i= n NSH=C2=A0using a next protocol to identify IOAM data fields that follows = NSH context headers."

GIM>> I think that RFC 8300 views data followi= ng Context Headers as NSH payload, not being "in NSH".=C2=A0

  • If I understand the format of the IOAM header defined in Section 3 correctl= y, the header's length is limited by 1020 octets, while the effective l= ength containing IOAM options and data - 1016 octets. Is that correct? What= is the recommended technique of collecting IOAM data that exceeds that limit?

= Shwetha > IOAM options inherently support specifying the size limits at = the node that added the IOAM options. While operationalizing the solution t= he data types included and number of nodes expected to be adding the data should be selected. This is covered in deployment co= nsiderations=C2=A0draft-brockners-opsawg-ioam-deployment.<= /u>

  • In Section 4.1, I've found the text reflecting the history of the discu= ssion about how to carry the IOAM header using NSH encapsulation. As the te= xt has no normative value, I suggest moving it into an Appendix.<= /u>

= Shwetha > Agreed, revised draft will have this section moved to Appendix= .=C2=A0

GIM>> Thank you.=C2=A0

  • I find the rules of handling the O-bit in NSH listed in Section 4.2 inconsi= stent and confusing. The IOAM header is not part of NSH encapsulation but i= s a part of the payload. But in one case, when user data follows it, the O-= bit must not be set as. If there's no user data after the IOAM header, then the O-bit must be set. But from t= he perspective of NSH encapsulation, it includes specially constructed data= added for the sole purpose of collecting OAM/telemetry information. Then, = why, in one case, the O-bit is cleared and in the other set if, in both cases, the NSH-encapsulated packet is use= d to perform the OAM function?

= Shwetha > The reason for not setting the O-bit for packets that contains= actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier implementations that do not support

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 SFC OAM procedures SHOULD discard packets with O bit set=
". It will be undesirable to discard packets with O-bit set that carry=
 user data as IOAM can be inserted insitu.
For synthetic =
traffic created for OAM along with IOAM-data-fields in NSH following the NS=
H OAM function with 0-bit set is desirable.=C2=A0

=C2=A0GIM>> This is an interesting situation. = I agree that there could be an SFC element not supporting "SFC OAM pro= cedures" (not clear what these are). By the same token, would such SFC= element support IOAM, be capable of processing IOAM without adverse impact to user data? I am not certain and it seems that it might b= e better to recommend that NSH packets with IOAM be dropped by an SFP eleme= nt if it does not support "SFC OAM". What are your thoughts?

=C2=A0

=C2=A0

= Thanks,

= Shwetha=C2=A0

I much appreciate your consideration of my comments = and questions and looking forward to your feedback.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Aug 18, 2021 at 5:32 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

Dear WG:

=C2=A0

This email starts a 2 week Working Group Last Call f= or draft-ietf-sfc-ioam-nsh [1].

=C2=A0

Please read this document if you haven=E2=80=99t rea= d the most recent version and send your comments to the SFC WG list no late= r than September 1st 2021.

=C2=A0

If you are raisi= ng a point which you expect will be specifically debated on the mailing lis= t, consider using a specific email/thread for this point.<= /u>

=C2=A0=

Lastly, if you a= re an author or contributor please response to indicate whether you know of= any undisclosed IPR related to this document.

=C2=A0

Thanks!

=C2=A0

Jim & Joel

=C2=A0

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/=

=C2=A0

=C2=A0

=C2=A0

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

--000000000000b8236305d7970d9e-- From nobody Wed Feb 9 18:12:10 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531733A1236; Wed, 9 Feb 2022 18:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] 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 7NHEe4wZYWgk; Wed, 9 Feb 2022 18:12:00 -0800 (PST) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 67DBD3A1233; Wed, 9 Feb 2022 18:11:59 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id fj5so8973459ejc.4; Wed, 09 Feb 2022 18:11:59 -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=bZ96slQPCeQ4e822J9iw+21J/GYG07Jm9PIaxa8stDw=; b=U97J6sCjajYKDtCpbUQs6MQVqXXKX2oBB6D66UuKjB72+FF9Xq9zZ7PFTfWM+pH8cB Qb/kNKZXSqJx8IQcazu6XzpVNt75gkB615YOKRO/Ps5Sl+GFXnol6yXZ4qzoD09sABaN 0VK2WZc06oFfQsdbqXr/62uTLHtLTokzS7sHHLCIhmPdMIm5clSTM2d7cIEsohQO2cSS JI+cSU8UPsLMlOy/EtlMI76akPCFcqbcsD23VuuRX+6Jy3jYuHOSV//cVox0xTxQw2PF Ev2Nl2jRVUH1M5Pqp4kpGYH2EFAV4SvlnuL6aATSzCgroj4gmXJdZRL3nTO7QpiKciie Gp/Q== 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=bZ96slQPCeQ4e822J9iw+21J/GYG07Jm9PIaxa8stDw=; b=2CMVSz+xT4I4ehYIKIiBclYsT6zZJdKno7AAGmvIbNr9wlb78W7jnXns0pfMWAsKfz j7pWZkqB88wTqb+YvZaYs8R9NLZC52kpEHNZrWVRpIsX3dc0Z4hLLyQGaZDSyPNjEjsS yPHecG4aUd2ajmHhL8jSMhC4Vp+PjQJAQtBeXEN8LPCeS3ALuqhqv+BWzSQGVHoUP5aO z1hx174DFqCkYuYSZ8C0mR2M+ad0kACx/jCgI8ztce+1P/GOSBm0/uO2w7ikiFF69zG1 lEiBBav3yaSpCNx95DJ0Re/zPc3EMLwkzHtBKbvShSOROUxFkmec10NWhsjbNEC8lrFU 0s3A== X-Gm-Message-State: AOAM530tqHTEG5/2dBXo5c+VpYP5vWMpSa595tIqvccLWxGFiviDHtdi aF5vBGgM7krd+8VRIpJsTXd4Dvn0HabBPtWuF+TucvMffqI= X-Google-Smtp-Source: ABdhPJx/LW+48ST6JKUO4TPpd1KFrpKwAEfaxChTdZDBv7sa4NNKYEXBvUFRFUkR46qMXfCAjxcU6ENUKcxh8UB0dhg= X-Received: by 2002:a17:907:7f91:: with SMTP id qk17mr85135ejc.172.1644459112729; Wed, 09 Feb 2022 18:11:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Wed, 9 Feb 2022 18:11:41 -0800 Message-ID: To: Shwetha Bhandari Cc: James Guichard , "draft-ietf-sfc-ioam-nsh@ietf.org" , "sfc@ietf.org" , "sfc-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004310f805d7a079d2" Archived-At: Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 02:12:07 -0000 --0000000000004310f805d7a079d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Shwetha, thank you for your kind consideration of my comments. Please find my follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Wed, Feb 9, 2022 at 6:57 AM Shwetha Bhandari < shwetha.bhandari@thoughtspot.com> wrote: > Hi Jim, > > On the O bit handling, are you suggesting that the O-bit for IOAM, that i= s > carried as a next protocol following NSH header, is not applicable? Would > removing the section on O-bit considerations resolve your concern? > > Hi Greg, > > >I have one more question. As the draft now mentions the option of using > IOAM Direct Export to collect the IOAM data, it might be helpful reflecti= ng > that in the figure on p.2. I think that the caption "IOAM Option and Data > Space" might be reworded to "IOAM Option and Optional Data Space". > What are your thoughts? > Yes, that will make it accurate. I will update the diagram and publish a > new version. > GIM>> Thank you. > > >I cannot find the text in the draft suggesting that an SFF that does not > support IOAM may forward the packet with the NSH Next Protocol field equa= l > to IOAM protocol identifier. Could you help me find it? > Can you suggest text to help with this ? This would be a generic problem > for NSH implementation when a next protocol is set to a value it does not > understand. What should is recommended action in this situation? > GIM>> I think that dropping the packet and notifying the operator (under the controlled threshold) is the safest way to handle the situation. > > > > For example, if the Loopback IOAM flag is set, the node is required to > send a copy of the packet back to the IOAM encapsulating node. It is not > clear to me how an SFF learns the identity of the IOAM encapsulating node > and how it encapsulates the loopbacked packet. Can you help me find how i= t > is supposed to work in the NSH? > > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags#section-= 4.2 > : > > A Loopback flag that is set indicates to the transit nodes processing > this option that they are to create a copy of the received packet and > send the copy back to the source of the packet. > > Given this is explained in the flag handling, do you see a need to define > it again in NSH? IMHO the explanation of flag handling is quite generic f= or > any packet based transport. > Please share your thoughts and text suggestions to improve the draft for > flag handling if it requires clarification. > GIM>> The IPPM draft describes the basic Loopback behavior without specifying for every possible network layer. For the case of NSH, I find that the following text from Section 4 provides the guidance: Loopback can be used only if a return path from transit nodes and destination nodes towards the source (encapsulating node) exists. Specifically, loopback is only applicable in encapsulations in which the identity of the encapsulating node is available in the encapsulation header. If an encapsulating node receives a looped back packet that was not originated from the current encapsulating node, the packet is dropped. As the identity of the IOAM encapsulating node, to the best of my understanding, is not available in NSH, the Loopback must not be used and if the flag is set, the packet must be dropped. What do you think? And continuing the discussion about that draft, I may propose a text on the applicability of the IOAM Active flag: The applicability of the IOAM Active [I-D.ietf-ippm-ioam-flags] is outside the scope of this document and may be specified in the future. > > Thanks, > Shwetha > > On Thu, Feb 3, 2022 at 6:48 AM Greg Mirsky wrote: > >> Hi Shwetha, >> I have one more question. As the draft now mentions the option of using >> IOAM Direct Export to collect the IOAM data, it might be helpful reflect= ing >> that in the figure on p.2. I think that the caption "IOAM Option and Dat= a >> Space" might be reworded to "IOAM Option and Optional Data Space". >> What are your thoughts? >> >> Regards, >> Greg >> >> On Wed, Feb 2, 2022 at 7:29 AM Shwetha Bhandari < >> shwetha.bhandari@thoughtspot.com> wrote: >> >>> Hi Jim, Greg, >>> >>> Thanks for the follow up. >>> 1) On O-bit: I am a bit confused about the O-bit feedback. Are you >>> suggesting that it should not be a consideration for IOAM as it is hand= led >>> as a next protocol and not as NSH context headers? >>> What should a SFC element handle a packet containing IOAM as next heade= r >>> and does not implement IOAM and hence does not understand IOAM? I think >>> O-bit helps in such situations to help such elements decide to drop or >>> forward without processing the IOAM header. >>> Let me know if that is not the case and if simply not considering O-bit >>> in the context of IOAM is what you would recommend. >>> 2) Active or Loopback flags >>> - >>> there is nothing specific for NSH on how the flags are to be handled. = The >>> IOAM specific fields are to be handled as recommended by the respective >>> IOAM drafts. Do you see any specific NSH considerations to be documente= d >>> for IOAM fields? >>> >>> Thanks, >>> Shwetha >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Feb 1, 2022 at 4:29 PM James Guichard < >>> james.n.guichard@futurewei.com> wrote: >>> >>>> Hi Shwetha & Greg, >>>> >>>> >>>> >>>> Thank you for the update. >>>> >>>> >>>> >>>> I still believe however that more work is necessary to reconcile how >>>> SFC OAM is supposed to work. RFC 8300 says: >>>> >>>> >>>> >>>> O bit: Setting this bit indicates an OAM packet (see [RFC6291 >>>> >>>> ]). >>>> >>>> The actual format and processing of SFC OAM packets is outside t= he >>>> >>>> scope of this specification (for example, see [SFC-OAM-FRAMEWORK >>>> >>>> ] >>>> >>>> for one approach). >>>> >>>> >>>> >>>> The O bit MUST be set for OAM packets and MUST NOT be set for >>>> >>>> non-OAM packets. >>>> >>>> >>>> >>>> If we look at RFC6291 it simply describes what OAM is supposed to mean >>>> and this is independent from SFC. The SFC-OAM-Framework (now RFC 8924)= in >>>> section 6.3 says: >>>> >>>> >>>> >>>> The Next Protocol field in the NSH header may be used to indicate >>>> what OAM function is intended >>>> >>>> or what toolset is used. Any other overlay encapsulations used at >>>> the service layer must have a >>>> >>>> similar way to indicate the intended OAM function. >>>> >>>> >>>> >>>> So my reading of this is that if you take 8300 together with the >>>> framework then 1. The O-bit MUST be set for OAM packets, and 2. The Ne= xt >>>> Protocol field may or may not be used to indicate which OAM function i= s to >>>> be applied. From this I can determine that iOAM has taken the approach= of >>>> using the next protocol field to indicate how to process the OAM packe= t and >>>> does NOT use the NSH context headers in any way shape or form. This se= ems >>>> consistent with the current definitions of the O-bit from RFC 8300 and >>>> processing guidelines from RFC 8924. >>>> >>>> >>>> >>>> However, your document says: >>>> >>>> >>>> >>>> *4.1 >>>> . >>>> IOAM and the use of the NSH O-bit* >>>> >>>> >>>> >>>> [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300 >>>> ] >>>> the O >>>> >>>> bit must be set for OAM packets and must not be set for non-OAM >>>> >>>> packets. Packets with IOAM data included MUST follow this >>>> >>>> definition, i.e. the O bit MUST NOT be set for regular customer >>>> >>>> traffic which also carries IOAM data and the O bit MUST be set for >>>> >>>> OAM packets which carry only IOAM data without any regular data >>>> >>>> payload. >>>> >>>> >>>> >>>> This text basically says that if the packet is customer traffic and >>>> happens to carry iOAM data then it is NOT an OAM packet. What am I >>>> missing, customer traffic or not, both carry iOAM data so how are they >>>> different within an SFC domain? >>>> >>>> >>>> >>>> In addition to the above I will note that there is still a conflict >>>> with Greg=E2=80=99s draft namely this text from section 4: >>>> >>>> * O bit set and the "Next Protocol" value does not match the value >>>> >>>> Active SFC OAM (TBA1), defined in Section 10.1 >>>> >>>> : >>>> >>>> >>>> >>>> - An SFC NSH Context Header(s) contain an OAM processing >>>> >>>> instructions or data. >>>> >>>> >>>> >>>> - The "Next Protocol" field determines the type of the payloa= d. >>>> >>>> >>>> >>>> The above text suggests to me that if the O-bit is set and the next >>>> protocol is not active SFC OAM then it is **required** that OAM data >>>> will be in the NSH context headers (which is not the case for iOAM) an= d the >>>> next protocol will indicate what follows the NSH header. While iOAM do= es >>>> follow the NSH header as indicated by the next protocol there is still= an >>>> expectation that OAM is also carried in the NSH context headers. This = seems >>>> to be in conflict with RFC 8300 AND RFC 8924. >>>> >>>> >>>> >>>> This of course is just my reading of the text and I would like to hear >>>> yours and other folks thoughts. >>>> >>>> >>>> >>>> Jim >>>> >>>> >>>> >>>> *From:* Shwetha Bhandari >>>> *Sent:* Monday, January 31, 2022 11:25 PM >>>> *To:* Greg Mirsky >>>> *Cc:* James Guichard ; >>>> draft-ietf-sfc-ioam-nsh@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org >>>> *Subject:* Re: [sfc] WGLC for >>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >>>> >>>> >>>> >>>> >>>> Hi Greg, >>>> >>>> >>>> >>>> Sorry for the late action on this. >>>> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 >>>> >>>> has been now posted with the edits per this discussion. >>>> >>>> >>>> >>>> Hi Jim, >>>> >>>> >>>> >>>> After Greg's review please let us know if the changes are good to >>>> progress the draft to the next step. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Shwetha >>>> >>>> >>>> >>>> On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky >>>> wrote: >>>> >>>> Hi Shwetha, >>>> >>>> thank you for the detailed response to my comments. Please feel free t= o >>>> share any updates you're considering for the next version. I'll be gla= d to >>>> work together on these. >>>> >>>> I have several follow-up notes in-lined below under the GIM>> tag. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Greg >>>> >>>> >>>> >>>> On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari < >>>> shwetha.bhandari@thoughtspot.com> wrote: >>>> >>>> Hi Greg, >>>> >>>> >>>> >>>> Sorry for the very late reply. Please find responses to your comments >>>> inline @Shwetha: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky >>>> wrote: >>>> >>>> Dear Authors and All, >>>> >>>> I've read the current version of the draft and have some comments I'd >>>> like to share with you. I much appreciate your thoughts on where this = work >>>> should go considering developments in other IETF WGs. Please find my n= otes >>>> and questions below: >>>> >>>> - It is stated in the Abstract that: >>>> >>>> In-situ Operations, Administration, and Maintenance (IOAM) records >>>> operational and telemetry information in the packet while the packe= t >>>> traverses a path between two points in the network. >>>> >>>> But that is the case only for the pre-allocated and incremental trace >>>> option types. The Direct Export option >>>> >>>> does not write telemetry data into the data packet itself but export >>>> telemetry information in a specially constructed packet. >>>> >>>> And as we are talking about different IOAM trace options, the >>>> question of the scope of this document seems appropriate. There is a >>>> WGLC on two IOAM documents >>>> >>>> active through September 15th at the IPPM WG. I believe that it would = be >>>> beneficial if we had a single document that describes the applicabilit= y of >>>> IOAM in all its functionality defined by documents in IPPM WG. Of cour= se, >>>> that cannot be a moving target as that would not be helpful. But since= the >>>> IPPM WG discusses the progress of two IOAM documents, it could be a gr= eat >>>> time to address the applicability of the Direct Export trace type >>>> >>>> and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags >>>> . >>>> It would be concerning to have more than one SFC document describing t= he >>>> applicability of the generic IOAM mechanisms >>>> >>>> >>>> >>>> Shwetha> This is a fair point. We will revise the draft with text in >>>> the abstract and Section 3 IOAM-Type to be updated to include the >>>> usage of trace and DEX options. The encapsulation of IOAM options wit= hin >>>> NSH itself in its current form already supports all the IOAM Option Ty= pe >>>> defined both from draft-ietf-ippm-ioam-data and draft-ietf-ippm-ioam-d= irect-export >>>> along with the flags supported within the options. Hence the >>>> IOAM-data-field definitions in the draft will remain unchanged. >>>> >>>> GIM>> I agree that the definitions of the IOAM data-fields are >>>> invariant in various data plane encapsulations. You likely follow the >>>> discussion of the IAOM Direct Export and IOAM flags on the IPPM WG lis= t. I >>>> think that for SFC NSH, IOAM Direct Export could be as simple as "use = the >>>> local policy". The applicability of the Loopback and Active flags seem= s to >>>> require detailed explanation by SFP actors. >>>> >>>> >>>> >>>> >>>> >>>> >>>> - The location of the IOAM header in the SFC >>>> NSH-encapsulated packet is defined in Section 3: >>>> >>>> IOAM-Data-Fields are carried in NSH >>>> >>>> using a next protocol header which follows the NSH MD context >>>> >>>> headers. >>>> >>>> I've checked RFC 8300 but couldn't find it defines the Next Protocol >>>> header. Also, it appears that NSH Context headers are optional. Hence = my >>>> question. Is the presence of an NSH Context header required when using >>>> IOAM? Could you clarify which mechanism is used to identify the payloa= d of >>>> an SFC NSH-encapsulated packet as IOAM? >>>> >>>> Shwetha> We will reword it, it is not Next Protocol header but using >>>> IOAM as a Next Protocol as described in Section 4.1 and requested in I= ANA >>>> section. Following is the proposed text to align with the RFC 8300 >>>> reference to context headers following base header and service path he= ader: >>>> >>>> "The NSH is defined in [RFC8300]. IOAM-Data-Fields are carried in >>>> NSH using a next protocol to identify IOAM data fields that follows NS= H >>>> context headers." >>>> >>>> GIM>> I think that RFC 8300 views data following Context Headers as NS= H >>>> payload, not being "in NSH". >>>> >>>> >>>> - If I understand the format of the IOAM header defined in Section >>>> 3 correctly, the header's length is limited by 1020 octets, while t= he >>>> effective length containing IOAM options and data - 1016 octets. Is= that >>>> correct? What is the recommended technique of collecting IOAM data = that >>>> exceeds that limit? >>>> >>>> Shwetha > IOAM options inherently support specifying the size limits a= t >>>> the node that added the IOAM options. While operationalizing the solut= ion >>>> the data types included and number of nodes expected to be adding the = data >>>> should be selected. This is covered in deployment >>>> considerations draft-brockners-opsawg-ioam-deployment. >>>> >>>> >>>> - In Section 4.1, I've found the text reflecting the history of the >>>> discussion about how to carry the IOAM header using NSH encapsulati= on. As >>>> the text has no normative value, I suggest moving it into an Append= ix. >>>> >>>> Shwetha > Agreed, revised draft will have this section moved to >>>> Appendix. >>>> >>>> GIM>> Thank you. >>>> >>>> >>>> - I find the rules of handling the O-bit in NSH listed in Section >>>> 4.2 inconsistent and confusing. The IOAM header is not part of NSH >>>> encapsulation but is a part of the payload. But in one case, when u= ser data >>>> follows it, the O-bit must not be set as. If there's no user data a= fter the >>>> IOAM header, then the O-bit must be set. But from the perspective o= f NSH >>>> encapsulation, it includes specially constructed data added for the= sole >>>> purpose of collecting OAM/telemetry information. Then, why, in one = case, >>>> the O-bit is cleared and in the other set if, in both cases, the >>>> NSH-encapsulated packet is used to perform the OAM function? >>>> >>>> Shwetha > The reason for not setting the O-bit for packets that >>>> contains actual user data is because RFC 8300 has " SF/SFF/SFC >>>> Proxy/Classifier implementations that do not support >>>> >>>> SFC OAM procedures SHOULD discard packets with O bit set". It wi= ll be undesirable to discard packets with O-bit set that carry user data as= IOAM can be inserted insitu. >>>> >>>> For synthetic traffic created for OAM along with IOAM-data-fields in N= SH following the NSH OAM function with 0-bit set is desirable. >>>> >>>> GIM>> This is an interesting situation. I agree that there could be a= n >>>> SFC element not supporting "SFC OAM procedures" (not clear what these = are). >>>> By the same token, would such SFC element support IOAM, be capable of >>>> processing IOAM without adverse impact to user data? I am not certain = and >>>> it seems that it might be better to recommend that NSH packets with IO= AM be >>>> dropped by an SFP element if it does not support "SFC OAM". What are y= our >>>> thoughts? >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Shwetha >>>> >>>> I much appreciate your consideration of my comments and questions and >>>> looking forward to your feedback. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Greg >>>> >>>> >>>> >>>> On Wed, Aug 18, 2021 at 5:32 AM James Guichard < >>>> james.n.guichard@futurewei.com> wrote: >>>> >>>> Dear WG: >>>> >>>> >>>> >>>> This email starts a 2 week Working Group Last Call for >>>> draft-ietf-sfc-ioam-nsh [1]. >>>> >>>> >>>> >>>> Please read this document if you haven=E2=80=99t read the most recent = version >>>> and send your comments to the SFC WG list no later than September 1st >>>> 2021. >>>> >>>> >>>> >>>> If you are raising a point which you expect will be specifically >>>> debated on the mailing list, consider using a specific email/thread fo= r >>>> this point. >>>> >>>> >>>> >>>> Lastly, if you are an author or contributor please response to indicat= e >>>> whether you know of any undisclosed IPR related to this document. >>>> >>>> >>>> >>>> Thanks! >>>> >>>> >>>> >>>> Jim & Joel >>>> >>>> >>>> >>>> [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> >>>> --0000000000004310f805d7a079d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Shwetha,
tha= nk you for your kind consideration of my comments. Please find my follow-up= notes in-lined below under the GIM>> tag.

R= egards,
Greg

On Wed, Feb 9, 2022 at 6:57 AM Shwetha Bhanda= ri <shwetha.bhandari= @thoughtspot.com> wrote:
Hi Jim,

On the O bit ha= ndling, are you suggesting that the O-bit for IOAM, that is carried as a ne= xt protocol following=C2=A0NSH header, is not applicable? Would removing th= e section on O-bit considerations resolve your concern?

Hi Greg,

>I have one more question. As th= e draft now mentions the option of using IOAM Direct Export to collect the = IOAM data, it might be helpful reflecting that in the figure on p.2. I thin= k that the caption "IOAM Option and Data Space" might be reworded= =C2=A0to "IOAM Option and Optional Data Space".
What ar= e your thoughts?
Yes, that will make it accurate. I will update t= he diagram and publish a new version.
GIM>&= gt; Thank you.=C2=A0

>I cannot find the text in the dra= ft suggesting that an SFF that does not support IOAM may forward the packet= with the NSH Next Protocol field equal to IOAM protocol identifier. Could = you help me find it?
Can you suggest text to help with this ? Thi= s would be a generic problem for NSH implementation when a next protocol is= set to a value it does not understand. What should is recommended action i= n this situation?
GIM>> I think that dro= pping the packet and notifying the operator (under the controlled threshold= ) is the safest way to handle the situation.


> For example, if the Loopback IOAM flag is set, the node is required = to send a copy of the packet back to the IOAM encapsulating node. It is not= clear to me how an SFF learns the identity of the IOAM encapsulating node = and how it encapsulates the loopbacked packet. Can you help me find how it = is supposed to work in the NSH?=C2=A0
  A Loopback flag tha=
t is set indicates to the transit nodes processing
   this option that they are to create a copy of the received packet and
   send the copy back to the source of the packet.
Given t= his is explained in the flag handling, do you see a need to define it again= in NSH? IMHO the explanation of flag handling is quite generic for any pac= ket based transport.
Please share your thoughts and text suggesti= ons to improve the draft for flag handling if it requires clarification.=C2= =A0
GIM>> The IPPM draft describes the b= asic Loopback behavior without specifying for every possible network layer.= For the case of NSH, I find that the following text from Section 4 provide= s the guidance:=C2=A0
=C2=A0 =C2=A0Loopback can be used only= if a return path from transit nodes and
=C2=A0 =C2=A0destination= nodes towards the source (encapsulating node) exists.
=C2=A0 =C2= =A0Specifically, loopback is only applicable in encapsulations in which
=C2=A0 =C2=A0the identity of the encapsulating node is available in = the
=C2=A0 =C2=A0encapsulation header.=C2=A0 If an encapsulating = node receives a looped
=C2=A0 =C2=A0back packet that was not orig= inated from the current encapsulating
=C2=A0 =C2=A0node, the pack= et is dropped.
As the identity of the IOAM encapsulating no= de, to the best of my understanding, is not available in NSH, the Loopback = must not be used and if the flag is set, the packet must be dropped. What d= o you think?
And continuing the discussion about that draft, I ma= y propose a text on the applicability of the IOAM Active flag:
<= /div>
The applicability of the IOAM Ac= tive [I-D.ietf-ippm-ioam-flags] is outside the scope of this document and m= ay be specified in the future.


Thanks,
= Shwetha

On Thu, Feb 3, 2022 at 6:48 AM Greg Mirsky <gregimirsky@gmail.com> w= rote:
Hi Shwetha,
I have one more = question. As the draft now mentions the option of using IOAM Direct Export = to collect the IOAM data, it might be helpful reflecting that in the figure= on p.2. I think that the caption "IOAM Option and Data Space" mi= ght be reworded=C2=A0to "IOAM Option and Optional Data Space".
What are your thoughts?

Regards,
Greg

On Wed, Feb 2, 2022 at 7:29 AM Shwetha Bhandari <= shwet= ha.bhandari@thoughtspot.com> wrote:
Hi Jim, Greg,

Thanks for the follow up.
1) On O-bit: I am a bit confused= about the O-bit feedback. Are you suggesting that it should not be a consi= deration for IOAM as it is handled as a next protocol and not as NSH contex= t headers?
What should a SFC element handle a packet containing I= OAM as next header and does not implement IOAM and hence does not understan= d IOAM? I think O-bit helps in such situations to help such elements decide= to drop or forward without processing the IOAM header.
Let me kn= ow if that is not the case and if simply not considering O-bit in the conte= xt of IOAM is what you would recommend.
2) Active or Loopback flags=C2=A0-= there is nothing specific=C2=A0for NSH on how the flags are to be handled.= =C2=A0 The IOAM specific fields are to be handled as recommended by the res= pective IOAM drafts. Do you see any specific NSH considerations to be docum= ented for IOAM fields?

Thanks,
Shwetha







On Tue, Feb 1, 2022 at 4:29 PM James Guichard <= james.n= .guichard@futurewei.com> wrote:

Hi Shwetha & Greg,

=C2=A0

Thank you for the update.

=C2=A0

I still believe however that more work is necessary = to reconcile how SFC OAM is supposed to work. RFC 8300 says:

=C2=A0

=C2=A0=C2=A0 O bit:=C2=A0 Setting this bit indic= ates an OAM packet (see [RFC6291]).<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The actual format= and processing of SFC OAM packets is outside the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scope of this spe= cification (for example, see [SFC-OAM-FRAMEWORK]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for one approach)= .

=C2=A0

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0The O bit MUST be= set for OAM packets and MUST NOT be set for

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 non-OAM packets.<= u>

=C2=A0

If we look at RFC6291 it simply describes what OAM i= s supposed to mean and this is independent from SFC. The SFC-OAM-Framework = (now RFC 8924) in section 6.3 says:

=C2=A0

=C2=A0=C2=A0 The Next Protocol field in the NSH = header may be used to indicate what OAM function is intended<= /span>

=C2=A0=C2=A0 or what toolset is used.=C2=A0 Any = other overlay encapsulations used at the service layer must have a

=C2=A0=C2=A0=C2=A0similar way to indicate the in= tended OAM function.

=C2=A0

So my reading of this is that if you take 8300 toget= her with the framework then 1. The O-bit MUST be set for OAM packets, and 2= . The Next Protocol field may or may not be used to indicate which OAM func= tion is to be applied. From this I can determine that iOAM has taken the approach of using the next protocol = field to indicate how to process the OAM packet and does NOT use the NSH co= ntext headers in any way shape or form. This seems consistent with the curr= ent definitions of the O-bit from RFC 8300 and processing guidelines from RFC 8924.

=C2=A0

However, your document says:

=C2=A0

4.1.=C2=A0 IOAM and the use of the N= SH O-bit

=C2=A0

=C2=A0=C2=A0 [RFC8300] defines an "O bit&qu= ot; for OAM packets.=C2=A0 Per [RFC8300] the O

=C2=A0=C2=A0 bit must be set for OAM packets and= must not be set for non-OAM

=C2=A0=C2=A0 packets.=C2=A0 Packets with IOAM da= ta included MUST follow this

=C2=A0=C2=A0 definition, i.e. the O bit MUST NOT= be set for regular customer

=C2=A0=C2=A0 traffic which also carries IOAM dat= a and the O bit MUST be set for

=C2=A0=C2=A0 OAM packets which carry only IOAM d= ata without any regular data

=C2=A0=C2=A0 payload.

=C2=A0

This text basically says that if the packet is custo= mer traffic and happens to carry iOAM data then it is NOT an OAM packet.=C2= =A0 What am I missing, customer traffic or not, both carry iOAM data so how= are they different within an SFC domain?

=C2=A0

In addition to the above I will note that there is s= till a conflict with Greg=E2=80=99s draft namely this text from section 4:<= span style=3D"font-size:10pt;font-family:"Courier New";color:blac= k">

=C2=A0=C2=A0 *=C2=A0 O bit set and the "Nex= t Protocol" value does not match the value

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Active SFC OAM (T= BA1), defined in Section 10.1:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - An SFC NSH Context Header(s) contain an OAM processing

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= instructions or data.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= - The "Next Protocol" field determines the type of the payload.<= u>

=C2=A0

The above text suggests to me that if the O-bit is s= et and the next protocol is not active SFC OAM then it is *required*= that OAM data will be in the NSH context headers (which is not the case fo= r iOAM) and the next protocol will indicate what follows the NSH header. While iOAM does follow the NSH heade= r as indicated by the next protocol there is still an expectation that OAM = is also carried in the NSH context headers. This seems to be in conflict wi= th RFC 8300 AND RFC 8924.

=C2=A0

This of course is just my reading of the text and I = would like to hear yours and other folks thoughts.

=C2=A0

Jim

=C2=A0

From: Shwetha Bhandari <shwetha.bhandari@though= tspot.com>
Sent: Monday, January 31, 2022 11:25 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: James Guichard <james.n.guichard@futurewei.com>; draft-ietf-sfc-io= am-nsh@ietf.org; sfc@= ietf.org; sfc-= chairs@ietf.org
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh= /

=C2=A0

Hi Greg,

=C2=A0

Sorry for the late action on this. https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 has be= en now posted with the edits per this discussion.=C2=A0

=C2=A0

Hi Jim,

=C2=A0

After Greg's review please let us know if the ch= anges are good to progress the draft to the next step.

=C2=A0

Thanks,

Shwetha

=C2=A0

On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

Hi Shwetha,

thank you for the detailed response to my comments. = Please feel free to share any updates you're considering for the next v= ersion. I'll be glad to work together on these.

I have several follow-up notes in-lined below under = the GIM>> tag.

=C2=A0

Regards,

Greg

=C2=A0

On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari <= ;shwe= tha.bhandari@thoughtspot.com> wrote:

= Hi Greg,

=C2=A0

= Sorry for the very late reply. Please find responses to your comments inlin= e @Shwetha:

=C2=A0

=C2=A0

=C2=A0

On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <gregimirsky@gmail.com= > wrote:

Dear Authors and All,

I've read the current version of the draft and h= ave some comments I'd like to share with you. I much appreciate your th= oughts on where this work should go considering developments in other IETF = WGs. Please find my notes and questions below:

  • It is stated in the Abstract that:

=C2=A0 =C2=A0In-situ Operations, Administration, and= Maintenance (IOAM) records
=C2=A0 =C2=A0operational and telemetry information in the packet while the = packet
=C2=A0 =C2=A0traverses a path between two points in the network.<= /u>

But that is the case only for the pre-allocated and = incremental trace option=C2=A0types. The Direct Export option does not write telemetry=C2=A0data into the data p= acket itself but export telemetry information in a specially constructed pa= cket.=C2=A0

And as we are talking about different IOAM trace opt= ions, the question=C2=A0of the scope of this document seems appropriate. Th= ere is a WGLC on two IOAM documents active through September 15th at the IPPM = WG. I believe that it would be beneficial if we had a single document that = describes the applicability of IOAM in all its functionality defined by doc= uments in IPPM WG. Of course, that cannot be a moving target as that would not be helpful. But since the IPPM= WG discusses the progress of two IOAM documents, it could be a great time = to address the applicability of the Direct Export trace type and Loopback and Active flags defined in= =C2=A0draft-ietf-ippm-ioam-flags. It would be concerning to have more than one SFC document describing the a= pplicability of the generic IOAM mechanisms

=C2=A0

= Shwetha> This is a fair point. We will revise the=C2=A0 draft with text = in the abstract and Section 3 IOAM-Type=C2=A0to be updated to include the usage of trace and DEX options.=C2=A0 The encapsulation of IOAM options within NSH = itself in its current form already supports all the IOAM Option Type define= d both from draft-i= etf-ippm-ioam-data and=C2=A0draft-ietf-ippm-ioam-direct-export along with the flags supported within the options. Hence the IOAM-data-fie= ld definitions in the draft will remain unchanged.=C2=A0

GIM>> I agree that the definitions of the IOAM= data-fields are invariant in various data plane encapsulations. You likely= follow the discussion of the IAOM Direct Export and IOAM flags on the IPPM= WG list. I think that for SFC NSH, IOAM Direct Export could be as simple as "use the local policy". The = applicability of the Loopback and Active flags seems to require detailed ex= planation by SFP actors.

=C2=A0

=C2=A0

  • The location of the IOAM header in the SFC NSH-encapsulated=C2=A0packet is = defined in Section 3:

=C2=A0 =C2=A0IOAM-Data-Fields are carried in NSH<= /u>

=C2=A0 =C2=A0using a next protocol header which foll= ows the NSH MD context

=C2=A0 =C2=A0headers.

I've checked RFC 8300 but couldn't find it d= efines the Next Protocol header. Also, it appears that NSH Context headers= =C2=A0are optional. Hence my question. Is the presence of an NSH Context he= ader required when using IOAM? Could you clarify which mechanism is used to identify the payload of an SFC NSH-encapsulated= packet as IOAM?

= Shwetha> We will reword it, it is not Next Protocol header but using IOA= M as a Next Protocol as described in Section 4.1 and requested in IANA sect= ion. Following is the proposed text to align with the RFC 8300 reference to context headers following base header and servic= e path header:

= "The NSH is defined in [RFC8300].=C2=A0 IOAM-Data-Fields are carried i= n NSH=C2=A0using a next protocol to identify IOAM data fields that follows = NSH context headers."

GIM>> I think that RFC 8300 views data followi= ng Context Headers as NSH payload, not being "in NSH".=C2=A0

  • If I understand the format of the IOAM header defined in Section 3 correctl= y, the header's length is limited by 1020 octets, while the effective l= ength containing IOAM options and data - 1016 octets. Is that correct? What= is the recommended technique of collecting IOAM data that exceeds that limit?

= Shwetha > IOAM options inherently support specifying the size limits at = the node that added the IOAM options. While operationalizing the solution t= he data types included and number of nodes expected to be adding the data should be selected. This is covered in deployment co= nsiderations=C2=A0draft-brockners-opsawg-ioam-deployment.<= /u>

  • In Section 4.1, I've found the text reflecting the history of the discu= ssion about how to carry the IOAM header using NSH encapsulation. As the te= xt has no normative value, I suggest moving it into an Appendix.<= /u>

= Shwetha > Agreed, revised draft will have this section moved to Appendix= .=C2=A0

GIM>> Thank you.=C2=A0

  • I find the rules of handling the O-bit in NSH listed in Section 4.2 inconsi= stent and confusing. The IOAM header is not part of NSH encapsulation but i= s a part of the payload. But in one case, when user data follows it, the O-= bit must not be set as. If there's no user data after the IOAM header, then the O-bit must be set. But from t= he perspective of NSH encapsulation, it includes specially constructed data= added for the sole purpose of collecting OAM/telemetry information. Then, = why, in one case, the O-bit is cleared and in the other set if, in both cases, the NSH-encapsulated packet is use= d to perform the OAM function?

= Shwetha > The reason for not setting the O-bit for packets that contains= actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier implementations that do not support

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 SFC OAM procedures SHOULD discard packets with O bit set=
". It will be undesirable to discard packets with O-bit set that carry=
 user data as IOAM can be inserted insitu.
For synthetic =
traffic created for OAM along with IOAM-data-fields in NSH following the NS=
H OAM function with 0-bit set is desirable.=C2=A0

=C2=A0GIM>> This is an interesting situation. = I agree that there could be an SFC element not supporting "SFC OAM pro= cedures" (not clear what these are). By the same token, would such SFC= element support IOAM, be capable of processing IOAM without adverse impact to user data? I am not certain and it seems that it might b= e better to recommend that NSH packets with IOAM be dropped by an SFP eleme= nt if it does not support "SFC OAM". What are your thoughts?

=C2=A0

=C2=A0

= Thanks,

= Shwetha=C2=A0

I much appreciate your consideration of my comments = and questions and looking forward to your feedback.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Aug 18, 2021 at 5:32 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

Dear WG:

=C2=A0

This email starts a 2 week Working Group Last Call f= or draft-ietf-sfc-ioam-nsh [1].

=C2=A0

Please read this document if you haven=E2=80=99t rea= d the most recent version and send your comments to the SFC WG list no late= r than September 1st 2021.

=C2=A0

If you are raisi= ng a point which you expect will be specifically debated on the mailing lis= t, consider using a specific email/thread for this point.<= /u>

=C2=A0=

Lastly, if you a= re an author or contributor please response to indicate whether you know of= any undisclosed IPR related to this document.

=C2=A0

Thanks!

=C2=A0

Jim & Joel

=C2=A0

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/=

=C2=A0

=C2=A0

=C2=A0

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

--0000000000004310f805d7a079d2-- From nobody Thu Feb 10 09:57:40 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C453A0E63; Thu, 10 Feb 2022 09:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] 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 NSFZKcfupifx; Thu, 10 Feb 2022 09:57:30 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20716.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e88::716]) (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 606FF3A08ED; Thu, 10 Feb 2022 09:57:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YIA/kZEpO+aMt/jIKUFQNo3s0uZ4JmdkiLDdVXLX8Plk0aLhLCmrXVr0vp37xoAsyDporFxeefAvJ/6fKcmx0a9En8G1MrmrjHRzjK0zWypeAKDrbATQgS6FR1yq6j7FC7K53rit+cPyc5RUwt0bAwomR+osawX8mn1cOsxsPa8tMWKcqhKbpHlMVGOD8FqurALL5UedmfWAb7z2W3UPin+kNrRrN2XhEqAAxPXwjtEfFAdq76sbwhP0aFr2JxmHlgJuVi+kOWuj0dBfBOzYFu+Dvx/AtHOyDLNhBSUDanQCZlorlhcAPR4QnQesNO+I8tJWohqccS4L5LEki+k7nw== 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=0AVLUNPho2gAgvMIjGrClE4Q6oVLvxw7VRKD7Hsg/Co=; b=U5FmLXsPwLjQGO7pSdXcYyDARfN7j3x7ff0EKwkDwQbjJhGWMNG1u6iV7szHilN984bHzKuFlvUQm0ap2P1GRxmoPU71PO4KaPE1zFEwaypmi9xR4DpL9CaCDwP7+ePbcCeTcltPcpT2aBcU6fUNfoOU4bqCK1E5pt0sQzdVhLCBlqYr7DDtN/M4XMDT3/ffg6uYMbjHXsxFZta3Y8O+Z5m4YuruzbOFvFBxIcRuNbjKXbLx948+G53iKkUNO3ydacSqOyh+PBQdzdS0Xza6Krj4C/jt/uD6kRqtO1gE0ahTqvD3913fGxlXtomzhFYMB3nbGRLzRJRlDXhtpoyTEQ== 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=0AVLUNPho2gAgvMIjGrClE4Q6oVLvxw7VRKD7Hsg/Co=; b=cmoGBCU1gsJPB+igO25AWEQsj2eBitzdgroNa4G90sr5+dYBzkcKv3Q/aDIqFw8L/tik7dVO00TERQJDpCfEsKcL99owVKTfTeN64u62E3oii2qcB1o3kepZpnq5+MD/t+i95U2NjRBokBAnAHOfC2/xR5r8Se0kz/O72nhT1Oo= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by BN6PR13MB1091.namprd13.prod.outlook.com (2603:10b6:404:6a::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.6; Thu, 10 Feb 2022 17:57:13 +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.4975.011; Thu, 10 Feb 2022 17:57:13 +0000 From: James Guichard To: Shwetha Bhandari , Greg Mirsky CC: "draft-ietf-sfc-ioam-nsh@ietf.org" , "sfc@ietf.org" , "sfc-chairs@ietf.org" Thread-Topic: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ Thread-Index: AdeULBhJRJPqyAEIQoSKEyRZsxugZSC95BWLAArMKUAAPrC9AAAUk9wAAUpazIAAOEHkgA== Date: Thu, 10 Feb 2022 17:57:13 +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: 20878ece-91a6-46a2-06d7-08d9ecbec482 x-ms-traffictypediagnostic: BN6PR13MB1091: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: cWmulSDRKSXvLq4GsqQxr3eSF3D5pGLnBcKQXZ0Rc0E7l4aepAfXnduuUvaFs30cPMf2Ny1BsD1sOkxWpa18Ai6/cpS7EQOoTFE+0nKfgC+R+hZzO5FvtcUmnsead8VNQEgQYgDLQ8neLexuaONOeR1fOuCq96ZaYxQ0S2mBLVCp6tyhrav5LnZqNyoey+Dn2gcWVssO+28OPi29/y8NgCNT9J2D/rG6M41Uul3tnnBs0kmY/twsrLgBtHuJF4CT93RAm2q9L6G/CnQx3ehj14n6E7eQKsTgA8HwIhCh6IZa6PXw+EPI3A2VektVTd5+zCA2q6z6Pde9VMtEFywhq5aebb3YQ7XkJhJZGfQGVKR0O8L4PH2d9rpPSe0GIV2TrJvPpqsqn3z0mb+ikxFgZTG7q2zIVOqhRzlvMO6PcC5A6CjcGKpeXfEAsbfG2WsTT4vDOR7fC080K9TCUyV3FhNX88Gi+IjQnFIbo9SIPUlKH39MG907Kywn5uQHGNchN/v5vHJIWHiI/3C95ap13foZX8aOTEw408xQeFqeUruwTc5bGa71m0PZGfKeTayZRI8M/ywnQcOVZ/KfRE3M/RLzZttXNQPkkpr95W5yxTpXJ6gnyGX+LmKYvWoo2rCRHlxnJ8KnH0VnJzytxm8s7ioel5Y/W9nQ2xIn4BAmywsHi/Kw2ULt5SDSyyQOBgA5OOPFq0SNl3TkDxd3YxvEK/CNqvpon7P+wxIbwSTf5dzh+86AOuKIMzWp+cQYJrRFCiXba46wrsC7w7+z+fNt/Gm+zYjfmNAq1gouCRxBZ27vKlR6EQOWEU5g6x6w1f7+WyFGG1SoAIzWppNsxX3HuA== 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)(84040400005)(71200400001)(86362001)(186003)(33656002)(54906003)(966005)(508600001)(122000001)(55016003)(110136005)(38100700002)(4326008)(38070700005)(76116006)(166002)(52536014)(8936002)(8676002)(6506007)(66446008)(66946007)(66556008)(66476007)(64756008)(83380400001)(9326002)(316002)(30864003)(7696005)(5660300002)(53546011)(2906002)(9686003)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?a5/2IlfMbGPGoIaOdTkIH09+IBdpEayzJWwk2vz6PoUBx4ustWl9vi7j0hQ8?= =?us-ascii?Q?d5rTh/SN4si+tm+mcEYd/K0KI+DDmQ9CpdKTLILveGkINheCcHTpneHcIeBj?= =?us-ascii?Q?77kEktu90ZQAGZ8+aLkRGOm/qrbYmPPDJzbl0v3uqRQ4XnExY5KzgALi+3X+?= =?us-ascii?Q?y1ItAnp01nL84h69bu8Im2gKvVXRHgL9AmhJGYfGYCAR95STz215pkxt8733?= =?us-ascii?Q?gVkvs213X/LNhQT6GicMsbWw7kTxNSPmxcPA6/XCr8pcX6t1PDh0cbMktkV3?= =?us-ascii?Q?fu6PIzS9187rx55ddY8nxqNT9bpYZU/vi1DZe+G+f5/0tgBtERHCkkKNf+O1?= =?us-ascii?Q?6qBM/OofXzZ1IpBzh2hn1np2GtY12cN/0VZNugL1jQ9Y4Rm4GT156XC+dgqJ?= =?us-ascii?Q?+/CXsExf4B2KzUMUD3kj9a8jFTgQW6XFtQALuVBjd1zuTCAr212XgG0DfDig?= =?us-ascii?Q?P0bKOcp3onRxYdYn3EHnY+6eSYSLg5TfyM2rmJ6uKnpxEKl9k6ccO6NKRpLw?= =?us-ascii?Q?zZ8MOzGeLCd56MrCu9yuOvnKg7S3dBYWPDbJwy3/PL5W21OkmtT702u86jIj?= =?us-ascii?Q?H2Xu4IgyBwsJ9xlt1M4UsEOHtdJCxIHoevOI5uC97Kq4PsXo6HFxWRw0f93E?= =?us-ascii?Q?Pc7JZIkt1XaVX3D5GGNAIpF8uK+01r5/jmeyl0iHjiBQTre5Vb0pjHqF/xKX?= =?us-ascii?Q?plLzloy9CjMjgy8sGK99qcpKAyR3KQVcS2x5x3xXqQtOedRcUyBnTynJpF10?= =?us-ascii?Q?8jJ6DQAC4dbFf48YzoMOfKeONljSoL6x8ohHJQB3772JnK70gaZWUVt0/8Mp?= =?us-ascii?Q?1T0QitA5FQYRt3MOXXbrwZkjXU9fdgZJ08iBPWvVUMQDrBmCSLPkyHiLCPp8?= =?us-ascii?Q?6sJhWyqbyCrUETUsZ5NxfGulpFa3X73xukiHRaceRvkkhn/UYRPoiIknxJe/?= =?us-ascii?Q?gQgS/avM5qny21fNxDMwFesuk+wxmLqdHPjHRlrvZTSojlehalN9P5KJfrcb?= =?us-ascii?Q?PKBsBcJPljM09kyRBT5aKmSneE5yIPigEUek3OghQk1kuCjVGkfccmEaYM0S?= =?us-ascii?Q?6nvy3wdR45zT0N2zhSzkBgB5tcb0AhL+JkSwurF5GJ8YmnT/eKX4NlSIeo9f?= =?us-ascii?Q?NCLQIHEEcQRsx5UmkgbqboMKkAzwtnfBspocIvqe7LxBjKzwRInd6vYHFER4?= =?us-ascii?Q?3XtNTHuF8YDEaiBGZwqCsPAfJ57uB+CVdcx/O8094oVW0K7k3kv6vLVxEle2?= =?us-ascii?Q?B1tb82mn0A4Srg07cHCQTonSxtfZHk28KI7tQmebAKzVLTDk+QtUpQXPit4n?= =?us-ascii?Q?E/VWt5JQaXtWw0M49jY+GSy/eX3MaiLNjcbGfwOMRyNz/ncE4boJtvLt0KMQ?= =?us-ascii?Q?RgeAjpRfBfAEc7nsR/5N/dZ8/cGu0MgGOBg5JmFefRjeRCMqGcYE8UuY5s4t?= =?us-ascii?Q?+nw2c0iPct0jTmWXyppVBMUOglE64u9l9CepbINmtm0TUGbLSW9ZYy6P8PUl?= =?us-ascii?Q?7dipcoNwYP25QkVdQYXMWqEL+gRBzX2JNajAwnnwuh7yyjKjCoESzR97sYAH?= =?us-ascii?Q?GpzLP0FZER99usegkFC4ywI2hwlMzkED1XNChoA14suS+knhqshuDKYhOKHe?= =?us-ascii?Q?GQ+FfRpDUif2p/GPoqPWvP0fnmjiymBEQ66KoAW8pQgp2vXdqGgpMxdQ69GF?= =?us-ascii?Q?QpUo6tjN41N1RljICdsKqX1XYpY=3D?= Content-Type: multipart/alternative; boundary="_000_MN2PR13MB420615DA403388EA0144A9C1D22F9MN2PR13MB4206namp_" 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: 20878ece-91a6-46a2-06d7-08d9ecbec482 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2022 17:57:13.2401 (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: hm15cJ6+TePS/FC2EH1eFki1Xu0JlPxSQcTHBfOXwjLKLDf9e/G5i0k6dO2kXf0D8UYQOVZQ/aUD0f53TqIXAg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR13MB1091 Archived-At: Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 17:57:37 -0000 --_000_MN2PR13MB420615DA403388EA0144A9C1D22F9MN2PR13MB4206namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shwetha, My only point was that in the case of IOAM the O-bit seems to be obsolete a= s you use the next protocol field rather than the context headers. It seems= to me that the definition of the O-bit should be that if set then the cont= ext headers are used to obtain the OAM instructions. Currently that is not = what 8300 says. As I said in my previous emails I would really like to hear= the WGs opinion on what to do with the O-bit and we certainly need to reco= ncile the various documents to be following the same standard. Jim From: Shwetha Bhandari Sent: Wednesday, February 9, 2022 9:57 AM To: Greg Mirsky Cc: James Guichard ; draft-ietf-sfc-ioam-ns= h@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc= -ioam-nsh/ Hi Jim, On the O bit handling, are you suggesting that the O-bit for IOAM, that is = carried as a next protocol following NSH header, is not applicable? Would r= emoving the section on O-bit considerations resolve your concern? Hi Greg, >I have one more question. As the draft now mentions the option of using IO= AM Direct Export to collect the IOAM data, it might be helpful reflecting t= hat in the figure on p.2. I think that the caption "IOAM Option and Data Sp= ace" might be reworded to "IOAM Option and Optional Data Space". What are your thoughts? Yes, that will make it accurate. I will update the diagram and publish a ne= w version. >I cannot find the text in the draft suggesting that an SFF that does not s= upport IOAM may forward the packet with the NSH Next Protocol field equal t= o IOAM protocol identifier. Could you help me find it? Can you suggest text to help with this ? This would be a generic problem fo= r NSH implementation when a next protocol is set to a value it does not und= erstand. What should is recommended action in this situation? > For example, if the Loopback IOAM flag is set, the node is required to se= nd a copy of the packet back to the IOAM encapsulating node. It is not clea= r to me how an SFF learns the identity of the IOAM encapsulating node and h= ow it encapsulates the loopbacked packet. Can you help me find how it is su= pposed to work in the NSH? https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags#section-4.= 2: A Loopback flag that is set indicates to the transit nodes processing this option that they are to create a copy of the received packet and send the copy back to the source of the packet. Given this is explained in the flag handling, do you see a need to define i= t again in NSH? IMHO the explanation of flag handling is quite generic for = any packet based transport. Please share your thoughts and text suggestions to improve the draft for fl= ag handling if it requires clarification. Thanks, Shwetha On Thu, Feb 3, 2022 at 6:48 AM Greg Mirsky > wrote: Hi Shwetha, I have one more question. As the draft now mentions the option of using IOA= M Direct Export to collect the IOAM data, it might be helpful reflecting th= at in the figure on p.2. I think that the caption "IOAM Option and Data Spa= ce" might be reworded to "IOAM Option and Optional Data Space". What are your thoughts? Regards, Greg On Wed, Feb 2, 2022 at 7:29 AM Shwetha Bhandari > wrote: Hi Jim, Greg, Thanks for the follow up. 1) On O-bit: I am a bit confused about the O-bit feedback. Are you suggesti= ng that it should not be a consideration for IOAM as it is handled as a nex= t protocol and not as NSH context headers? What should a SFC element handle a packet containing IOAM as next header an= d does not implement IOAM and hence does not understand IOAM? I think O-bit= helps in such situations to help such elements decide to drop or forward w= ithout processing the IOAM header. Let me know if that is not the case and if simply not considering O-bit in = the context of IOAM is what you would recommend. 2) Active or Loopback flags - there is nothing specific for NSH on how the flags are to be hand= led. The IOAM specific fields are to be handled as recommended by the resp= ective IOAM drafts. Do you see any specific NSH considerations to be docume= nted for IOAM fields? Thanks, Shwetha On Tue, Feb 1, 2022 at 4:29 PM James Guichard > wrote: Hi Shwetha & Greg, Thank you for the update. I still believe however that more work is necessary to reconcile how SFC OA= M is supposed to work. RFC 8300 says: O bit: Setting this bit indicates an OAM packet (see [RFC6291]). The actual format and processing of SFC OAM packets is outside the scope of this specification (for example, see [SFC-OAM-FRAMEWORK] for one approach). The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM packets. If we look at RFC6291 it simply describes what OAM is supposed to mean and = this is independent from SFC. The SFC-OAM-Framework (now RFC 8924) in secti= on 6.3 says: The Next Protocol field in the NSH header may be used to indicate what O= AM function is intended or what toolset is used. Any other overlay encapsulations used at the s= ervice layer must have a similar way to indicate the intended OAM function. So my reading of this is that if you take 8300 together with the framework = then 1. The O-bit MUST be set for OAM packets, and 2. The Next Protocol fie= ld may or may not be used to indicate which OAM function is to be applied. = >From this I can determine that iOAM has taken the approach of using the nex= t protocol field to indicate how to process the OAM packet and does NOT use= the NSH context headers in any way shape or form. This seems consistent wi= th the current definitions of the O-bit from RFC 8300 and processing guidel= ines from RFC 8924. However, your document says: 4.1. IOAM and the use of the NSH O-bit [RFC8300] defines an "O bit" for OAM packets. Per [RFC8300] the O bit must be set for OAM packets and must not be set for non-OAM packets. Packets with IOAM data included MUST follow this definition, i.e. the O bit MUST NOT be set for regular customer traffic which also carries IOAM data and the O bit MUST be set for OAM packets which carry only IOAM data without any regular data payload. This text basically says that if the packet is customer traffic and happens= to carry iOAM data then it is NOT an OAM packet. What am I missing, custo= mer traffic or not, both carry iOAM data so how are they different within a= n SFC domain? In addition to the above I will note that there is still a conflict with Gr= eg's draft namely this text from section 4: * O bit set and the "Next Protocol" value does not match the value Active SFC OAM (TBA1), defined in Section 10.1: - An SFC NSH Context Header(s) contain an OAM processing instructions or data. - The "Next Protocol" field determines the type of the payload. The above text suggests to me that if the O-bit is set and the next protoco= l is not active SFC OAM then it is *required* that OAM data will be in the = NSH context headers (which is not the case for iOAM) and the next protocol = will indicate what follows the NSH header. While iOAM does follow the NSH h= eader as indicated by the next protocol there is still an expectation that = OAM is also carried in the NSH context headers. This seems to be in conflic= t with RFC 8300 AND RFC 8924. This of course is just my reading of the text and I would like to hear your= s and other folks thoughts. Jim From: Shwetha Bhandari > Sent: Monday, January 31, 2022 11:25 PM To: Greg Mirsky > Cc: James Guichard >; draft-ietf-sfc-ioam-nsh@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc= -ioam-nsh/ Hi Greg, Sorry for the late action on this. https://datatracker.ietf.org/doc/html/dr= aft-ietf-sfc-ioam-nsh-07 has been now posted with = the edits per this discussion. Hi Jim, After Greg's review please let us know if the changes are good to progress = the draft to the next step. Thanks, Shwetha On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky > wrote: Hi Shwetha, thank you for the detailed response to my comments. Please feel free to sha= re any updates you're considering for the next version. I'll be glad to wor= k together on these. I have several follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari > wrote: Hi Greg, Sorry for the very late reply. Please find responses to your comments inlin= e @Shwetha: On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky > wrote: Dear Authors and All, I've read the current version of the draft and have some comments I'd like = to share with you. I much appreciate your thoughts on where this work shoul= d go considering developments in other IETF WGs. Please find my notes and q= uestions below: * It is stated in the Abstract that: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. But that is the case only for the pre-allocated and incremental trace optio= n types. The Direct Export option does not write telemet= ry data into the data packet itself but export telemetry information in a s= pecially constructed packet. And as we are talking about different IOAM trace options, the question of t= he scope of this document seems appropriate. There is a WGLC on two IOAM do= cuments active through September 15th at t= he IPPM WG. I believe that it would be beneficial if we had a single docume= nt that describes the applicability of IOAM in all its functionality define= d by documents in IPPM WG. Of course, that cannot be a moving target as tha= t would not be helpful. But since the IPPM WG discusses the progress of two= IOAM documents, it could be a great time to address the applicability of t= he Direct Export trace type and Loopback and Active flag= s defined in draft-ietf-ippm-ioam-flags. It would be concerning = to have more than one SFC document describing the applicability of the gene= ric IOAM mechanisms Shwetha> This is a fair point. We will revise the draft with text in the a= bstract and Section 3 IOAM-Type to be updated to include the usage of trace= and DEX options. The encapsulation of IOAM options within NSH itself in i= ts current form already supports all the IOAM Option Type defined both from= draft-ietf-ippm-ioam-data and draft-ietf-ippm-ioam-direct-export along wit= h the flags supported within the options. Hence the IOAM-data-field definit= ions in the draft will remain unchanged. GIM>> I agree that the definitions of the IOAM data-fields are invariant in= various data plane encapsulations. You likely follow the discussion of the= IAOM Direct Export and IOAM flags on the IPPM WG list. I think that for SF= C NSH, IOAM Direct Export could be as simple as "use the local policy". The= applicability of the Loopback and Active flags seems to require detailed e= xplanation by SFP actors. * The location of the IOAM header in the SFC NSH-encapsulated packet is= defined in Section 3: IOAM-Data-Fields are carried in NSH using a next protocol header which follows the NSH MD context headers. I've checked RFC 8300 but couldn't find it defines the Next Protocol header= . Also, it appears that NSH Context headers are optional. Hence my question= . Is the presence of an NSH Context header required when using IOAM? Could = you clarify which mechanism is used to identify the payload of an SFC NSH-e= ncapsulated packet as IOAM? Shwetha> We will reword it, it is not Next Protocol header but using IOAM a= s a Next Protocol as described in Section 4.1 and requested in IANA section= . Following is the proposed text to align with the RFC 8300 reference to co= ntext headers following base header and service path header: "The NSH is defined in [RFC8300]. IOAM-Data-Fields are carried in NSH usin= g a next protocol to identify IOAM data fields that follows NSH context hea= ders." GIM>> I think that RFC 8300 views data following Context Headers as NSH pay= load, not being "in NSH". * If I understand the format of the IOAM header defined in Section 3 co= rrectly, the header's length is limited by 1020 octets, while the effective= length containing IOAM options and data - 1016 octets. Is that correct? Wh= at is the recommended technique of collecting IOAM data that exceeds that l= imit? Shwetha > IOAM options inherently support specifying the size limits at the= node that added the IOAM options. While operationalizing the solution the = data types included and number of nodes expected to be adding the data shou= ld be selected. This is covered in deployment considerations draft-brockner= s-opsawg-ioam-deployment. * In Section 4.1, I've found the text reflecting the history of the dis= cussion about how to carry the IOAM header using NSH encapsulation. As the = text has no normative value, I suggest moving it into an Appendix. Shwetha > Agreed, revised draft will have this section moved to Appendix. GIM>> Thank you. * I find the rules of handling the O-bit in NSH listed in Section 4.2 i= nconsistent and confusing. The IOAM header is not part of NSH encapsulation= but is a part of the payload. But in one case, when user data follows it, = the O-bit must not be set as. If there's no user data after the IOAM header= , then the O-bit must be set. But from the perspective of NSH encapsulation= , it includes specially constructed data added for the sole purpose of coll= ecting OAM/telemetry information. Then, why, in one case, the O-bit is clea= red and in the other set if, in both cases, the NSH-encapsulated packet is = used to perform the OAM function? Shwetha > The reason for not setting the O-bit for packets that contains ac= tual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier implem= entations that do not support SFC OAM procedures SHOULD discard packets with O bit set". It will be= undesirable to discard packets with O-bit set that carry user data as IOAM= can be inserted insitu. For synthetic traffic created for OAM along with IOAM-data-fields in NSH fo= llowing the NSH OAM function with 0-bit set is desirable. GIM>> This is an interesting situation. I agree that there could be an SFC= element not supporting "SFC OAM procedures" (not clear what these are). By= the same token, would such SFC element support IOAM, be capable of process= ing IOAM without adverse impact to user data? I am not certain and it seems= that it might be better to recommend that NSH packets with IOAM be dropped= by an SFP element if it does not support "SFC OAM". What are your thoughts= ? Thanks, Shwetha I much appreciate your consideration of my comments and questions and looki= ng forward to your feedback. Regards, Greg On Wed, Aug 18, 2021 at 5:32 AM James Guichard > wrote: Dear WG: This email starts a 2 week Working Group Last Call for draft-ietf-sfc-ioam-= nsh [1]. Please read this document if you haven't read the most recent version and s= end your comments to the SFC WG list no later than September 1st 2021. If you are raising a point which you expect will be specifically debated on= the mailing list, consider using a specific email/thread for this point. Lastly, if you are an author or contributor please response to indicate whe= ther you know of any undisclosed IPR related to this document. Thanks! Jim & Joel [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_MN2PR13MB420615DA403388EA0144A9C1D22F9MN2PR13MB4206namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shwetha,

 

My only point was that in the case of IOAM the O-bit= seems to be obsolete as you use the next protocol field rather than the co= ntext headers. It seems to me that the definition of the O-bit should be th= at if set then the context headers are used to obtain the OAM instructions. Currently that is not what 8300 s= ays. As I said in my previous emails I would really like to hear the WGs op= inion on what to do with the O-bit and we certainly need to reconcile the v= arious documents to be following the same standard.

 

Jim

 

From: Shwetha Bhandari <shwetha.bhandari@t= houghtspot.com>
Sent: Wednesday, February 9, 2022 9:57 AM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: James Guichard <james.n.guichard@futurewei.com>; draft-iet= f-sfc-ioam-nsh@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-i= etf-sfc-ioam-nsh/

 

Hi Jim,

 

On the O bit handling, are you suggesting that the O= -bit for IOAM, that is carried as a next protocol following NSH header= , is not applicable? Would removing the section on O-bit considerations res= olve your concern?

 

Hi Greg,

 

>I have one more question. As the draft now menti= ons the option of using IOAM Direct Export to collect the IOAM data, it mig= ht be helpful reflecting that in the figure on p.2. I think that the captio= n "IOAM Option and Data Space" might be reworded to "IOAM Option and Optional Data Space".<= /o:p>

What are your thoughts?

Yes, that will make it accurate. I will update the d= iagram and publish a new version.

 

>I cannot find the text in the draft suggesting t= hat an SFF that does not support IOAM may forward the packet with the NSH N= ext Protocol field equal to IOAM protocol identifier. Could you help me fin= d it?

Can you suggest text to help with this ? This would = be a generic problem for NSH implementation when a next protocol is set to = a value it does not understand. What should is recommended action in this s= ituation?

 

 

> For example, if the Loopback IOAM flag is set, = the node is required to send a copy of the packet back to the IOAM encapsul= ating node. It is not clear to me how an SFF learns the identity of the IOA= M encapsulating node and how it encapsulates the loopbacked packet. Can you help me find how it is supposed to work in = the NSH? 

  A Loopb=
ack flag that is set indicates to the transit nodes processing
   this option that they are to =
create a copy of the received packet and
   send the copy back to the sou=
rce of the packet.

Given this is explained in the flag handling, do you= see a need to define it again in NSH? IMHO the explanation of flag handlin= g is quite generic for any packet based transport.

Please share your thoughts and text suggestions to i= mprove the draft for flag handling if it requires clarification. =

 

 

Thanks,

Shwetha

 

On Thu, Feb 3, 2022 at 6:48 AM Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Shwetha,

I have one more question. As the draft now mentions = the option of using IOAM Direct Export to collect the IOAM data, it might b= e helpful reflecting that in the figure on p.2. I think that the caption &q= uot;IOAM Option and Data Space" might be reworded to "IOAM Option and Optional Data Space".

What are your thoughts?

 

Regards,

Greg

 

On Wed, Feb 2, 2022 at 7:29 AM Shwetha Bhandari <= shwet= ha.bhandari@thoughtspot.com> wrote:

Hi Jim, Greg,

 

Thanks for the follow up.

1) On O-bit: I am a bit confused about the O-bit fee= dback. Are you suggesting that it should not be a consideration for IOAM as= it is handled as a next protocol and not as NSH context headers?

What should a SFC element handle a packet containing= IOAM as next header and does not implement IOAM and hence does not underst= and IOAM? I think O-bit helps in such situations to help such elements deci= de to drop or forward without processing the IOAM header.

Let me know if that is not the case and if simply no= t considering O-bit in the context of IOAM is what you would recommend.

2) Active or Loopback flags - there is nothing specific for NSH = on how the flags are to be handled.  The IOAM specific fields are to b= e handled as recommended by the respective IOAM drafts. Do you see any spec= ific NSH considerations to be documented for IOAM fields?

 

Thanks,

Shwetha

 

 

 

 

 

 

 

On Tue, Feb 1, 2022 at 4:29 PM James Guichard <james.n.g= uichard@futurewei.com> wrote:

Hi Shwetha & Greg,

 

Thank you for the update.

 

I still believe however that more work is necessary to reconcile h= ow SFC OAM is supposed to work. RFC 8300 says:

 

   O bit:  Setting this bit indicates an OAM = packet (see [RFC= 6291]).

      The actual format and process= ing of SFC OAM packets is outside the

      scope of this specification (= for example, see [SFC-OAM-FRAMEWORK]=

      for one approach).

 

      The O bit MUST be set for OAM= packets and MUST NOT be set for

      non-OAM packets.<= /o:p>

 

If we look at RFC6291 it simply describes what OAM is supposed to = mean and this is independent from SFC. The SFC-OAM-Framework (now RFC 8924)= in section 6.3 says:

 

   The Next Protocol field in the NSH header may b= e used to indicate what OAM function is intended

   or what toolset is used.  Any other overla= y encapsulations used at the service layer must have a

   similar way to indicate the intended OAM f= unction.

 

So my reading of this is that if you take 8300 together with the f= ramework then 1. The O-bit MUST be set for OAM packets, and 2. The Next Pro= tocol field may or may not be used to indicate which OAM function is to be applied. From this I can determine th= at iOAM has taken the approach of using the next protocol field to indicate= how to process the OAM packet and does NOT use the NSH context headers in = any way shape or form. This seems consistent with the current definitions of the O-bit from RFC 8300 and pro= cessing guidelines from RFC 8924.

 

However, your document says:

 

4.1.  IOAM and the use of the NSH O-bit

 

   [RFC8300] defines an "O bit" for OAM = packets.  Per [   bit must be set for OAM packets and must not be= set for non-OAM

   packets.  Packets with IOAM data included = MUST follow this

   definition, i.e. the O bit MUST NOT be set for = regular customer

   traffic which also carries IOAM data and the O = bit MUST be set for

   OAM packets which carry only IOAM data without = any regular data

   payload.

 

This text basically says that if the packet is customer traffic an= d happens to carry iOAM data then it is NOT an OAM packet.  What am I = missing, customer traffic or not, both carry iOAM data so how are they different within an SFC domain?

 

In addition to the above I will note that there is still a conflict with= Greg’s draft namely this text from section 4:

   *  O bit set and the "Next Protocol&q= uot; value does not match the value

      Active SFC OAM (TBA1), define= d in Section 10.1:

 

         - An SFC NS= H Context Header(s) contain an OAM processing

         instruction= s or data.

 

         - The "= ;Next Protocol" field determines the type of the payload.<= /o:p>

 

The above text suggests to me that if the O-bit is set and the nex= t protocol is not active SFC OAM then it is *required* that OAM data= will be in the NSH context headers (which is not the case for iOAM) and the next protocol will indicate what = follows the NSH header. While iOAM does follow the NSH header as indicated = by the next protocol there is still an expectation that OAM is also carried= in the NSH context headers. This seems to be in conflict with RFC 8300 AND RFC 8924.

 

This of course is just my reading of the text and I would like to = hear yours and other folks thoughts.

 

Jim

 

From: Shwetha Bhandari <shwetha.bhandari@thoughtspot.com&= gt;
Sent: Monday, January 31, 2022 11:25 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: James Guichard <james.n.guichard@futurewei.com>; draft= -ietf-sfc-ioam-nsh@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

 

Hi Greg,

 

Sorry for the late action on this. https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 has be= en now posted with the edits per this discussion. 

 

Hi Jim,

 

After Greg's review please let us know if the changes are good to = progress the draft to the next step.

 

Thanks,

Shwetha

 

On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky <gregimirsky@gmail.com> wrot= e:

Hi Shwetha,

thank you for the detailed response to my comments. Please feel fr= ee to share any updates you're considering for the next version. I'll be gl= ad to work together on these.

I have several follow-up notes in-lined below under the GIM>>= ; tag.

 

Regards,

Greg

 

On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari <shwetha.bhandari@t= houghtspot.com> wrote:

Hi Greg,

 

Sorry for the = very late reply. Please find responses to your comments inline @Shwetha:

 

 

 

On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <gregimirsky@gmail.com> wrote= :

Dear Authors and All,

I've read the current version of the draft and have some comments = I'd like to share with you. I much appreciate your thoughts on where this w= ork should go considering developments in other IETF WGs. Please find my notes and questions below:

  • It is stated in the Abstract that:

   In-situ Operations, Administration, and Maintenance (= IOAM) records
   operational and telemetry information in the packet while the = packet
   traverses a path between two points in the network.=

But that is the case only for the pre-allocated and incremental tr= ace option types. The Direct Export option does not write telemetry data into the data p= acket itself but export telemetry information in a specially constructed pa= cket. 

And as we are talking about different IOAM trace options, the ques= tion of the scope of this document seems appropriate. There is a WGLC on two IOAM documents active through September 15th at the IPPM = WG. I believe that it would be beneficial if we had a single document that = describes the applicability of IOAM in all its functionality defined by doc= uments in IPPM WG. Of course, that cannot be a moving target as that would not be helpful. But since the IPPM= WG discusses the progress of two IOAM documents, it could be a great time = to address the applicability of the Direct Export trace type and Loopback and Active flags defined in&n= bsp;draft-ietf-ippm-ioa= m-flags. It would be concerning to have more than one SFC document describing the a= pplicability of the generic IOAM mechanisms

 

Shwetha> Th= is is a fair point. We will revise the  draft with text in the abstrac= t and Section 3 IOAM-Type to be updated to include the usage of trace and DEX options.  The encaps= ulation of IOAM options within NSH itself in its current form already suppo= rts all the IOAM Option Type defined both from draft-ietf-ippm-ioam-data and draft-ietf-ippm-ioam-direct-export along with the flags su= pported within the options. Hence the IOAM-data-field definitions in the dr= aft will remain unchanged. 

GIM>> I agree that the definitions of the IOAM data-fields a= re invariant in various data plane encapsulations. You likely follow the di= scussion of the IAOM Direct Export and IOAM flags on the IPPM WG list. I think that for SFC NSH, IOAM Direct Export co= uld be as simple as "use the local policy". The applicability of = the Loopback and Active flags seems to require detailed explanation by SFP = actors.

 

 

  • The location of the IOAM header in the SFC NSH-encapsulated packet is = defined in Section 3:

   IOAM-Data-Fields are carried in NSH

   using a next protocol header which follows the NSH MD= context

   headers.

I've checked RFC 8300 but couldn't find it defines the Next Protoc= ol header. Also, it appears that NSH Context headers are optional. Hen= ce my question. Is the presence of an NSH Context header required when using IOAM? Could you clarify which mechanism= is used to identify the payload of an SFC NSH-encapsulated packet as IOAM?=

Shwetha> We= will reword it, it is not Next Protocol header but using IOAM as a Next Pr= otocol as described in Section 4.1 and requested in IANA section. Following is the proposed text to align with the RFC 8300 re= ference to context headers following base header and service path header:

"The NSH = is defined in [RFC8300].  IOAM-Data-Fields are carried in NSH usi= ng a next protocol to identify IOAM data fields that follows NSH context headers."

GIM>> I think that RFC 8300 views data following Context Hea= ders as NSH payload, not being "in NSH". 

  • If I understand the format of the IOAM header defined in Section 3 correctl= y, the header's length is limited by 1020 octets, while the effective lengt= h containing IOAM options and data - 1016 octets. Is that correct? What is = the recommended technique of collecting IOAM data that exceeds that limit?

Shwetha > I= OAM options inherently support specifying the size limits at the node that = added the IOAM options. While operationalizing the solution the data types included and number of nodes expected to be adding= the data should be selected. This is covered in deployment considerations&= nbsp;draft-brockners-opsawg-ioam-deployment.

  • In Section 4.1, I've found the text reflecting the history of the discussio= n about how to carry the IOAM header using NSH encapsulation. As the text h= as no normative value, I suggest moving it into an Appendix.

Shwetha > A= greed, revised draft will have this section moved to Appendix. =

GIM>> Thank you. 

  • I find the rules of handling the O-bit in NSH listed in Section 4.2 inconsi= stent and confusing. The IOAM header is not part of NSH encapsulation but i= s a part of the payload. But in one case, when user data follows it, the O-= bit must not be set as. If there's no user data after the IOAM header, then the O-bit must be set. But from t= he perspective of NSH encapsulation, it includes specially constructed data= added for the sole purpose of collecting OAM/telemetry information. Then, = why, in one case, the O-bit is cleared and in the other set if, in both cases, the NSH-encapsulated packet is use= d to perform the OAM function?

Shwetha > T= he reason for not setting the O-bit for packets that contains actual user d= ata is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier implementations that do not support

  &n=
bsp;   SFC OAM procedures SHOULD discard packets with O bit set&q=
uot;. It will be undesirable to discard packets with O-bit set that carry u=
ser data as IOAM can be inserted insitu.
For synthetic =
traffic created for OAM along with IOAM-data-fields in NSH following the NS=
H OAM function with 0-bit set is desirable. 

 GIM>> This is an interesting situation. I agree that t= here could be an SFC element not supporting "SFC OAM procedures" = (not clear what these are). By the same token, would such SFC element support IOAM, be capable of processing IOAM without adverse im= pact to user data? I am not certain and it seems that it might be better to= recommend that NSH packets with IOAM be dropped by an SFP element if it do= es not support "SFC OAM". What are your thoughts?

 

 

Thanks,=

Shwetha=  

I much appreciate your consideration of my comments and questions = and looking forward to your feedback.

 

Regards,

Greg

 

On Wed, Aug 18, 2021 at 5:32 AM James Guichard <james.n.guichard@futur= ewei.com> wrote:

Dear WG:

 

This email starts a 2 week Working Group Last Call for draft-ietf-= sfc-ioam-nsh [1].

 

Please read this document if you haven’t read the most recen= t version and send your comments to the SFC WG list no later than September= 1st 2021.

 

If you are raising a point which you= expect will be specifically debated on the mailing list, consider using a = specific email/thread for this point.

 

Lastly, if you are an author or cont= ributor please response to indicate whether you know of any undisclosed IPR= related to this document.

 

Thanks!

 

Jim & Joel

 

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

 

 

 

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

--_000_MN2PR13MB420615DA403388EA0144A9C1D22F9MN2PR13MB4206namp_-- From nobody Thu Feb 10 19:26:38 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F8F3A08C6 for ; Thu, 10 Feb 2022 19:26:35 -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, 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 2GqSs5_mWe-6 for ; Thu, 10 Feb 2022 19:26:31 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20707.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e8a::707]) (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 7F70A3A08BF for ; Thu, 10 Feb 2022 19:26:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QynJzQWzy7APaHIOjD8PX47UVIyPEz9u7fe/pxfHdnxt/dxxU4ALkf5fnZKT0zPZ6FNbDtxWAyPgzI0GjXXZpPREwZhpLDmRqZhsnbRBxoMeyglsbQjK11oE4ucMileLOZM9BW3SYm4JJIzrdXjIPGMJhvY4syjn6uvST5KnZPeQAOEMjKxyqau4Z0j8iGJ5Jp5/IBAo3D838OjrxSC1bPvU9vNhO/mwleiHStA4vrOS2zTb6bcrQblNuUTctCEz4g0OjKVdsHU0TvMEUkzdLQ9EmZtkOFumoAMHgj966h+a5g9onjZkY/7N3wM+PJsM1QuBDtan8gcYXwIP0Djmyg== 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=7TIVicAdCk+bucDg2IgiIrw4Jsr/UKILiFsAGRUKKP8=; b=DdqFCFbZIftUM5hFAa6uInHKxLgeKaKiO9t6AMgN+f2ypqiHX+SUHL1eFiDHDwHLNjaUInKzxk/VF9hGJvRJama7uh03zEVJtXCgCR8xYuZ6WIYLt9QoZJeqjbuch3UXxbIks4qNoKP5oq1qrVWRZg9X50CbzzkCd4FBQaYlcenIqIW9A9awPv6uKiBDVRtSfXO170rb4ogKR0pRg9KdkW1b+EKTGa7Q0XBjyflUusObTfJyjQsfQi0/DQ6RP79G5fNYcjVXWQLN4QJJQ8HNw4tkQ7YE0EF+mqNYoVc/5rC9rh84XRrc9VlWm5vUi6g/yJGRWtuHNXjXplQZlIbOdQ== 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=7TIVicAdCk+bucDg2IgiIrw4Jsr/UKILiFsAGRUKKP8=; b=ljYfSH7fr+HWKpTBTTPaHN7E+9I5qOQT9GSgpGvpdyeHN7vrlQ/Yo+ckmAaxMfjIRTChvfmuF0qn9SjESJyp10tHc3oaxwLFd95JFn4f+spgmRUpM7RZVBtXXvYonRGlThemdZtAOfaL9tgcfR9utJopDoooGdJ9xAxbG2n1dGk= Received: from BYAPR13MB2582.namprd13.prod.outlook.com (2603:10b6:a03:b2::19) by CY4PR13MB1447.namprd13.prod.outlook.com (2603:10b6:903:131::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.8; Fri, 11 Feb 2022 03:26:22 +0000 Received: from BYAPR13MB2582.namprd13.prod.outlook.com ([fe80::15b2:d043:d385:5795]) by BYAPR13MB2582.namprd13.prod.outlook.com ([fe80::15b2:d043:d385:5795%5]) with mapi id 15.20.4995.007; Fri, 11 Feb 2022 03:26:22 +0000 From: Michael McBride To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Future of SFC work Thread-Index: AQHYFHoLdzO/OfC1j06bwBmFTpFvE6yNv+SA Date: Fri, 11 Feb 2022 03:26:22 +0000 Message-ID: References: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> In-Reply-To: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.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: f62dbb0e-0ce9-48a8-199c-08d9ed0e46f1 x-ms-traffictypediagnostic: CY4PR13MB1447: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: r16WOGRu6DPi6udONx7mQoOlz0tRcd7UcatD6BijfvVD1fpFcQBh5f6INYVX993ydA9m8DuDvZl8H0QdR0E+Yj1bQx4H6aPVJHgs5SWnPmls6iyC31aZJzH74sOQRqpDNGlRrRR0j6XGFX/pDEmQz9vzMsLmxQ1VtHvEpby6xlpdKO8rEMzENLUcjKdQ2ji/j8JF3+zY+ipWKbO4m8ZGk3l4h1Uv48j6VxnRByxQgwls0AQyE/kULl++7pcwHeClMzwp7RyXKQGti3+1CJfE6n6/3CappqYtJJE2JjKPQW8TmW8s4NoqviVlLqqTov3FNMvLvEl7jpSN/bMk4/+EIxojYpwD7mkvL5/ZTJ8bk7LzOZITly+iosh0DdCwz6wLVV0FzXTk11Zx61OpPBKwcLhhWeJLfznogPHUzSfc6NjVfLeXLUOcffw0irw2Lmf9dmikF94WiOcsYfZq9BCYAofMGh5tXquHPH+ngQ6cvmMkyIhC5xKhsaZokLNoBySPEI9tHNWQlfvh/2lL1mAcJghRulKW3zF6aHTRt6v8m8ZuY7Q5y1yYonOgnidzikNccb/NrTMdAlOKRG/PbouMi6e8Qc/z2K3AeN2SZxTHA9k3sBZC82biJFoin6KTK1z/tugcot3xBlAeDa66b/tnA7aRldTYjSaIZZ9hUcZQ/L9hCmV9yrfWzWtuEiI2o5f0KezBTWFex81CB8/HbXdq0H4L8fRr8RW5CBRzXIkRhxD6w/Z7mAieqmEB0vMqPSIM0q/6+uVmSj3IJYzJRdRA9rpCfy3kkYpapMRnGwhkuzZW0jZjbzmfWaLZumBUH/9c5HYM7qZFh63MEPykoMFYjQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR13MB2582.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38100700002)(86362001)(2906002)(66556008)(8676002)(66446008)(66946007)(66476007)(76116006)(64756008)(122000001)(6506007)(110136005)(316002)(38070700005)(71200400001)(53546011)(9686003)(7696005)(55016003)(966005)(52536014)(5660300002)(8936002)(508600001)(83380400001)(45080400002)(186003)(33656002)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?J02Sr7Ffw18hUcdrIKU2A0Aoq9ty/1FjmzF507eb5dB1Q1+CHCe6WFdD9oZO?= =?us-ascii?Q?bktegtqQPXLoWqxmvabrTHcne0cFTxiBoKrBsOzkdj/8EptBKoPP9epXfOfg?= =?us-ascii?Q?wAltuxrbJ8SYiTUf0ffdlOh6e2r87Ch2sn0mRPDReiHx8PF4KfkeEBqfvIyC?= =?us-ascii?Q?+VCanNiSSBFgV72+fJ4sdKaOPZcJk/uzJo5EvCJQSnZfdWY/KjJ4o2N+0u47?= =?us-ascii?Q?pBihvwqowUsMSXF7rFS8y3aglkdSEhELE/9iyybwx0wD0i5LOt08BiEhsf7E?= =?us-ascii?Q?veqNejcRR0FdaDG/NM2GW+ldd8cc/qJf/JkzmRsCPotLbQEYtgt+GD+r2OVe?= =?us-ascii?Q?VcKM5RkJvPOxNGO0WC0bxSwkJU19tnh6mzK1qAIRoDw4lYTf9LCzHKbkPszD?= =?us-ascii?Q?uxBXb2QzfPScA07/jZxY1qvcaiLi2Zp24kz3ZNZkKYkdtIpV+EZ7Le2xBdfy?= =?us-ascii?Q?womOHrTL0O8mnBaeuQKYSuBZ94MFKL5hT1vuORObEZIIUx7sx/R2CXcDoJ1n?= =?us-ascii?Q?G3fQTTlGvGGt9WNYOazLcpTp2UKp86SePE9S6iwpJVKGVU7WMUcT7OyXsIow?= =?us-ascii?Q?Epqq2dTunFw3V+kVAgvqJ5cqapxMITNtDS3MkB/7COIhUPuTvYcz1HWHS/32?= =?us-ascii?Q?FaIcZ9YhGub/8+57k5VtJdpcv1xmFKGEtXiIr2VGE60r+yrsUWyRaf9y3cDe?= =?us-ascii?Q?3gwCHDS6Q70Qab51THB8Fv8SyBpnEkYHgxzGGmKM1u4XRTvzuDANbEwTtw9g?= =?us-ascii?Q?f5xKAkxqQnRA+fvrnWdXpKip4leLvSy1JTik8WsrYeBT/i8OEFnlRd+dyqL5?= =?us-ascii?Q?0dOvVvepSDfrmIKF8ja/nL2BTliy79+69NTz5EGeg+/GC7W6nJTTYvDXFDXe?= =?us-ascii?Q?ALbIaaOM2PMlvaClFozZ2R69sSLGYoUPFTfg/b01echtObfbh8CcKTynlxqQ?= =?us-ascii?Q?rC+lhr2kFBUXx+1yq3kvrV1/TcwfXc8jdtSqfD+cTEVKEhe8AZKpRrlot1Fo?= =?us-ascii?Q?q4a4JpZxYrIAfwiicLsYRz/so1X2H3Gxlw5IDVD2WDY5cqgJ+pxR3ZkTchUN?= =?us-ascii?Q?H0n95PbmphDFVrqYu2rwCkf6JP6HDOsjvof9GglKzRer26XqAahXx6fzin4K?= =?us-ascii?Q?L5SOwGFSEwdtAFTj4oIASkHGJYvE6yPki98Wldr6wgpC7YMtZ641XqWOTzEG?= =?us-ascii?Q?+MlPfD1btxfMUM9bKP3UMUiVdGdMBLq6gclYO662arC7VLUk2DVxR8rl72mZ?= =?us-ascii?Q?ETHA2NzFZMeGWz44sFgGOAjh/rcuaaEptZ31Abnjwop9Cu1kpfrg8OSXOZUZ?= =?us-ascii?Q?ukX5ASuqa2R4FMTHhRKiaLKyA7fUBNPaPBWOamJ0OcbHQjoJqJENjaNVaxgt?= =?us-ascii?Q?+7PBcHGqoS0QFObVAm7YyOR6H3JEy84iZ8hF7nasze2OqZYObfKSh7S1qVWI?= =?us-ascii?Q?eBU4iNsV9BIpg5vPZRiyVpHHo6kUvzAITzrjVTXBuQGyCRWiMVoU5mzyxzly?= =?us-ascii?Q?H6UtBLb9e7x+io6vA+GNnMsG+uSXaW2h6LCeWTaAfMNMvX4tK6I6WfWGmWzl?= =?us-ascii?Q?iMW3r6Xz1X8EB6dm/HV4Tj1fapACOe7yNhczv3LG+Ddn/s8veEEFX/ThGEzv?= =?us-ascii?Q?jXId2uj8r6d9qOnAwUGbnAA=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: BYAPR13MB2582.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f62dbb0e-0ce9-48a8-199c-08d9ed0e46f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2022 03:26:22.3916 (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: huOIo9f0mvTQaW+Iy0TDI659eMNVnjDAUBUhSHEYGeHh94GIoRY+fm9EeP2wJaLacDTdjDUyQhNb+Iv74ALzPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR13MB1447 Archived-At: Subject: Re: [sfc] Future of SFC work X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2022 03:26:36 -0000 Hi Joel and Jim, Many of us move to shiny new topics but I think there is still work to be d= one and would prefer expanding the scope of the wg by a recharter. I'd like= to see something about constraint based routing added to SFC for instance = and could commit to working on existing docs. Thanks, mike -----Original Message----- From: sfc On Behalf Of Joel M. Halpern Sent: Friday, January 28, 2022 11:05 AM To: sfc@ietf.org Subject: [sfc] Future of SFC work SFC Working Group: As part of discussing the OAM elated drafts in SFC, the chairs have be= en looking at the overall working group participation. We note that very f= ew people have spoken up about the issues being discussed. For most recent= drafts we have been working to advance, it has been a lot of work to get e= nough comments to justify advancement (and folks could argue that we did no= t succeed.) We are considering various alternatives. We could, for example, just = close the working group. One possibility is to recharter the working group to expand the scope.=20 There are two related questions that we would like to hear from the working= group about this. 1) If we were to consider expanding the charter, what things would you like= to see included in it? 2) If we do recharter will you work on the existing documents, and will you= engage on documents other than the one or two you personally would like to= see included? Thank you, Joel and Jim _______________________________________________ sfc mailing list sfc@ietf.org https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fsfc&data=3D04%7C01%7Cmichael.mcbride%40fut= urewei.com%7C5c213540aa7e46a4b01d08d9e2912b2e%7C0fee8ff2a3b240189c753a1d559= 1fedc%7C1%7C1%7C637789935420434369%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DUdj%2= BIqSYne72gle4HBn5YgpFG96JFaDhV45yiloxp8s%3D&reserved=3D0 From nobody Fri Feb 11 05:33:24 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426483A0D65; Fri, 11 Feb 2022 05:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.675 X-Spam-Level: X-Spam-Status: No, score=-7.675 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMXeXJRVPL9e; Fri, 11 Feb 2022 05:32:58 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20615.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::615]) (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 E6DC03A0033; Fri, 11 Feb 2022 05:32:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R1ru0eN4CttMbglb3MIilPnIdhuIfEa5wX3+b5MlJNv8oKs0uIbvuFjKGbqZGDsn4a3ryhg4XlG+Xk2sqzHfWYbvcX96VQUK4kKzJR4iOG38yXyvGoShn0fEjy8ehgYUM6DLjpA7KGEKNAO4n5p82j0zR5vBBfojCmLiCh79Sj6OeoggOu7CXbPwEt1BoGi0nREeHLjwuZS5IjZCTEDV51vpYsaqIrtBnpMX/a23PviqLFfsPazteqOt6ZoZRHIl+K7tNnaQ4PFrDsFJ4AKyzT4S8IfpJU1SKk2Rs1yQh6zi3G9GTLZqNYCk6RDVVeerGRGCWND40uGrZMyHWLDWvA== 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=gUW/pcrem2S63nU/YQDX7f4LmXLZueSgXUwy8wipv3s=; b=S74s73SuYk8LMVNVJ/DfpjLodE8I/IptA70BCk2C8i6uGPo98M+Ich6sf0tjZIMc99TetZtqzJg4PZ6l16Jz6HEI1+EmYMWfUmYN365Oxjg4vGHzWnkb6uZlNOXoCurSRWgXJDtNt/geGtwoXDjkOY/lI7bTIQpyL6U8N21lSGYsdpDsU5RciDy3UYTGDX2lChZgIZUaMulzKQlbBkVlH8Cu0FSOmPZv2pSHNa2q7mN7fvRMy1HqWF9Sbsot3lyy0nyLCfg7tcTPJ6J8PO6NWsjjh2hRtTLyOInSA7WflLd6LgHFtH5TYL8q2MEK6snwahmWA73VNnCzKat2F8Za0g== 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=gUW/pcrem2S63nU/YQDX7f4LmXLZueSgXUwy8wipv3s=; b=kARUedJvx9y92Lh53wTksbSFfXfprwNUR8TipwojWfIR0pccA5RME7huPdcpr9fhtjwU+ePY7Tqufp914ixsfPtQy//teqEKx8PDId2+StMymvnEQIXzxHcjrCbIBRdxLGIvAENwD+VptfzJPQICoPqXPdzQXVu9XuxkJEJLTwA= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by PR3PR07MB6827.eurprd07.prod.outlook.com (2603:10a6:102:5d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.8; Fri, 11 Feb 2022 13:32:51 +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.006; Fri, 11 Feb 2022 13:32:50 +0000 From: Francesca Palombini To: "wei.yuehua@zte.com.cn" , "martin.vigoureux@nokia.com" CC: "iesg@ietf.org" , "draft-ietf-sfc-nsh-tlv@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Thread-Topic: Re:[sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT) Thread-Index: AQHX5RA437So/X5KCEKu8XNUX02g8KwfI+QAgFXG+YCAGeD5Cw== Date: Fri, 11 Feb 2022 13:32:50 +0000 Message-ID: References: 163818356894.9882.14504113673742570287@ietfa.amsl.com, f511d5ec-a840-52bc-ec9a-da8b54403781@nokia.com <202201261014495204767@zte.com.cn> In-Reply-To: <202201261014495204767@zte.com.cn> 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: 4d7fe002-85e3-405f-09d6-08d9ed630025 x-ms-traffictypediagnostic: PR3PR07MB6827: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: vqoNCOWiwESF5zNvkUlYHMWAr11ocl+Cu0Fo2KDIxT8Z6wf5h6Yy6xWs3Qm9Qd5Oaw/uEZPnuq4KB7sbwDvhu/QwpWlX40DYfnXwIQEDAQ4ydlRaf3TUoJ2JNOklTXYjsfzr4fVnH1StQG++cqEFUE33t7xmsy92Y2+msLbZp2IJK9ZMnTL2taeAWvePP/wImDjRnXAwEDLFmNvAPQDPiM1iqZnvw2YJDJ5M+gwRoIItyb4KqyaCYG7iBgP02DyNmVX2SSmZle55buDZx2wtLdPqS66AUsq5B+26GZ/W74UopPW8aCGNdBiDlmmzqSEnvWuskO9xOv0NaE6SfdZi9eNJG33WGfha4/5Tclfdq/++sAqEV3zzZdDGm8r7A49oIfXR7rYp4/ssAsrcRQWRsx98pHraaJk2+JdVA/KD9xpTIkYl8+9syBXVspZ0iAifC+b6sqfXAKwGZdd3CTeZFOerR+xHHueQ0FhP2mKVstZ20PPfMwSciBS2z3oFIIBD83Z4mYp6Yp1V9gq6rtrbXs0ScgAf66l6QcOsYZvBs7mXx/1TErv7npq6QINUuBSzh8gySolxEL6bkMehc4IJ1GMJyGzLQkUbER5YDpzc4tDob5FCY9U3yjnAIqSHCtPf/QEasFApYJWLefU0aVfNG2jpeACjm722pJwKqnBKyya/BrfokozeJqp9c74eTTuEmzLiJkYktJbxepxJfgiyN94wk2H0hdp51Nlz/MGGjrfR7qwg+JS7Jg6Jr0I/5L9ZnJ2nLeD5+xvaAb7r7L00daZBGRQfr69Ph0QUaWhrqJKwc1LDJdxCfXo5DjPq70jbq3KXlWrwQ7ynpv4Stnp/Aw== 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)(38100700002)(4001150100001)(5660300002)(52536014)(71200400001)(44832011)(53546011)(508600001)(82960400001)(38070700005)(9326002)(55016003)(64756008)(66446008)(7696005)(9686003)(6506007)(66946007)(76116006)(66556008)(54906003)(83380400001)(186003)(966005)(2906002)(166002)(4326008)(110136005)(86362001)(316002)(122000001)(8936002)(8676002)(66574015)(66476007)(33656002)(91956017); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Y3hvWEJTbk5hbEJscDBsT2cxeDlSS1pnN1ZqTUZlT28wTlp4ZnB1NC9LRnVl?= =?utf-8?B?MmRBd1BVa3o4WFJIYjNqN0grSzR0dEtYZmh4NkVjcU5tMHIyc043YXZlSGRr?= =?utf-8?B?cG55Zzg2dHNDRzVVeDRPZk9TREwyNG9pY2xUdEoyNDJiUCt1VXBlWGc1d3JJ?= =?utf-8?B?UUs1NmxKQnZGSDlZRXRGL05weG14QXhiSzJOVk1QWDBWKzBteGg3MnVXTjdX?= =?utf-8?B?RWpzQXlxaWN0ZjFzOW1lU2h1TXp4STdKUnlQZzJVeEhBMnN2VnU3NlJXUXp2?= =?utf-8?B?L1V0cm9tZHM2Z0dhUmZEbndoL2M0WURyMU5GcjZ2SFBVU2NYWW5LTlVBV2dO?= =?utf-8?B?WnVHTkJGOUdsN0trRDVzWXh1SXBPUmIwdHN3ZjRJZ3F0TGFHN3ExaFNoaWVm?= =?utf-8?B?d0hDMTByOEUzdGNuYUF4cmFvU1FDbWFCSjVlcFlIK1JUSkdwVFBWMS9STkYr?= =?utf-8?B?Ky9Nbm9TREd6cm9lWE8zeWZ1RnVsVXBSd3A0cVRxK2ZGL1pGanMvOWZnZmN2?= =?utf-8?B?ci9HOWlES01DM3RZa2U3MDBaT0cvMkUyTHRERk1LTXJYa1loK3RnTjhuSHB1?= =?utf-8?B?MklvZ3NwQ1U1Sk5iK0ovYUJMcnlPMm14R3RjOUNwN2dWWWlhRUFFT0xxaUF2?= =?utf-8?B?VTlnc0xRQzdVOWhsVHdwQVZrczRCMy9iZ0VFTFpQVzROL21Bd2pFaS9KNHJX?= =?utf-8?B?S0cwOEtoUzRlVFFPMWVkelc2TTJ4M3BwaUQ5dDRobEo0NG1UWjkzWEJOMHZl?= =?utf-8?B?cEhReXIybGZhaUt4dnJTbzZtYTlQck1XcGlwcEtsejY3dnBwWGROVFdadTVU?= =?utf-8?B?SnZ3WWVSclk5eWYvVG43WEl6dU1zR095bDlkTS9IRC9vYnY4Q2lIYmtVcDVi?= =?utf-8?B?U3ZNREdabUhkcGRPdmNBVVR3cmNTeVRIYks5N3lyNUViNlFnUlUzT2NBM1Jv?= =?utf-8?B?OVgrTHduS0lGVDZ6YlgyQno4RTFLbTFmelJTczlyUmZiZzVBQzB1TVlHdVhV?= =?utf-8?B?NHNRUk5naGhncFJyY0pBMWNpN0VlcThaUTRVL2RVc3ZaZC9vNVpIMTFoelJj?= =?utf-8?B?M0ZmY0sxa0dRbmQ0MG42QS9XeFl0WDhWS2dTd3JKMWVsYWowc0lDS0NMWkUy?= =?utf-8?B?TkZCbUE4eDBxU0pwNzJEQ01jL0NWNlpPNXRMYVhlUTlFQVRlbDdTRWt3VGZv?= =?utf-8?B?b0poKy9WY2tPNmQ3bWNjS0EyeEt2c0NwMUdQV211eFlBbGRsUXJLUTVteC9V?= =?utf-8?B?NHNWZUU3RldxQVpBMm9nNWg4QnY5Mm9hL1RuL2VDejZiTFJJbUxBaUNOVjFW?= =?utf-8?B?TGJOYVM1eDZUV3E1WHM5azBMdjRETXA0WEY0ZTFqS2Z2VDFDdTAySzBqVVBI?= =?utf-8?B?TzAxeGlyYk1oekhSS2lXL0RhS2RZL1YzMXNVTVFuZTAvUmprVEprYWdxU1Vm?= =?utf-8?B?WWZqTlZiekxZY0JVT0loalEzZzRLbTNVdDB5dHdrTHdpaXVuWkFiWHdkZVhF?= =?utf-8?B?eUpiNlZZcElGUUk2V2xHYldKOTU3TGFMcEZ5RWdtTWhzSlhiN203TWl0YUps?= =?utf-8?B?SmJoWXhPZlk1emJka1YvSlA4dytBeEtIOUVWQUZBVUR5WXZsS3V0b3VvODRV?= =?utf-8?B?cTdkSXJKRzMwbmgwWDJTcFZHemN6RlhwQkZBT08rUFZwYnpZNzdmbENUU0dJ?= =?utf-8?B?Y2xQUzRZOHBCV1hOU3c3cGtDMG1iNEhuTlRNcmx1QkFuV2hkTjh3MGU0cE94?= =?utf-8?B?YkNSQk9RVHRyTFhySjBRQWNZaU9TdWlyTzhNY0Zyb2Z2NEtlNnFlZHBhU00w?= =?utf-8?B?NDFjMStadDVlVkwwSHhRLzVyeC81SzNpdFlEWTl2c1U0aFozWTRuV0ZoVW1M?= =?utf-8?B?S3R2aW5zdEVpek9uNkhRcjgwQWp2NndYbFdsZDR4NjdKOUJjdWExZjdyYWw2?= =?utf-8?B?ckE4TUlxZTFaNGk5bWNkb055YVFYU1FldFgyelBIeFcwTE5Eb3RPYlBtZ3FQ?= =?utf-8?B?QXNQWnp3em5BV3R4dmwza1RnWmFId3VSMCtyQU5JSm94SGh5Zk9DOUMwY0dt?= =?utf-8?B?NThRSXR1ak9oQnJOZXFFNC9OOXRLUy93U0hlMkl1Yno3TkpSY2xOd2NVZmJT?= =?utf-8?B?azNTWmJDcVFxZTVqbTBsQVBNV002eGlES1BwMkdrWWNaNWwvejdUUFhWYktF?= =?utf-8?B?RWhlbmVjTDloUmQ5TEdYUTlieVRHQmI0ZDJnQjN6SDk5Z1BiQmtTd3l0ekY0?= =?utf-8?B?WVZIRHZraE1LOHRKVHBUa1BYVXhZNGhXSFB5UTJiSDlBR05MREwwYWtPblRY?= =?utf-8?B?KzNaTDcwTEwweUN4dlBFWm5JWXBoN1EyT0NMR0VNQkx1YXVDSUhnN0FFUnVy?= =?utf-8?Q?ZWlu60CN6jmrMVLrZs8wCxrfjSh/TegbA6WutGc/zeZb3?= x-ms-exchange-antispam-messagedata-1: mAYABqrNj1RywZTw44CMM0PLeigRJuobcYY= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB42178E476E313EC8FA66E20098309HE1PR07MB4217eurp_" 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: 4d7fe002-85e3-405f-09d6-08d9ed630025 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2022 13:32:50.8827 (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: FIq5JtwleLKMgr58eh82bhpQQp0L281hYXvedB1tszkOdzmCZxBEWT1STUc/8324MoSjIEBMg+Qg1n9J3Ji38E+1Jv0Ux+5Lx3I0L8QYPNylxwrCQgA2UCsNiLEj9/VX X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR07MB6827 Archived-At: Subject: Re: [sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2022 13:33:04 -0000 --_000_HE1PR07MB42178E476E313EC8FA66E20098309HE1PR07MB4217eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWXVlaHVhLA0KDQpUaGFua3MgZm9yIHlvdXIgdXBkYXRlISBJdCBhZGRyZXNzZXMgYWxtb3N0 IGFsbCBteSBjb21tZW50cy4NCg0KSSBzdGlsbCBoYXZlIHRoZSBzYW1lIHByb2JsZW0gd2l0aCB0 aGUgZm9sbG93aW5nIHVuY2hhbmdlZCB0ZXh0Og0KDQoNCiAgICAgIFRlbmFudCBJRDogUmVwcmVz ZW50cyBhbiBvcGFxdWUgdmFsdWUgcG9pbnRpbmcgdG8gT3JjaGVzdHJhdGlvbg0KDQogICAgICBz eXN0ZW0tZ2VuZXJhdGVkIHRlbmFudCBpZGVudGlmaWVyLiAgVGhlIHN0cnVjdHVyZSBhbmQgc2Vt YW50aWNzDQoNCiAgICAgIG9mIHRoaXMgZmllbGQgYXJlIGRlcGxveW1lbnQgc3BlY2lmaWMuDQoN ClRoZSBxdWVzdGlvbiBiZWluZyBob3cgY2FuIHRoaXMgZmllbGQgYmUgaW50ZXJvcGVyYWJsZSBp ZiB0aGUgc3RydWN0dXJlIGFuZCBzZW1hbnRpY3MgaXMgZGVwbG95bWVudCBzcGVjaWZpYy4NCg0K VGhpcyB3YXMgZGlzY3Vzc2VkIGR1cmluZyB0aGUgdGVsZWNoYXQgKG1pbnV0ZXMgaGVyZTogaHR0 cHM6Ly93d3c2LmlldGYub3JnL2llc2cvbWludXRlcy8yMDIxL25hcnJhdGl2ZS1taW51dGVzLTIw MjEtMTItMDIudHh0ICksIGFuZCBCZW4gd2FzIGdyZWF0IGF0IHB1dHRpbmcgaW50byB3b3JkcyBt eSBjb25jZXJuOg0KDQpCZW46IElmIGl0J3MgZ29pbmcgdG8gYmUgdGhlIGJ5dGUgc3RyaW5nIHRo YXQgaXMganVzdCBjb25maWd1cmVkIGV2ZXJ5d2hlcmUgYW5kIHlvdSBqdXN0IGNoZWNrIGlmIGl0 IG1hdGNoZXMgb3IgZG9lc24ndCBtYXRjaCwgdGhhdCdzIHByZXR0eSBzdHJhaWdodGZvcndhcmQg YW5kIHRoYXQgaXMgcHJvYmFibHkgZ29pbmcgdG8gYmUgaW50ZXJvcGVyYWJsZS4gSSB0aGluayB5 b3UgY2FuIGdldCBzb21lIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIGlmIGl0J3MgYSB2YWx1ZSB0 aGF0IG1heSBvciBtYXkgbm90IGJlIGNvbmZpZ3VyZWQgYXMgb3BhcXVlIHRvIHRoZSBOU0ggaW1w bGVtZW50YXRpb24gYnV0IHRoZW4gaXQgaGFzIHRvIGJlIHByb2Nlc3NlZCBpbiBzb21lIHdheSBi eSB0aGUgcmVjaXBpZW50cywgYXMgdGhlIHNvZnR3YXJlIGltcGxlbWVudGF0aW9uIG9uIHRoZSBy ZWNpcGllbnQgaXMgb25seSBnb2luZyB0byBpbXBsZW1lbnQgc3VwcG9ydCBmb3Igc29tZSBmaXhl ZCBzZXQgb2YgZm9ybWF0cy4gSWYgdGhhdCBpbXBsZW1lbnRhdGlvbiBwaWNrcyBvbmUgc2V0IG9m IGZvcm1hdHMgYW5kIGFub3RoZXIgaW1wbGVtZW50YXRpb24gcGlja3MgYSBkaWZmZXJlbnQgc2V0 IG9mIGZvcm1hdHMsIHRoZXJlIG1heSBub3QgYmUgYW55IG92ZXJsYXAgc28geW91IG1heSBub3Qg YmUgYWJsZSB0byBhY3R1YWxseSBpbnRlcm9wZXJhdGUgaW4gdGVybXMgb2YgdGhlIGNvbnRlbnRz IG9mIHRoYXQgZmllbGQuIFRoYXQncyBhIGxpdHRsZSBmYXIgcmVtb3ZlZCBmcm9tIHRoZSBOU0gg cHJvdG9jb2wgaXRzZWxmIGJ1dCB0aGVyZSBpcyBwZXJoYXBzIHN0aWxsIHNvbWUgaW50ZXJvcGVy YWJpbGl0eSBjb25jZXJuIHRvIGJlIHdvcnJpZWQgYWJvdXQgdGhlcmUsIGRlcGVuZGluZyBvbiBo b3cgdGhpcyB2YWx1ZSBpcyBleHBlY3RlZCB0byBiZSBwcm9jZXNzZWQgYnkgdGhlIHJlY2lwaWVu dC4NCg0KDQpJIHdhcyBob3Bpbmcgc29tZSB0ZXh0IGNvdWxkIGJlIGFkZGVkIGFib3V0IGNvbmZp Z3VyYXRpb24sIGFuZCB3aHkgdGhpcyBzaG91bGQgbm90IGJlIGEgcHJvYmxlbSBpbiB0aGUgdXNl IGNhc2VzIG9mIHRoaXMgZG9jdW1lbnQuIEJhc2ljYWxseSBzb21lIG1vcmUgZGV0YWlscyBhYm91 dCB3aGF0IE1hcnRpbiBzYXlzOiBUaGUgcG9pbnQgaXMgcmVhbGx5IHRoYXQgYm90aCB0aGUgY2xh c3NpZmllciB0aGF0IHdlIGluc2VydCB0byB0aGF0IG1ldGFkYXRhIGFuZCBwb3NzaWJseSBzb21l IHZpcnR1YWwgbmV0d29yayBmdW5jdGlvbiB0aGF0IHdpbGwgcHJvY2VzcyBpdCwgYmUgY29uZmln dXJlZCB0aGUgc2FtZS4NCg0KVGhpcyBpbiBteSBvcGluaW9uIGlzIG5vdCBjbGVhciBlbm91Z2gg aW4gdGhlIGRvY3VtZW50IGFzIGlzLiBJdCBjb3VsZCBiZSBjbGFyaWZpZWQgaXRoZXIgaW4gdGhl IOKAnFRlbmFudCBJROKAnSBkZWZpbml0aW9uIG9yIGluIGEgc2VwYXJhdGUgcGFyYWdyYXBoLg0K DQpJ4oCZbGwgdXBkYXRlIHRoZSBESVNDVVNTIHRvIHJlZmxlY3QgdGhpcyBjb21tZW50Lg0KVGhh bmsgeW91LA0KRnJhbmNlc2NhDQoNCkZyb206IHdlaS55dWVodWFAenRlLmNvbS5jbiA8d2VpLnl1 ZWh1YUB6dGUuY29tLmNuPg0KRGF0ZTogV2VkbmVzZGF5LCAyNiBKYW51YXJ5IDIwMjIgYXQgMDM6 MTUNClRvOiBtYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbSA8bWFydGluLnZpZ291cmV1eEBub2tp YS5jb20+LCBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29u LmNvbT4NCkNjOiBpZXNnQGlldGYub3JnIDxpZXNnQGlldGYub3JnPiwgZHJhZnQtaWV0Zi1zZmMt bnNoLXRsdkBpZXRmLm9yZyA8ZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdkBpZXRmLm9yZz4sIHNmYy1j aGFpcnNAaWV0Zi5vcmcgPHNmYy1jaGFpcnNAaWV0Zi5vcmc+LCBzZmNAaWV0Zi5vcmcgPHNmY0Bp ZXRmLm9yZz4sIGdyZWdpbWlyc2t5QGdtYWlsLmNvbSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPg0K U3ViamVjdDogUmU6W3NmY10gRnJhbmNlc2NhIFBhbG9tYmluaSdzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi1zZmMtbnNoLXRsdi0wOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCkRlYXIgTWFy dGluIGFuZCBGcmFuY2VzY2EsDQpDb21iaW5lIHdpdGggeW91ciBjb21tZW50cyBhbmQgc3VnZ2Vz dGlvbnMsIEkgdXBsb2FkZWQgYSB2ZXIxMiB0byByZWZsZWN0ZWQgdGhlIHVwZGF0ZXMuDQpJIGFw cHJlY2lhdGUgeW91ciBmdXJ0aGVyIHJldmlldy4NClRoZSBsaW5rIG9mIGRpZmZlcmVuY2VzIGlz IDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNmYy1uc2gt dGx2LTEyLnR4dA0KDQoNCkJlc3QgUmVnYXJkcywNCll1ZWh1YSBXZWkNCk06ICs4NiAxMzg1MTQ2 MDI2OSBFOiB3ZWkueXVlaHVhQHp0ZS5jb20uY24NCi0tLS0tLS0tLS0tLS0tLS0tLeWOn+Wni+mC ruS7ti0tLS0tLS0tLS0tLS0tLS0tLQ0K5Y+R5Lu25Lq677yaTWFydGluVmlnb3VyZXV4DQrmlLbk u7bkurrvvJpGcmFuY2VzY2EgUGFsb21iaW5pO1RoZSBJRVNHOw0K5oqE6YCB5Lq677yaZHJhZnQt aWV0Zi1zZmMtbnNoLXRsdkBpZXRmLm9yZztzZmMtY2hhaXJzQGlldGYub3JnO3NmY0BpZXRmLm9y ZztncmVnaW1pcnNreUBnbWFpbC5jb207DQrml6Ug5pyfIO+8mjIwMjHlubQxMuaciDAy5pelIDIw OjMxDQrkuLsg6aKYIO+8mlJlOiBbc2ZjXSBGcmFuY2VzY2EgUGFsb21iaW5pJ3MgRGlzY3VzcyBv biBkcmFmdC1pZXRmLXNmYy1uc2gtdGx2LTA5OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0K SGVsbG8gRnJhbmNlc2NhLA0KDQp0aGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3LiBQbGVhc2Ugc2Vl IGlubGluZS4NCg0KSSBpbnZpdGUgdGhlIGF1dGhvcnMgdG8gc2hhcmUgdGhlaXIgdmlld3MuDQoN Ci1tDQoNCkxlIDIwMjEtMTEtMjkgw6AgMTE6NTksIEZyYW5jZXNjYSBQYWxvbWJpbmkgdmlhIERh dGF0cmFja2VyIGEgw6ljcml0IDoNCj4gRnJhbmNlc2NhIFBhbG9tYmluaSBoYXMgZW50ZXJlZCB0 aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1zZmMtbnNoLXRs di0wOTogRGlzY3Vzcw0KPg0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJq ZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1 ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gaW50 cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+DQo+DQo+IFBsZWFzZSByZWZlciB0byBo dHRwczovL3d3dy5pZXRmLm9yZy9ibG9nL2hhbmRsaW5nLWllc2ctYmFsbG90LXBvc2l0aW9ucy8N Cj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgaG93IHRvIGhhbmRsZSBESVNDVVNTIGFuZCBD T01NRU5UIHBvc2l0aW9ucy4NCj4NCj4NCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNmYy1uc2gtdGx2Lw0KPg0KPg0KPg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gVGhhbmsgeW91IGZv ciB0aGUgd29yayBvbiB0aGlzIGRvY3VtZW50Lg0KPg0KPiBJIGhhdmUgc29tZSBjb21tZW50cywg bW9zdGx5IGhhdmluZyB0byBkbyB3aXRoIGNsYXJpZmljYXRpb25zIGFuZCBpbXByb3ZlbWVudA0K PiBvZiB0ZXh0IGZvciByZWFkYWJpbGl0eS4gSSdkIGxpa2UgYW5zd2VycyB0byB0d28gbWFpbiBw b2ludHM6IGZpcnN0IC0gSSBiZWxpZXZlDQo+IHRoZSBsYWNrIG9mIG5vcm1hdGl2ZSByZWZlcmVu Y2VzIHRvIHRoZSBkb2N1bWVudHMgdGhhdCBkZWZpbmUgdGhlIGZpZWxkcyB0aGlzDQo+IGRvY3Vt ZW50IHJlZ2lzdGVycyBpbnRvIElBTkEgaXMgaW1wb3J0YW50IGVub3VnaCB0byB3YXJyYW50IHNv bWUgZGlzY3Vzc2lvbi4NCk5vdCBzdXJlIHdoZXRoZXIgeW91IGFyZSBhc2tpbmcgZm9yIE5vcm1h dGl2ZSByZWZlcmVuY2VzIGluIDQuMSBvciBpbg0KNC4yIHRvIDQuNiwgb3IgYm90aC4NCkknbSBu b3Qgc3VyZSBOb3JtYXRpdmUgcmVmZXJlbmNlcyB3b3VsZCBiZSBhcHByb3ByaWF0ZSBmb3IgdGhl IG1ldGFkYXRhDQpvYmplY3RzIChmcm9tIDQuMiB0byA0LjYpIHRoaXMgZG9jdW1lbnQgZGVmaW5l cy4gQWxsIG9mIHRoZW0gYXJlIG9wYXF1ZSwNCmFuZCB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUg b3BlcmF0b3IuIEluZm9ybWF0aXZlIHJlZmVyZW5jZXMgKGxpa2UgaW4NCjQuNikgd291bGQgYmUg YSBwbHVzIHRob3VnaC4NCkknbSBzdXJlIHRoZSBhdXRob3JzIGNhbiBhZGQgTm9ybWF0aXZlIHJl ZmVyZW5jZXMgdG8gNC4xIHRvby4NCg0KDQo+IFNlY29uZCAtIEknZCBsaWtlIHNvbWUgY2xhcmlm aWNhdGlvbiBhYm91dCBpbnRlcm9wZXJhYmlsaXR5LiBNb3JlIGRldGFpbHMgYmVsb3cuDQpJdCB3 b3VsZCBiZSBncmVhdCBpZiB5b3UgY291bGQgZWxhYm9yYXRlIGEgYml0IG9uIHRoZSBpbnRlcm9w ZXJhYmlsaXR5DQppc3N1ZXMgeW91IGZvcmVzZWUuIFBlcnNvbmFsbHksIEkgY2FuIGVudmlzYWdl IG1pc2NvbmZpZ3VyYXRpb24gZHJpdmVuDQpwcm9ibGVtcywgYnV0IG5vdCBpbnRlcm9wIG9uZXMu DQoNCj4NCj4gRnJhbmNlc2NhDQo+DQo+IDEuIC0tLS0tDQo+DQo+ICAgICAgICBUZW5hbnQgSUQ6 IFJlcHJlc2VudHMgYW4gb3BhcXVlIHZhbHVlIHBvaW50aW5nIHRvIE9yY2hlc3RyYXRpb24NCj4g ICAgICAgIHN5c3RlbS1nZW5lcmF0ZWQgdGVuYW50IGlkZW50aWZpZXIuICBUaGUgc3RydWN0dXJl IGFuZCBzZW1hbnRpY3MNCj4gICAgICAgIG9mIHRoaXMgZmllbGQgYXJlIGRlcGxveW1lbnQgc3Bl Y2lmaWMuDQo+DQo+IEZQOiBJIGFtIHdvcnJpZWQgYWJvdXQgaW50ZXJvcGVyYWJpbGl0eSwgYXMg dGhlIGZpZWxkIGlzIGRlZmluZWQgYXMgZGVwbG95bWVudA0KPiBzcGVjaWZpYy4gQ291bGQgeW91 IGNsYXJpZnkgd2h5IHlvdSBkb24ndCB0aGluayB0aGlzIGlzIGFuIGlzc3VlPyBBbHNvLCBwbGVh c2UNCj4gYWRkIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0aGUgc2VjdGlvbiBhbmQgZG9jdW1l bnQgZGVmaW5pbmcgdGVuYW50DQo+IGlkZW50aWZpY2F0aW9uLg0KPg0KPiAyLiAtLS0tDQo+DQo+ IFNlY3Rpb24gNC4zDQo+DQo+IEZQOiBTYW1lIGNvbW1lbnQgYXMgYWJvdmUgZm9yIE5vZGUgSUQ6 IHBsZWFzZSBhZGQgYSByZWZlcmVuY2UgYW5kIGV4cGxhaW4NCj4gaW50ZXJvcGVyYWJpbGl0eSwg YXMgdGhpcyBpcyBkZWZpbmVkIGFzIGRlcGxveW1lbnQgc3BlY2lmaWMuDQo+DQo+IDMuIC0tLS0t DQo+DQo+IFNlY3Rpb25zIDQuNCwgNC41DQo+DQo+IEZQOiBJIGRvIHRoaW5rIHRoZXNlIGZpZWxk cyBuZWVkIHJlZmVyZW5jZXMgdG8gdGhlIGRvY3VtZW50cyB0aGV5IGFyZSBkZWZpbmVkDQo+IGlu LiAoSSBhbSBhd2FyZSBzZWN0aW9uIDIuMSBhbmQgdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHNo b3VsZCBoZWxwLCBidXQgSQ0KPiB0aGluayBpdCB3b3VsZCBiZSBtdWNoIGNsZWFyZXIgdG8gaGF2 ZSBkaXJlY3QgbGlua3MgdG8gdGhlIHJpZ2h0IHBsYWNlIGluIHRoZQ0KPiB0ZXh0LikgRm9yIEZs b3cgSUQsIGlmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBp dCBoaWdoDQo+IGxldmVsIGFuZCBnaXZlcyBleGFtcGxlcyBvZiB3aGF0IHZhbHVlIGl0IGNhbiB0 YWtlLiBJIHdvdWxkIGNsYXJpZnkgdGhhdCBpbiB0aGUNCj4gZmlyc3QgcGFyYWdyYXBoIG9mIHRo ZSBzZWN0aW9uIChhcyB5b3UgZG8gZm9yIFNlY3Rpb24gNC42KSwgaW5zdGVhZCBvZiBoYXZpbmcN Cj4gdGhlIHJlZmVyZW5jZXMgb25seSBpbiB0aGUgIkxlbmd0aCIgcGFyYWdyYXBoLg0KPg0KPg0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gNC4gLS0t LS0NCj4NCj4gU2VjdGlvbiA0LjENCj4NCj4gRlA6IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVy IHRvIGhhdmUgdGhlIHNlbnRlbmNlICJSZXNlcnZlZCBiaXRzIE1VU1QgYmUgc2VudA0KPiBhcyB6 ZXJvIGFuZCBpZ25vcmVkIG9uIHJlY2VpcHQuIiBvbmx5IG9uY2UsIHJhdGhlciB0aGFuIHJlcGVh dCBmb3IgZWFjaA0KPiBjb250ZXh0LiBXaGF0IGlzIG1pc3NpbmcgaW5zdGVhZCBpcyB0aGUgbnVt YmVyIG9mIGJpdHMgdGhhdCBhcmUgcmVzZXJ2ZWQgZm9yDQo+IGVhY2ggQ1QuIEkga25vdyB0aGF0 IGl0IGNhbiBiZSBleHRyYWN0ZWQgZnJvbSB0aGUgZmlndXJlIG9yIGZyb20gdGhlIHZhbHVlIG9m DQo+IHRoZSBGb3J3YXJkaW5nIENvbnRleHQgZmllbGQsIGJ1dCBJIGJlbGlldmUgZmlndXJlcyBz aG91bGQgYmUgY29tcGxlbWVudGVkIGJ5DQo+IGNsZWFyIHdyaXR0ZW4gdGV4dC4gQWRkaXRpb25h bGx5LCB0byBpbXByb3ZlIHJlYWRhYmlsaXR5LCByZWZlcmVuY2VzIHNob3VsZCBiZQ0KPiBhZGRl ZCBmb3IgdGhlIGZvcndhcmRpbmcgY29udGV4dCB3aGVyZSB0aGV5IGFyZSBtaXNzaW5nOiBWTEFO IGlkZW50aWZpZXIsIE1QTFMNCj4gVlBOIGxhYmVs4oCaIFZOSS4NCj4NCj4NCj4NCj4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5n IGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCg== --_000_HE1PR07MB42178E476E313EC8FA66E20098309HE1PR07MB4217eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9z ZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJQaW5nRmFuZyBUQyI7DQoJcGFub3NlLTE6MiAx MSA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBQaW5nRmFu ZyBUQyI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t R0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29y ZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBZdWVodWEsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRo YW5rcyBmb3IgeW91ciB1cGRhdGUhIEl0IGFkZHJlc3NlcyBhbG1vc3QgYWxsIG15IGNvbW1lbnRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5JIHN0aWxsIGhhdmUgdGhlIHNhbWUgcHJvYmxlbSB3aXRoIHRoZSBmb2xsb3dpbmcg dW5jaGFuZ2VkIHRleHQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRlbmFudCBJRDogUmVwcmVzZW50cyBhbiBvcGFxdWUgdmFs dWUgcG9pbnRpbmcgdG8gT3JjaGVzdHJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBzeXN0ZW0tZ2VuZXJhdGVkIHRlbmFudCBpZGVudGlmaWVyLiZuYnNwOyBUaGUgc3RydWN0dXJl IGFuZCBzZW1hbnRpY3M8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2YgdGhpcyBmaWVs ZCBhcmUgZGVwbG95bWVudCBzcGVjaWZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgcXVlc3Rpb24gYmVpbmcgaG93 IGNhbiB0aGlzIGZpZWxkIGJlIGludGVyb3BlcmFibGUgaWYgdGhlIHN0cnVjdHVyZSBhbmQgc2Vt YW50aWNzIGlzIGRlcGxveW1lbnQgc3BlY2lmaWMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyB3YXMgZGlzY3Vzc2Vk IGR1cmluZyB0aGUgdGVsZWNoYXQgKG1pbnV0ZXMgaGVyZToNCjxhIGhyZWY9Imh0dHBzOi8vd3d3 Ni5pZXRmLm9yZy9pZXNnL21pbnV0ZXMvMjAyMS9uYXJyYXRpdmUtbWludXRlcy0yMDIxLTEyLTAy LnR4dCI+DQpodHRwczovL3d3dzYuaWV0Zi5vcmcvaWVzZy9taW51dGVzLzIwMjEvbmFycmF0aXZl LW1pbnV0ZXMtMjAyMS0xMi0wMi50eHQ8L2E+ICksIGFuZCBCZW4gd2FzIGdyZWF0IGF0IHB1dHRp bmcgaW50byB3b3JkcyBteSBjb25jZXJuOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPkJlbjogSWYgaXQncyBnb2luZyB0byBiZSB0aGUgYnl0ZSBzdHJpbmcgdGhh dCBpcyBqdXN0IGNvbmZpZ3VyZWQgZXZlcnl3aGVyZSBhbmQgeW91IGp1c3QgY2hlY2sgaWYgaXQg bWF0Y2hlcyBvciBkb2Vzbid0IG1hdGNoLCB0aGF0J3MgcHJldHR5IHN0cmFpZ2h0Zm9yd2FyZCBh bmQgdGhhdCBpcw0KIHByb2JhYmx5IGdvaW5nIHRvIGJlIGludGVyb3BlcmFibGUuIEkgdGhpbmsg eW91IGNhbiBnZXQgc29tZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBpZiBpdCdzIGEgdmFsdWUg dGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBjb25maWd1cmVkIGFzIG9wYXF1ZSB0byB0aGUgTlNIIGlt cGxlbWVudGF0aW9uIGJ1dCB0aGVuIGl0IGhhcyB0byBiZSBwcm9jZXNzZWQgaW4gc29tZSB3YXkg YnkgdGhlIHJlY2lwaWVudHMsIGFzIHRoZSBzb2Z0d2FyZSBpbXBsZW1lbnRhdGlvbg0KIG9uIHRo ZSByZWNpcGllbnQgaXMgb25seSBnb2luZyB0byBpbXBsZW1lbnQgc3VwcG9ydCBmb3Igc29tZSBm aXhlZCBzZXQgb2YgZm9ybWF0cy4gSWYgdGhhdCBpbXBsZW1lbnRhdGlvbiBwaWNrcyBvbmUgc2V0 IG9mIGZvcm1hdHMgYW5kIGFub3RoZXIgaW1wbGVtZW50YXRpb24gcGlja3MgYSBkaWZmZXJlbnQg c2V0IG9mIGZvcm1hdHMsIHRoZXJlIG1heSBub3QgYmUgYW55IG92ZXJsYXAgc28geW91IG1heSBu b3QgYmUgYWJsZSB0byBhY3R1YWxseQ0KIGludGVyb3BlcmF0ZSBpbiB0ZXJtcyBvZiB0aGUgY29u dGVudHMgb2YgdGhhdCBmaWVsZC4gVGhhdCdzIGEgbGl0dGxlIGZhciByZW1vdmVkIGZyb20gdGhl IE5TSCBwcm90b2NvbCBpdHNlbGYgYnV0IHRoZXJlIGlzIHBlcmhhcHMgc3RpbGwgc29tZSBpbnRl cm9wZXJhYmlsaXR5IGNvbmNlcm4gdG8gYmUgd29ycmllZCBhYm91dCB0aGVyZSwgZGVwZW5kaW5n IG9uIGhvdyB0aGlzIHZhbHVlIGlzIGV4cGVjdGVkIHRvIGJlIHByb2Nlc3NlZCBieSB0aGUNCiBy ZWNpcGllbnQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHdhcyBob3Bpbmcg c29tZSB0ZXh0IGNvdWxkIGJlIGFkZGVkIGFib3V0IGNvbmZpZ3VyYXRpb24sIGFuZCB3aHkgdGhp cyBzaG91bGQgbm90IGJlIGEgcHJvYmxlbSBpbiB0aGUgdXNlIGNhc2VzIG9mIHRoaXMgZG9jdW1l bnQuIEJhc2ljYWxseSBzb21lIG1vcmUgZGV0YWlscyBhYm91dCB3aGF0IE1hcnRpbiBzYXlzOiA8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgcG9pbnQgaXMgcmVhbGx5IHRoYXQg Ym90aCB0aGUgY2xhc3NpZmllciB0aGF0IHdlIGluc2VydCB0byB0aGF0IG1ldGFkYXRhIGFuZCBw b3NzaWJseSBzb21lIHZpcnR1YWwgbmV0d29yayBmdW5jdGlvbiB0aGF0IHdpbGwgcHJvY2VzcyBp dCwgYmUgY29uZmlndXJlZCB0aGUgc2FtZS4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBpbiBteSBv cGluaW9uIGlzIG5vdCBjbGVhciBlbm91Z2ggaW4gdGhlIGRvY3VtZW50IGFzIGlzLiBJdCBjb3Vs ZCBiZSBjbGFyaWZpZWQgaXRoZXIgaW4gdGhlIOKAnFRlbmFudCBJROKAnSBkZWZpbml0aW9uIG9y IGluIGEgc2VwYXJhdGUgcGFyYWdyYXBoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5J4oCZbGwgdXBkYXRlIHRoZSBESVNDVVNT IHRvIHJlZmxlY3QgdGhpcyBjb21tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhh bmsgeW91LDxicj4NCkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0 OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNi4wcHQiPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPndlaS55dWVodWFAenRlLmNv bS5jbiAmbHQ7d2VpLnl1ZWh1YUB6dGUuY29tLmNuJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRu ZXNkYXksIDI2IEphbnVhcnkgMjAyMiBhdCAwMzoxNTxicj4NCjxiPlRvOiA8L2I+bWFydGluLnZp Z291cmV1eEBub2tpYS5jb20gJmx0O21hcnRpbi52aWdvdXJldXhAbm9raWEuY29tJmd0OywgRnJh bmNlc2NhIFBhbG9tYmluaSAmbHQ7ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20mZ3Q7 PGJyPg0KPGI+Q2M6IDwvYj5pZXNnQGlldGYub3JnICZsdDtpZXNnQGlldGYub3JnJmd0OywgZHJh ZnQtaWV0Zi1zZmMtbnNoLXRsdkBpZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdkBp ZXRmLm9yZyZndDssIHNmYy1jaGFpcnNAaWV0Zi5vcmcgJmx0O3NmYy1jaGFpcnNAaWV0Zi5vcmcm Z3Q7LCBzZmNAaWV0Zi5vcmcgJmx0O3NmY0BpZXRmLm9yZyZndDssIGdyZWdpbWlyc2t5QGdtYWls LmNvbSAmbHQ7Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5S ZTpbc2ZjXSBGcmFuY2VzY2EgUGFsb21iaW5pJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNmYy1u c2gtdGx2LTA5OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPkRlYXIgTWFydGluIGFuZCBGcmFuY2VzY2EsPGJyPg0KQ29tYmluZSB3aXRoIHlv dXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLCBJIHVwbG9hZGVkIGEgdmVyMTIgdG8gcmVmbGVj dGVkIHRoZSB1cGRhdGVzLjxicj4NCkkgYXBwcmVjaWF0ZSB5b3VyIGZ1cnRoZXIgcmV2aWV3Ljxi cj4NClRoZSBsaW5rIG9mIGRpZmZlcmVuY2VzIGlzIDogPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2ZjLW5zaC10bHYtMTIudHh0Ij5o dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi0x Mi50eHQ8L2E+PGJyPg0KPGJyPg0KPGJyPg0KQmVzdCBSZWdhcmRzLDxicj4NCll1ZWh1YSBXZWk8 YnI+DQpNOiArODYgMTM4NTE0NjAyNjkgRTogd2VpLnl1ZWh1YUB6dGUuY29tLmNuPGJyPg0KLS0t LS0tLS0tLS0tLS0tLS0tPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZx dW90OyI+5Y6f5aeLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtQaW5nRmFu ZyBUQyZxdW90OyxzYW5zLXNlcmlmIj7pgq48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5Lu2PC9zcGFuPi0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtQaW5nRmFuZyBUQyZxdW90OyxzYW5zLXNl cmlmIj7lj5E8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZx dW90OyI+5Lu25Lq677yaPC9zcGFuPk1hcnRpblZpZ291cmV1eDxicj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaUtuS7tuS6uu+8mjwvc3Bhbj5GcmFu Y2VzY2EgUGFsb21iaW5pO1RoZSBJRVNHOzxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaKhOmAgeS6uu+8mjwvc3Bhbj5kcmFmdC1pZXRmLXNmYy1u c2gtdGx2QGlldGYub3JnO3NmYy1jaGFpcnNAaWV0Zi5vcmc7c2ZjQGlldGYub3JnO2dyZWdpbWly c2t5QGdtYWlsLmNvbTs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290 aGljJnF1b3Q7Ij7ml6U8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBH b3RoaWMmcXVvdDsiPg0K5pyfPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 TVMgR290aGljJnF1b3Q7Ij7vvJo8L3NwYW4+MjAyMTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuW5tDwvc3Bhbj4xMjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bhbj4wMjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaXpTwvc3Bhbj4gMjA6MzE8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7kuLs8L3NwYW4+IDxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtQaW5nRmFuZyBUQyZxdW90OyxzYW5zLXNlcmlmIj4N CumimDwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90 OyI+77yaPC9zcGFuPlJlOiBbc2ZjXSBGcmFuY2VzY2EgUGFsb21iaW5pJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLXNmYy1uc2gtdGx2LTA5OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxicj4N CkhlbGxvIEZyYW5jZXNjYSw8YnI+DQo8YnI+DQp0aGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3LiBQ bGVhc2Ugc2VlIGlubGluZS48YnI+DQo8YnI+DQpJIGludml0ZSB0aGUgYXV0aG9ycyB0byBzaGFy ZSB0aGVpciB2aWV3cy48YnI+DQo8YnI+DQotbTxicj4NCjxicj4NCkxlIDIwMjEtMTEtMjkgw6Ag MTE6NTksIEZyYW5jZXNjYSBQYWxvbWJpbmkgdmlhIERhdGF0cmFja2VyIGEgw6ljcml0IDo8YnI+ DQomZ3Q7IEZyYW5jZXNjYSBQYWxvbWJpbmkgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxs b3QgcG9zaXRpb24gZm9yPGJyPg0KJmd0OyBkcmFmdC1pZXRmLXNmYy1uc2gtdGx2LTA5OiBEaXNj dXNzPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUg c3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJyPg0KJmd0OyBlbWFpbCBhZGRy ZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQg dGhpczxicj4NCiZndDsgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9ibG9nL2hhbmRsaW5nLWllc2ctYmFsbG90LXBvc2l0aW9ucy8iPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvYmxvZy9oYW5kbGluZy1pZXNnLWJhbGxvdC1wb3NpdGlvbnMvPC9hPjxi cj4NCiZndDsgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgaG93IHRvIGhhbmRsZSBESVNDVVNT IGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZCBoZXJlOjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC10bHYvPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgRElTQ1VTUzo8YnI+DQomZ3Q7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFuayB5b3UgZm9yIHRoZSB3b3Jr IG9uIHRoaXMgZG9jdW1lbnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBoYXZlIHNvbWUgY29tbWVu dHMsIG1vc3RseSBoYXZpbmcgdG8gZG8gd2l0aCBjbGFyaWZpY2F0aW9ucyBhbmQgaW1wcm92ZW1l bnQ8YnI+DQomZ3Q7IG9mIHRleHQgZm9yIHJlYWRhYmlsaXR5LiBJJ2QgbGlrZSBhbnN3ZXJzIHRv IHR3byBtYWluIHBvaW50czogZmlyc3QgLSBJIGJlbGlldmU8YnI+DQomZ3Q7IHRoZSBsYWNrIG9m IG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIHRoZSBkb2N1bWVudHMgdGhhdCBkZWZpbmUgdGhlIGZp ZWxkcyB0aGlzPGJyPg0KJmd0OyBkb2N1bWVudCByZWdpc3RlcnMgaW50byBJQU5BIGlzIGltcG9y dGFudCBlbm91Z2ggdG8gd2FycmFudCBzb21lIGRpc2N1c3Npb24uPGJyPg0KTm90IHN1cmUgd2hl dGhlciB5b3UgYXJlIGFza2luZyBmb3IgTm9ybWF0aXZlIHJlZmVyZW5jZXMgaW4gNC4xIG9yIGlu PGJyPg0KNC4yIHRvIDQuNiwgb3IgYm90aC48YnI+DQpJJ20gbm90IHN1cmUgTm9ybWF0aXZlIHJl ZmVyZW5jZXMgd291bGQgYmUgYXBwcm9wcmlhdGUgZm9yIHRoZSBtZXRhZGF0YTxicj4NCm9iamVj dHMgKGZyb20gNC4yIHRvIDQuNikgdGhpcyBkb2N1bWVudCBkZWZpbmVzLiBBbGwgb2YgdGhlbSBh cmUgb3BhcXVlLDxicj4NCmFuZCB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgb3BlcmF0b3IuIElu Zm9ybWF0aXZlIHJlZmVyZW5jZXMgKGxpa2UgaW48YnI+DQo0LjYpIHdvdWxkIGJlIGEgcGx1cyB0 aG91Z2guPGJyPg0KSSdtIHN1cmUgdGhlIGF1dGhvcnMgY2FuIGFkZCBOb3JtYXRpdmUgcmVmZXJl bmNlcyB0byA0LjEgdG9vLjxicj4NCjxicj4NCjxicj4NCiZndDsgU2Vjb25kIC0gSSdkIGxpa2Ug c29tZSBjbGFyaWZpY2F0aW9uIGFib3V0IGludGVyb3BlcmFiaWxpdHkuIE1vcmUgZGV0YWlscyBi ZWxvdy48YnI+DQpJdCB3b3VsZCBiZSBncmVhdCBpZiB5b3UgY291bGQgZWxhYm9yYXRlIGEgYml0 IG9uIHRoZSBpbnRlcm9wZXJhYmlsaXR5PGJyPg0KaXNzdWVzIHlvdSBmb3Jlc2VlLiBQZXJzb25h bGx5LCBJIGNhbiBlbnZpc2FnZSBtaXNjb25maWd1cmF0aW9uIGRyaXZlbjxicj4NCnByb2JsZW1z LCBidXQgbm90IGludGVyb3Agb25lcy48YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBGcmFuY2Vz Y2E8YnI+DQomZ3Q7PGJyPg0KJmd0OyAxLiAtLS0tLTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRlbmFudCBJRDogUmVwcmVzZW50 cyBhbiBvcGFxdWUgdmFsdWUgcG9pbnRpbmcgdG8gT3JjaGVzdHJhdGlvbjxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3lzdGVtLWdlbmVyYXRlZCB0 ZW5hbnQgaWRlbnRpZmllci4mbmJzcDsgVGhlIHN0cnVjdHVyZSBhbmQgc2VtYW50aWNzPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiB0aGlzIGZp ZWxkIGFyZSBkZXBsb3ltZW50IHNwZWNpZmljLjxicj4NCiZndDs8YnI+DQomZ3Q7IEZQOiBJIGFt IHdvcnJpZWQgYWJvdXQgaW50ZXJvcGVyYWJpbGl0eSwgYXMgdGhlIGZpZWxkIGlzIGRlZmluZWQg YXMgZGVwbG95bWVudDxicj4NCiZndDsgc3BlY2lmaWMuIENvdWxkIHlvdSBjbGFyaWZ5IHdoeSB5 b3UgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhbiBpc3N1ZT8gQWxzbywgcGxlYXNlPGJyPg0KJmd0OyBh ZGQgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRoZSBzZWN0aW9uIGFuZCBkb2N1bWVudCBkZWZp bmluZyB0ZW5hbnQ8YnI+DQomZ3Q7IGlkZW50aWZpY2F0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7 IDIuIC0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0OyBTZWN0aW9uIDQuMzxicj4NCiZndDs8YnI+DQom Z3Q7IEZQOiBTYW1lIGNvbW1lbnQgYXMgYWJvdmUgZm9yIE5vZGUgSUQ6IHBsZWFzZSBhZGQgYSBy ZWZlcmVuY2UgYW5kIGV4cGxhaW48YnI+DQomZ3Q7IGludGVyb3BlcmFiaWxpdHksIGFzIHRoaXMg aXMgZGVmaW5lZCBhcyBkZXBsb3ltZW50IHNwZWNpZmljLjxicj4NCiZndDs8YnI+DQomZ3Q7IDMu IC0tLS0tPGJyPg0KJmd0Ozxicj4NCiZndDsgU2VjdGlvbnMgNC40LCA0LjU8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBGUDogSSBkbyB0aGluayB0aGVzZSBmaWVsZHMgbmVlZCByZWZlcmVuY2VzIHRvIHRo ZSBkb2N1bWVudHMgdGhleSBhcmUgZGVmaW5lZDxicj4NCiZndDsgaW4uIChJIGFtIGF3YXJlIHNl Y3Rpb24gMi4xIGFuZCB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgc2hvdWxkIGhlbHAsIGJ1dCBJ PGJyPg0KJmd0OyB0aGluayBpdCB3b3VsZCBiZSBtdWNoIGNsZWFyZXIgdG8gaGF2ZSBkaXJlY3Qg bGlua3MgdG8gdGhlIHJpZ2h0IHBsYWNlIGluIHRoZTxicj4NCiZndDsgdGV4dC4pIEZvciBGbG93 IElELCBpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0aGlzIGRvY3VtZW50IGRlZmluZXMgaXQg aGlnaDxicj4NCiZndDsgbGV2ZWwgYW5kIGdpdmVzIGV4YW1wbGVzIG9mIHdoYXQgdmFsdWUgaXQg Y2FuIHRha2UuIEkgd291bGQgY2xhcmlmeSB0aGF0IGluIHRoZTxicj4NCiZndDsgZmlyc3QgcGFy YWdyYXBoIG9mIHRoZSBzZWN0aW9uIChhcyB5b3UgZG8gZm9yIFNlY3Rpb24gNC42KSwgaW5zdGVh ZCBvZiBoYXZpbmc8YnI+DQomZ3Q7IHRoZSByZWZlcmVuY2VzIG9ubHkgaW4gdGhlICZxdW90O0xl bmd0aCZxdW90OyBwYXJhZ3JhcGguPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQomZ3Q7IENPTU1FTlQ6PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K Jmd0Ozxicj4NCiZndDsgNC4gLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0OyBTZWN0aW9uIDQuMTxi cj4NCiZndDs8YnI+DQomZ3Q7IEZQOiBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBoYXZl IHRoZSBzZW50ZW5jZSAmcXVvdDtSZXNlcnZlZCBiaXRzIE1VU1QgYmUgc2VudDxicj4NCiZndDsg YXMgemVybyBhbmQgaWdub3JlZCBvbiByZWNlaXB0LiZxdW90OyBvbmx5IG9uY2UsIHJhdGhlciB0 aGFuIHJlcGVhdCBmb3IgZWFjaDxicj4NCiZndDsgY29udGV4dC4gV2hhdCBpcyBtaXNzaW5nIGlu c3RlYWQgaXMgdGhlIG51bWJlciBvZiBiaXRzIHRoYXQgYXJlIHJlc2VydmVkIGZvcjxicj4NCiZn dDsgZWFjaCBDVC4gSSBrbm93IHRoYXQgaXQgY2FuIGJlIGV4dHJhY3RlZCBmcm9tIHRoZSBmaWd1 cmUgb3IgZnJvbSB0aGUgdmFsdWUgb2Y8YnI+DQomZ3Q7IHRoZSBGb3J3YXJkaW5nIENvbnRleHQg ZmllbGQsIGJ1dCBJIGJlbGlldmUgZmlndXJlcyBzaG91bGQgYmUgY29tcGxlbWVudGVkIGJ5PGJy Pg0KJmd0OyBjbGVhciB3cml0dGVuIHRleHQuIEFkZGl0aW9uYWxseSwgdG8gaW1wcm92ZSByZWFk YWJpbGl0eSwgcmVmZXJlbmNlcyBzaG91bGQgYmU8YnI+DQomZ3Q7IGFkZGVkIGZvciB0aGUgZm9y d2FyZGluZyBjb250ZXh0IHdoZXJlIHRoZXkgYXJlIG1pc3Npbmc6IFZMQU4gaWRlbnRpZmllciwg TVBMUzxicj4NCiZndDsgVlBOIGxhYmVs4oCaIFZOSS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBsaXN0PGJyPg0Kc2ZjQGlldGYub3Jn PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_HE1PR07MB42178E476E313EC8FA66E20098309HE1PR07MB4217eurp_-- From nobody Sat Feb 12 23:52:45 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83AD3A077F; Sat, 12 Feb 2022 23:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQqGCrMI8RWs; Sat, 12 Feb 2022 23:52:37 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9833A0780; Sat, 12 Feb 2022 23:52:36 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id v5-20020a17090a4ec500b001b8b702df57so15996471pjl.2; Sat, 12 Feb 2022 23:52:36 -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=EZGlFgRKys3G+j7iebh+1ItFBlL7UdUSgzmH85brnVU=; b=pq/qqNJZtll+2sd7xomTcTDB+KzT/kKWtlJCYtMVigL6RiCyT0VmxrdXmuqcWR2CBw 0YPabfOzLrvH8Q/pBHNIJ4yVTUrhZoW4me+nndMvbftzp+pz09SWOQtD0lBRThhLskAX 0V7vk+Nn08GiyB5f0Y2W3af1oIA/vPrVW6F2BHpzECwf5piZGcA67SbJhlDyk8QE/Y0Z aXtMUNRnIETlMADpEhBOG8b5KlGh9fMnNq/OCJh6K0HzOHfDVaO7e9r1UIJAHBjR0MOP syVj4Jot4zU2gqKC6f2zJcshQozpvj7MCcHcUgbfIFOWQI+NSapFNFe0RGRzzWIUMemX 5VWQ== 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=EZGlFgRKys3G+j7iebh+1ItFBlL7UdUSgzmH85brnVU=; b=jrR0UUs5lN6LO9FGLtquIDZdcgI91NJsN+sExvpdJiNvkus+HWMKTx0krMWw1xSxK4 KYlZot9+ARAp973sp4AYmPNIwUXJX5BCIRDY16ewFxn8esqFl+v+iPQ94H+bRPQ7orYf g1CVa3pNS57JfBz98s0FH/QnLGr6uJOkKgBfm0zP94HVBpY5L7CByQ6TL+IDL24pu3lS s3+t5LOcNVrSjPUID2efnb0v8jzN7nBt/X/KpYfpC2dTMwUq7AaBk+/2JvbngPn/a9uK Y2i0Rfeaiza/UX9kTbjQwhOYBDFb2y4HJYHBM4P6urjBzC2YXuPREFB9pb8iirwiHpfU +b7w== X-Gm-Message-State: AOAM533S3wHM0dku6FFbx8Q1nnzbgfzB+44bwPEvSKq9XLoqxyS1/64a XC/xhDQ3b/P9gWvP8RtNuMoB7E+JuunmgCmzdXYfKAJ+ X-Google-Smtp-Source: ABdhPJziRMpiuRWoKCu4Yq0FhBx4yeMDZsfxPYU1OhXR2XnDNDSOJ6/zhmw3ZBBcAMplE3tz1+tGWZ6QmuN0uKBmt9I= X-Received: by 2002:a17:902:b684:: with SMTP id c4mr8630579pls.100.1644738753694; Sat, 12 Feb 2022 23:52:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sun, 13 Feb 2022 02:52:22 -0500 Message-ID: To: Greg Mirsky Cc: James Guichard , "sfc-chairs@ietf.org" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000029903605d7e1959e" Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2022 07:52:43 -0000 --00000000000029903605d7e1959e Content-Type: text/plain; charset="UTF-8" Hi Jim, Joel & SFC WG, I agree that the RFC 8300 definition of O bit is incomplete and not clear as to its intended use. That is a problem that I agree needs to be rectified. I understand that we need to get this resolved before we can progress Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM. I agree that what makes sense to me as a path forward is to deprecate the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC Multilayer OAM and SFC IOAM are identified by the respective values for the NSH Next Protocol field (to be assigned by IANA), as well as so far no OAM-specific meta data TLV has been yet defined. So we have I believe solid solution and path forward and I support deprecating the O bit. Kind Regards Gyan On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky wrote: > Thank you, Jim and Joel, for guiding the SFC OAM work and pointing out the > issue that must be addressed. > > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I > understand these documents, the Active SFC OAM and IOAM are identified by > the respective values for the NSH Next Protocol field (to be assigned by > IANA). At the same time, so far no OAM-specific meta data TLV has been > defined. Thus, it appears that one way forward could be to not involve the > O bit in the active SFC OAM or IOAM altogether. In other words, to > deprecate the NSH O bit. > > I greatly appreciate your comments on the proposal to deprecate the NSH O > bit. > > Regards, > Greg > > On Wed, Feb 2, 2022 at 10:36 AM James Guichard < > james.n.guichard@futurewei.com> wrote: > >> Hi WG: >> >> >> >> Having reviewed all of the OAM related documents in our WG, the chairs >> would like to provide a few comments to hopefully generate discussion and >> forward progress of this work: >> >> >> >> 1) The chairs have reviewed the O bit definition in RFC 8300. That >> definition is at best open to interpretation and therefore incomplete. For >> example, the clear intention is only to mark packets which are intended for >> SFC OAM at the SFC service layer. But that is not what the current text >> says. There is also, unfortunately, ambiguity as to what constitutes an >> OAM packet. So it is reasonable for documents to update 8300 to clarify >> the exact applicability and action for the O-bit. >> >> >> >> 2) However, related to point 1), we can't have multiple documents >> updating the definition differently. As such, the authors of the SFC iOAM >> draft and the SFC multi-layer-oam draft need to come together and figure >> out what the clarification is for the definition of that bit. We do not >> believe as chairs that either of these documents can move forward from the >> WG until such clarity has been reached. >> >> >> >> 3) Related to the SFC iOAM, we need a clear definition of iOAM. There >> seem to be differences between the definitions in published RFCs, the usage >> (which is not a definition) in the SFC draft, and the various ippm drafts. >> Any such definition will need to be vetted with the ippm working group. >> >> >> >> Again, it would be good if members of the working group beyond the two >> author teams spoke up about their readings of the documents, and their >> understandings of what we need. >> >> >> >> Yours, >> >> Jim and Joel >> >> >> >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000029903605d7e1959e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Jim, Joel & SFC WG,

I agree that the RFC 8300 = definition of O bit is incomplete and not clear as to its intended use. =C2= =A0

That is a problem th= at I agree needs to be rectified.

I understand that we need to get this resolved before we can prog= ress Multilayer SFC OAM=C2=A0draft-ietf-sfc-multi-layer-oam-18=C2=A0and SFC IOAM. =C2=A0

I agree that what makes sense t= o me as a path forward is to deprecate the O bit and not use in SFC Multila= yer OAM and SFC IOAM, as both SFC Multilayer=C2=A0OAM and SFC=C2=A0IOAM are identified by the respective values for the NSH Next Protocol= field (to be assigned by IANA), as well as so far no OAM-specific meta dat= a TLV has been yet defined.

So we have I believe solid solution and path forward and I support depr= ecating the O bit.

Kind = Regards=C2=A0

Gyan
=

O= n Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
=
Thank you, Jim and Joel, for guiding the SFC OAM work and = pointing out the issue that must be addressed.

I've = reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I understand = these documents, the Active SFC OAM and IOAM are identified by the respecti= ve values for the NSH Next Protocol field (to be assigned by IANA). At the = same time, so far no OAM-specific meta data TLV has been defined. Thus, it = appears that one way forward could be to not involve the O bit in the activ= e SFC OAM or IOAM altogether. In other words, to deprecate the NSH O bit.

I greatly appreciate your comments on the proposal = to deprecate the NSH O bit.

Regards,
Gre= g

On Wed, Feb 2, 2022 at 10:36 AM James Guichard <james.n.guichard@futurew= ei.com> wrote:

Hi WG:

=C2=A0

Having reviewed all of the OAM related documents in = our WG, the chairs would like to provide a few comments to hopefully genera= te discussion and forward progress of this work:

=C2=A0

1) The chairs have reviewed the O bit definition in = RFC 8300.=C2=A0 That definition is at best open to interpretation and there= fore incomplete.=C2=A0 For example, the clear intention is only to mark pac= kets which are intended for SFC OAM at the SFC service layer.=C2=A0 But that is not what the current text says.=C2=A0 The= re is also, unfortunately, ambiguity as to what constitutes an OAM packet.= =C2=A0 So it is reasonable for documents to update 8300 to clarify the exac= t applicability and action for the O-bit.

=C2=A0

2) However, related to point 1), we can't have m= ultiple documents updating the definition differently.=C2=A0 As such, the a= uthors of the SFC iOAM draft and the SFC multi-layer-oam draft need to come= together and figure out what the clarification is for the definition of that bit. We do not believe as chairs that either= of these documents can move forward from the WG until such clarity has bee= n reached.

=C2=A0

3) Related to the SFC iOAM, we need a clear definiti= on of iOAM.=C2=A0 There seem to be differences between the definitions in p= ublished RFCs, the usage (which is not a definition) in the SFC draft, and = the various ippm drafts.=C2=A0 Any such definition will need to be vetted with the ippm working group.

=C2=A0

Again, it would be good if members of the working gr= oup beyond the two author teams spoke up about their readings of the docume= nts, and their understandings of what we need.

=C2=A0

Yours,

Jim and Joel

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--
--00000000000029903605d7e1959e-- From nobody Sun Feb 13 06:56:01 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1DC3A1383 for ; Sun, 13 Feb 2022 06:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNYCuRpUZmF8 for ; Sun, 13 Feb 2022 06:55:54 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B033A1382 for ; Sun, 13 Feb 2022 06:55:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4JxVlt2S6zz1pMJt; Sun, 13 Feb 2022 06:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1644764154; bh=pgwWhU/fyuc/FXztrgzqMYN2DPS+wIPbclTqaUt3vsI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NSVYDzA/WYbLdVU1tM8byyUWFUYdUOQQMGqVnGCQk0kU7h6hobxiiKQKPbRUyHnFW jaDbq7IuljlbZGeGjl4t0D1EG1RmF1mw3TF2nSWxXZ3QkKtLjeJreybAeL59G3yt6H fY83jVcvJjgDvpTLHF5+R82lkZF/5BqgfxYvpzvI= X-Quarantine-ID: <6W9Fe_lrLCmS> X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4JxVls4H0mz1nsGP; Sun, 13 Feb 2022 06:55:53 -0800 (PST) Message-ID: Date: Sun, 13 Feb 2022 09:55:53 -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 To: Gyan Mishra , Greg Mirsky Cc: "sfc@ietf.org" References: From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2022 14:56:00 -0000 There is an implication of deprecating the O-bit that I would like to hear from more WG participants about. As far as I can tell, if we deprecate the O-bit and rely on the next protocol field, we are saying that in practice (not by rule) NSH metadata can not be used for OAM. That's fine with me as long as we agree on that. Yours, Joel On 2/13/2022 2:52 AM, Gyan Mishra wrote: > > Hi Jim, Joel & SFC WG, > > I agree that the RFC 8300 definition of O bit is incomplete and not > clear as to its intended use. > > That is a problem that I agree needs to be rectified. > > I understand that we need to get this resolved before we can progress > Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM. > > I agree that what makes sense to me as a path forward is to deprecate > the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC > Multilayer OAM and SFC IOAM are identified by the respective values for > the NSH Next Protocol field (to be assigned by IANA), as well as so far > no OAM-specific meta data TLV has been yet defined. > > So we have I believe solid solution and path forward and I support > deprecating the O bit. > > Kind Regards > > Gyan > > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky > wrote: > > Thank you, Jim and Joel, for guiding the SFC OAM work and pointing > out the issue that must be addressed. > > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I > understand these documents, the Active SFC OAM and IOAM are > identified by the respective values for the NSH Next Protocol field > (to be assigned by IANA). At the same time, so far no OAM-specific > meta data TLV has been defined. Thus, it appears that one way > forward could be to not involve the O bit in the active SFC OAM or > IOAM altogether. In other words, to deprecate the NSH O bit. > > I greatly appreciate your comments on the proposal to deprecate the > NSH O bit. > > Regards, > Greg > > On Wed, Feb 2, 2022 at 10:36 AM James Guichard > > wrote: > > Hi WG:____ > > __ __ > > Having reviewed all of the OAM related documents in our WG, the > chairs would like to provide a few comments to hopefully > generate discussion and forward progress of this work:____ > > __ __ > > 1) The chairs have reviewed the O bit definition in RFC 8300. > That definition is at best open to interpretation and therefore > incomplete.  For example, the clear intention is only to mark > packets which are intended for SFC OAM at the SFC service > layer.  But that is not what the current text says.  There is > also, unfortunately, ambiguity as to what constitutes an OAM > packet.  So it is reasonable for documents to update 8300 to > clarify the exact applicability and action for the O-bit.____ > > __ __ > > 2) However, related to point 1), we can't have multiple > documents updating the definition differently.  As such, the > authors of the SFC iOAM draft and the SFC multi-layer-oam draft > need to come together and figure out what the clarification is > for the definition of that bit. We do not believe as chairs that > either of these documents can move forward from the WG until > such clarity has been reached. ____ > > __ __ > > 3) Related to the SFC iOAM, we need a clear definition of iOAM. > There seem to be differences between the definitions in > published RFCs, the usage (which is not a definition) in the SFC > draft, and the various ippm drafts.  Any such definition will > need to be vetted with the ippm working group.____ > > __ __ > > Again, it would be good if members of the working group beyond > the two author teams spoke up about their readings of the > documents, and their understandings of what we need.____ > > __ __ > > Yours,____ > > Jim and Joel____ > > __ __ > > __ __ > > __ __ > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > -- > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /Email gyan.s.mishra@verizon.com // > / > > /M 301 502-1347 > > / > > From nobody Sun Feb 13 09:04:51 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC503A0917 for ; Sun, 13 Feb 2022 09:04:20 -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 s9Ha8XBNfhr6 for ; Sun, 13 Feb 2022 09:04:15 -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 E89943A0847 for ; Sun, 13 Feb 2022 09:04:14 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id h18so1547040edb.7 for ; Sun, 13 Feb 2022 09:04:14 -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=jLlwcYpVkUNNPcfhMnqWuHnwezA6iLpt0+i02DBYHqg=; b=VOg3gEK7Q1lkRFMN73QXhm0j2L0bZ6D8AJhur5EB15QQSkML1Y3vzRVr6AkO+Miby+ /AakaseKv/iS/c3TTXcPWubsVwzfLPahl6ub5l36FTDzmkDQj/jYpnYEtTXeIgtIg3DD KJHF/l2wET6Rtg1dX4S+F1nHGx1C6VUq/2bhs+GLfm9U0qpAFHNA3C/zEaE+mM0Iu+1u m1MoLEncItOGsJdfxCW2zfmE2edl0jYisxXE0qfYDfTFddVo7vo6sNMX3oZ1ZWzIPDgg MXPs5g+flH5rZijgjCjXrg1fgipRp6nOF+Vr82xib/t57+xbKQQqbjgfyu43dtNF83PM gCkw== 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=jLlwcYpVkUNNPcfhMnqWuHnwezA6iLpt0+i02DBYHqg=; b=pniXiVF8NZn7Dra8pMgu4QE9RhnRaVtW80BBBJ4gGrA8lXJ1/pUf0lq7opH1qiEm7w yXSJkejVkRJ11x7Xe6iEKs+FCkZ3Ut5i2QOan2FkUwuH9RNZ1HpjGTWZ+gZlzs7pMn0j nHf4oui62162lLmqqVmRDHHfSF5RBazPWRCRXixoVq74yxhbiHSsV6aiX2xyyADdmMjq 2Hl0YKa2nzgYQi1mOgw4gwdS9wKh4V9J2SQ1iUjmGP8wfPRTutOf8Sq84MfCszA/45jx jLlstY26X1aqLqdA8t41Eoz6yYGz2qgwnpfFN6VsnprutPtXlGG3DBI9GobVIellurcE fR0w== X-Gm-Message-State: AOAM531V3jM/fuHEkT48/xG5jf74TavUWNDA6ZmPm3UreSkHHwFSrHZQ c73nc5h1zST2zjYsO/BFvNn+g71NcKmwvI6TbMe9jt/5 X-Google-Smtp-Source: ABdhPJwmbmNjpkCyz3CPSiMut8qzcsLJWGg9289ilNypTslCR01Ubv/HJMEcXyx1QIzwWO1p8b++jNldZ5tqj8OCAAs= X-Received: by 2002:a05:6402:2689:: with SMTP id w9mr11587932edd.68.1644771851553; Sun, 13 Feb 2022 09:04:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Sun, 13 Feb 2022 09:04:00 -0800 Message-ID: To: "Joel M. Halpern" Cc: Gyan Mishra , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f2cd7805d7e949d8" Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2022 17:04:22 -0000 --000000000000f2cd7805d7e949d8 Content-Type: text/plain; charset="UTF-8" Hi Joel, I agree that, as we find SFC NSH now, no OAM metadata has been defined. It appears to me that deprecating the O bit does not affect any of the already defined mechanisms in the SFC NSH. I think that if a new, for example, MD Type = 2 TLV that is used for any OAM functionality to be proposed in the future, deprecated the O bit would not prevent using such NSH TLV. What do you think? Regards, Greg On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern wrote: > There is an implication of deprecating the O-bit that I would like to > hear from more WG participants about. > > As far as I can tell, if we deprecate the O-bit and rely on the next > protocol field, we are saying that in practice (not by rule) NSH > metadata can not be used for OAM. That's fine with me as long as we > agree on that. > > Yours, > Joel > > On 2/13/2022 2:52 AM, Gyan Mishra wrote: > > > > Hi Jim, Joel & SFC WG, > > > > I agree that the RFC 8300 definition of O bit is incomplete and not > > clear as to its intended use. > > > > That is a problem that I agree needs to be rectified. > > > > I understand that we need to get this resolved before we can progress > > Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM. > > > > I agree that what makes sense to me as a path forward is to deprecate > > the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC > > Multilayer OAM and SFC IOAM are identified by the respective values for > > the NSH Next Protocol field (to be assigned by IANA), as well as so far > > no OAM-specific meta data TLV has been yet defined. > > > > So we have I believe solid solution and path forward and I support > > deprecating the O bit. > > > > Kind Regards > > > > Gyan > > > > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky > > wrote: > > > > Thank you, Jim and Joel, for guiding the SFC OAM work and pointing > > out the issue that must be addressed. > > > > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I > > understand these documents, the Active SFC OAM and IOAM are > > identified by the respective values for the NSH Next Protocol field > > (to be assigned by IANA). At the same time, so far no OAM-specific > > meta data TLV has been defined. Thus, it appears that one way > > forward could be to not involve the O bit in the active SFC OAM or > > IOAM altogether. In other words, to deprecate the NSH O bit. > > > > I greatly appreciate your comments on the proposal to deprecate the > > NSH O bit. > > > > Regards, > > Greg > > > > On Wed, Feb 2, 2022 at 10:36 AM James Guichard > > > > wrote: > > > > Hi WG:____ > > > > __ __ > > > > Having reviewed all of the OAM related documents in our WG, the > > chairs would like to provide a few comments to hopefully > > generate discussion and forward progress of this work:____ > > > > __ __ > > > > 1) The chairs have reviewed the O bit definition in RFC 8300. > > That definition is at best open to interpretation and therefore > > incomplete. For example, the clear intention is only to mark > > packets which are intended for SFC OAM at the SFC service > > layer. But that is not what the current text says. There is > > also, unfortunately, ambiguity as to what constitutes an OAM > > packet. So it is reasonable for documents to update 8300 to > > clarify the exact applicability and action for the O-bit.____ > > > > __ __ > > > > 2) However, related to point 1), we can't have multiple > > documents updating the definition differently. As such, the > > authors of the SFC iOAM draft and the SFC multi-layer-oam draft > > need to come together and figure out what the clarification is > > for the definition of that bit. We do not believe as chairs that > > either of these documents can move forward from the WG until > > such clarity has been reached. ____ > > > > __ __ > > > > 3) Related to the SFC iOAM, we need a clear definition of iOAM. > > There seem to be differences between the definitions in > > published RFCs, the usage (which is not a definition) in the SFC > > draft, and the various ippm drafts. Any such definition will > > need to be vetted with the ippm working group.____ > > > > __ __ > > > > Again, it would be good if members of the working group beyond > > the two author teams spoke up about their readings of the > > documents, and their understandings of what we need.____ > > > > __ __ > > > > Yours,____ > > > > Jim and Joel____ > > > > __ __ > > > > __ __ > > > > __ __ > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > > > > -- > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /Email gyan.s.mishra@verizon.com // > > / > > > > /M 301 502-1347 > > > > / > > > > > --000000000000f2cd7805d7e949d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joel,
I agree that, as we find SFC= NSH now, no OAM metadata has been defined. It appears to me that deprecati= ng the O bit does not affect any of the=C2=A0already defined mechanisms in = the=C2=A0SFC NSH. I think that if a new, for example, MD Type =3D 2 TLV tha= t=C2=A0is used for any OAM functionality to be proposed in the future, depr= ecated the O bit would=C2=A0not prevent using such NSH TLV.
What = do you think?

Regards,
Greg
<= br>
On Sun,= Feb 13, 2022 at 6:55 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
There is an implication of deprecating the O-bi= t that I would like to
hear from more WG participants about.

As far as I can tell, if we deprecate the O-bit and rely on the next
protocol field, we are saying that in practice (not by rule) NSH
metadata can not be used for OAM.=C2=A0 That's fine with me as long as = we
agree on that.

Yours,
Joel

On 2/13/2022 2:52 AM, Gyan Mishra wrote:
>
> Hi Jim, Joel & SFC WG,
>
> I agree that the RFC 8300 definition of O bit is incomplete and not > clear as to its intended use.
>
> That is a problem that I agree needs to be rectified.
>
> I understand that we need to get this resolved before we can progress =
> Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM.
>
> I agree that what makes sense to me as a path forward is to deprecate =
> the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC =
> Multilayer OAM and SFC IOAM are identified by the respective values fo= r
> the NSH Next Protocol field (to be assigned by IANA), as well as so fa= r
> no OAM-specific meta data TLV has been yet defined.
>
> So we have I believe solid solution and path forward and I support > deprecating the O bit.
>
> Kind Regards
>
> Gyan
>
> On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Thank you, Jim and Joel, for guiding the SFC OAM wo= rk and pointing
>=C2=A0 =C2=A0 =C2=A0out the issue that must be addressed.
>
>=C2=A0 =C2=A0 =C2=A0I've reviewed our SFC OAM documents and draft-i= etf-sfc-nsh-tlv. As I
>=C2=A0 =C2=A0 =C2=A0understand these documents, the Active SFC OAM and = IOAM are
>=C2=A0 =C2=A0 =C2=A0identified by the respective values for the NSH Nex= t Protocol field
>=C2=A0 =C2=A0 =C2=A0(to be assigned by IANA). At the same time, so far = no OAM-specific
>=C2=A0 =C2=A0 =C2=A0meta data TLV has been defined. Thus, it appears th= at one way
>=C2=A0 =C2=A0 =C2=A0forward could be to not involve the O bit in the ac= tive SFC OAM or
>=C2=A0 =C2=A0 =C2=A0IOAM altogether. In other words, to deprecate the N= SH O bit.
>
>=C2=A0 =C2=A0 =C2=A0I greatly appreciate your comments on the proposal = to deprecate the
>=C2=A0 =C2=A0 =C2=A0NSH O bit.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Wed, Feb 2, 2022 at 10:36 AM James Guichard
>=C2=A0 =C2=A0 =C2=A0<james.n.guichard@futurewei.com
>=C2=A0 =C2=A0 =C2=A0<mailto:james.n.guichard@futurewei.com>> wrot= e:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi WG:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Having reviewed all of the OAM relate= d documents in our WG, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chairs would like to provide a few co= mments to hopefully
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generate discussion and forward progr= ess of this work:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01) The chairs have reviewed the O bit= definition in RFC 8300.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0That definition is at best open to in= terpretation and therefore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0incomplete.=C2=A0 For example, the cl= ear intention is only to mark
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets which are intended for SFC OA= M at the SFC service
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0layer.=C2=A0 But that is not what the= current text says.=C2=A0 There is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also, unfortunately, ambiguity as to = what constitutes an OAM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packet.=C2=A0 So it is reasonable for= documents to update 8300 to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clarify the exact applicability and a= ction for the O-bit.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) However, related to point 1), we c= an't have multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0documents updating the definition dif= ferently.=C2=A0 As such, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authors of the SFC iOAM draft and the= SFC multi-layer-oam draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need to come together and figure out = what the clarification is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for the definition of that bit. We do= not believe as chairs that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0either of these documents can move fo= rward from the WG until
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0such clarity has been reached. ____ >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03) Related to the SFC iOAM, we need a= clear definition of iOAM.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There seem to be differences between = the definitions in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0published RFCs, the usage (which is n= ot a definition) in the SFC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft, and the various ippm drafts.= =C2=A0 Any such definition will
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need to be vetted with the ippm worki= ng group.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Again, it would be good if members of= the working group beyond
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the two author teams spoke up about t= heir readings of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0documents, and their understandings o= f what we need.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yours,____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jim and Joel____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sfc mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sfc@ietf.org <mailto:sfc@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/= mailman/listinfo/sfc
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.= org/mailman/listinfo/sfc>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0sfc mailing list
>=C2=A0 =C2=A0 =C2=A0s= fc@ietf.org <mailto:sfc@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listin= fo/sfc
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/li= stinfo/sfc>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /Email = gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>//
> /
>
> /M 301 502-1347
>
> /
>
>
--000000000000f2cd7805d7e949d8-- From nobody Sun Feb 13 09:32:27 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3193A3A07F0 for ; Sun, 13 Feb 2022 09:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.087 X-Spam-Level: X-Spam-Status: No, score=-1.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tg3hIYtn3a2h for ; Sun, 13 Feb 2022 09:32:21 -0800 (PST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 844CA3A07B7 for ; Sun, 13 Feb 2022 09:32:21 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id d9-20020a17090a498900b001b8bb1d00e7so13566352pjh.3 for ; Sun, 13 Feb 2022 09:32:21 -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=Jk55M4ZIUvxQ6fRttaD5murqjTx6KXf/FvmSrm/wLJk=; b=aI0xhzkoIrB0jRFpp6RNfZc4NY88bZQ4GDgLs8AAljD5M9we5OOvpv4/6r3y0HaQLq 7HkPCexlkNJ9aVzGhhe0VnuemTxAmQxDEBLE3HvBCJN9uk8ymFsC2phsGwOg7u2eWGcG MO0mRpuVpmDPLJlzR7ftbNZnq790o80v970HPsyUTK+/0hK+EaEF972rChPNiSAWfGrB dy6yoNubE9Yt7jjf2PMaIEQ3c7xnC6jccCG+HFDDwJPYYyqQczSR8rct8HtpLNUDJnrD izzKPuj4s2f1BglO4BG9z5zcy7cnv6Km7RyV5NNU0IpCx6X0vDsiBMmePt4DCgFkzvH0 ss4w== 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=Jk55M4ZIUvxQ6fRttaD5murqjTx6KXf/FvmSrm/wLJk=; b=U7k4xmEgL8tDW4AsiBYqQecdLLP9GfkoC3YJD6+l8XxvcBnQMI0d0xG30j31tzbC+q SdcsYhBgMkMRTqZz5TMUgh/NK2hd0dk3Rv1HQzBmThFLvcUxTZH1p2UXoelNaGNbrvYY w5II/DcQANt3GwBuMhlGSgN+byXcCRXQz7Dc/P8ju8/XcfGMzzC/kYP6RTFr2kRK6+EQ erKSgpVINNpc3Vloqra78EgN4q7pBqJQ7/xCz3W5w9dhpA9xwQ5HUc/M49+PttTPn1OX njpBd1NoXp0/s2nATAl5kyojRPyeo4aM+j2bPeSUVhZLmaK+btU75mSxZ1EjH4UTTjfA 2ZPg== X-Gm-Message-State: AOAM533CwFpqT4yu8FA09Lwxud9XafqTn4/sue0vz4uh6Yenim2n+l1S 8i68Qy1SOgNTbUh9HUlp3JKYOMRxgMebwkhqa24= X-Google-Smtp-Source: ABdhPJxXn04UolsuXzjXR/bkSc6Rd31p3uyBH8dnqGy7Nq1JRi972hmFsWGUHg6NxCowhbzIniPuhftlf/rxrn/JPQ4= X-Received: by 2002:a17:90b:38c9:: with SMTP id nn9mr10538242pjb.47.1644773537379; Sun, 13 Feb 2022 09:32:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sun, 13 Feb 2022 12:32:06 -0500 Message-ID: To: Greg Mirsky Cc: "Joel M. Halpern" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006e78c205d7e9aeb8" Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2022 17:32:26 -0000 --0000000000006e78c205d7e9aeb8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joel I am in agreement as well with what you have stated that once the O bit is deprecated that NSH metadata cannot be used for OAM and that we would have to now from that point forward rely on the next protocol field as we will be doing for SFC Multilayer and SFC IOAM drafts as well as will have backwards compatible with any already existing defined mechanisms in SFC NSH. I don=E2=80=99t see any issues or impact with moving forward. Kind Regards Gyan On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky wrote: > Hi Joel, > I agree that, as we find SFC NSH now, no OAM metadata has been defined. I= t > appears to me that deprecating the O bit does not affect any of the alrea= dy > defined mechanisms in the SFC NSH. I think that if a new, for example, MD > Type =3D 2 TLV that is used for any OAM functionality to be proposed in t= he > future, deprecated the O bit would not prevent using such NSH TLV. > What do you think? > > Regards, > Greg > > On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern > wrote: > >> There is an implication of deprecating the O-bit that I would like to >> hear from more WG participants about. >> >> As far as I can tell, if we deprecate the O-bit and rely on the next >> protocol field, we are saying that in practice (not by rule) NSH >> metadata can not be used for OAM. That's fine with me as long as we >> agree on that. >> >> Yours, >> Joel >> >> On 2/13/2022 2:52 AM, Gyan Mishra wrote: >> > >> > Hi Jim, Joel & SFC WG, >> > >> > I agree that the RFC 8300 definition of O bit is incomplete and not >> > clear as to its intended use. >> > >> > That is a problem that I agree needs to be rectified. >> > >> > I understand that we need to get this resolved before we can progress >> > Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM. >> > >> > I agree that what makes sense to me as a path forward is to deprecate >> > the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC >> > Multilayer OAM and SFC IOAM are identified by the respective values fo= r >> > the NSH Next Protocol field (to be assigned by IANA), as well as so fa= r >> > no OAM-specific meta data TLV has been yet defined. >> > >> > So we have I believe solid solution and path forward and I support >> > deprecating the O bit. >> > >> > Kind Regards >> > >> > Gyan >> > >> > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky > > > wrote: >> > >> > Thank you, Jim and Joel, for guiding the SFC OAM work and pointing >> > out the issue that must be addressed. >> > >> > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As= I >> > understand these documents, the Active SFC OAM and IOAM are >> > identified by the respective values for the NSH Next Protocol fiel= d >> > (to be assigned by IANA). At the same time, so far no OAM-specific >> > meta data TLV has been defined. Thus, it appears that one way >> > forward could be to not involve the O bit in the active SFC OAM or >> > IOAM altogether. In other words, to deprecate the NSH O bit. >> > >> > I greatly appreciate your comments on the proposal to deprecate th= e >> > NSH O bit. >> > >> > Regards, >> > Greg >> > >> > On Wed, Feb 2, 2022 at 10:36 AM James Guichard >> > > > > wrote: >> > >> > Hi WG:____ >> > >> > __ __ >> > >> > Having reviewed all of the OAM related documents in our WG, th= e >> > chairs would like to provide a few comments to hopefully >> > generate discussion and forward progress of this work:____ >> > >> > __ __ >> > >> > 1) The chairs have reviewed the O bit definition in RFC 8300. >> > That definition is at best open to interpretation and therefor= e >> > incomplete. For example, the clear intention is only to mark >> > packets which are intended for SFC OAM at the SFC service >> > layer. But that is not what the current text says. There is >> > also, unfortunately, ambiguity as to what constitutes an OAM >> > packet. So it is reasonable for documents to update 8300 to >> > clarify the exact applicability and action for the O-bit.____ >> > >> > __ __ >> > >> > 2) However, related to point 1), we can't have multiple >> > documents updating the definition differently. As such, the >> > authors of the SFC iOAM draft and the SFC multi-layer-oam draf= t >> > need to come together and figure out what the clarification is >> > for the definition of that bit. We do not believe as chairs th= at >> > either of these documents can move forward from the WG until >> > such clarity has been reached. ____ >> > >> > __ __ >> > >> > 3) Related to the SFC iOAM, we need a clear definition of iOAM= . >> > There seem to be differences between the definitions in >> > published RFCs, the usage (which is not a definition) in the S= FC >> > draft, and the various ippm drafts. Any such definition will >> > need to be vetted with the ippm working group.____ >> > >> > __ __ >> > >> > Again, it would be good if members of the working group beyond >> > the two author teams spoke up about their readings of the >> > documents, and their understandings of what we need.____ >> > >> > __ __ >> > >> > Yours,____ >> > >> > Jim and Joel____ >> > >> > __ __ >> > >> > __ __ >> > >> > __ __ >> > >> > _______________________________________________ >> > sfc mailing list >> > sfc@ietf.org >> > https://www.ietf.org/mailman/listinfo/sfc >> > >> > >> > _______________________________________________ >> > sfc mailing list >> > sfc@ietf.org >> > https://www.ietf.org/mailman/listinfo/sfc >> > >> > >> > -- >> > >> > >> > >> > *Gyan Mishra* >> > >> > /Network Solutions A//rchitect / >> > >> > /Email gyan.s.mishra@verizon.com // >> > / >> > >> > /M 301 502-1347 >> > >> > / >> > >> > >> > -- *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --0000000000006e78c205d7e9aeb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joel

I am in agreement as well with what you have stated that once the O bit i= s deprecated that NSH metadata cannot be used for OAM and that we would hav= e to now from that point forward rely on the next protocol field as we will= be doing for SFC Multilayer and SFC IOAM drafts as well as will have backw= ards compatible with any already existing defined mechanisms in SFC NSH. = =C2=A0

I don=E2=80=99t s= ee any issues or impact with moving forward.

Kind Regards=C2=A0

Gyan

On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky <<= a href=3D"mailto:gregimirsky@gmail.com">gregimirsky@gmail.com> wrote= :
Hi Joel,
I agree that, as we find SFC NSH now, no OAM metadata has bee= n defined. It appears to me that deprecating the O bit does not affect any = of the=C2=A0already defined mechanisms in the=C2=A0SFC NSH. I think that if= a new, for example, MD Type =3D 2 TLV that=C2=A0is used for any OAM functi= onality to be proposed in the future, deprecated the O bit would=C2=A0not p= revent using such NSH TLV.
What do you think?

Regards,
Greg

On Sun, Feb 13, 2= 022 at 6:55 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
There is an implication of deprecating = the O-bit that I would like to
hear from more WG participants about.

As far as I can tell, if we deprecate the O-bit and rely on the next
protocol field, we are saying that in practice (not by rule) NSH
metadata can not be used for OAM.=C2=A0 That's fine with me as long as = we
agree on that.

Yours,
Joel

On 2/13/2022 2:52 AM, Gyan Mishra wrote:
>
> Hi Jim, Joel & SFC WG,
>
> I agree that the RFC 8300 definition of O bit is incomplete and not > clear as to its intended use.
>
> That is a problem that I agree needs to be rectified.
>
> I understand that we need to get this resolved before we can progress =
> Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM.
>
> I agree that what makes sense to me as a path forward is to deprecate =
> the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC =
> Multilayer OAM and SFC IOAM are identified by the respective values fo= r
> the NSH Next Protocol field (to be assigned by IANA), as well as so fa= r
> no OAM-specific meta data TLV has been yet defined.
>
> So we have I believe solid solution and path forward and I support > deprecating the O bit.
>
> Kind Regards
>
> Gyan
>
> On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Thank you, Jim and Joel, for guiding the SFC OAM wo= rk and pointing
>=C2=A0 =C2=A0 =C2=A0out the issue that must be addressed.
>
>=C2=A0 =C2=A0 =C2=A0I've reviewed our SFC OAM documents and draft-i= etf-sfc-nsh-tlv. As I
>=C2=A0 =C2=A0 =C2=A0understand these documents, the Active SFC OAM and = IOAM are
>=C2=A0 =C2=A0 =C2=A0identified by the respective values for the NSH Nex= t Protocol field
>=C2=A0 =C2=A0 =C2=A0(to be assigned by IANA). At the same time, so far = no OAM-specific
>=C2=A0 =C2=A0 =C2=A0meta data TLV has been defined. Thus, it appears th= at one way
>=C2=A0 =C2=A0 =C2=A0forward could be to not involve the O bit in the ac= tive SFC OAM or
>=C2=A0 =C2=A0 =C2=A0IOAM altogether. In other words, to deprecate the N= SH O bit.
>
>=C2=A0 =C2=A0 =C2=A0I greatly appreciate your comments on the proposal = to deprecate the
>=C2=A0 =C2=A0 =C2=A0NSH O bit.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Wed, Feb 2, 2022 at 10:36 AM James Guichard
>=C2=A0 =C2=A0 =C2=A0<james.n.guichard@futurewei.com
>=C2=A0 =C2=A0 =C2=A0<mailto:james.n.guichard@futurewei.com>> wrot= e:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi WG:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Having reviewed all of the OAM relate= d documents in our WG, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chairs would like to provide a few co= mments to hopefully
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generate discussion and forward progr= ess of this work:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01) The chairs have reviewed the O bit= definition in RFC 8300.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0That definition is at best open to in= terpretation and therefore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0incomplete.=C2=A0 For example, the cl= ear intention is only to mark
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets which are intended for SFC OA= M at the SFC service
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0layer.=C2=A0 But that is not what the= current text says.=C2=A0 There is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also, unfortunately, ambiguity as to = what constitutes an OAM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packet.=C2=A0 So it is reasonable for= documents to update 8300 to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clarify the exact applicability and a= ction for the O-bit.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) However, related to point 1), we c= an't have multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0documents updating the definition dif= ferently.=C2=A0 As such, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authors of the SFC iOAM draft and the= SFC multi-layer-oam draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need to come together and figure out = what the clarification is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for the definition of that bit. We do= not believe as chairs that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0either of these documents can move fo= rward from the WG until
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0such clarity has been reached. ____ >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03) Related to the SFC iOAM, we need a= clear definition of iOAM.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There seem to be differences between = the definitions in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0published RFCs, the usage (which is n= ot a definition) in the SFC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft, and the various ippm drafts.= =C2=A0 Any such definition will
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need to be vetted with the ippm worki= ng group.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Again, it would be good if members of= the working group beyond
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the two author teams spoke up about t= heir readings of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0documents, and their understandings o= f what we need.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yours,____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jim and Joel____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sfc mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sfc@ietf.org <mailto:sfc@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/= mailman/listinfo/sfc
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.= org/mailman/listinfo/sfc>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0sfc mailing list
>=C2=A0 =C2=A0 =C2=A0s= fc@ietf.org <mailto:sfc@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listin= fo/sfc
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/li= stinfo/sfc>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /Email = gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>//
> /
>
> /M 301 502-1347
>
> /
>
>
--
--0000000000006e78c205d7e9aeb8-- From nobody Sun Feb 13 20:07:14 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8783A0D71 for ; Sun, 13 Feb 2022 20:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.584 X-Spam-Level: X-Spam-Status: No, score=-9.584 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BHauT1zb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=b+MeHfkq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AeshG03wxlh for ; Sun, 13 Feb 2022 20:07:04 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310583A0D6F for ; Sun, 13 Feb 2022 20:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50791; q=dns/txt; s=iport; t=1644811624; x=1646021224; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J2L91Sb3Y9EAuWbk5FbFgfePQtHAT7X+jxJ865HyEJ8=; b=BHauT1zblKdmZRo0o0KPi+xXmyuUKXyTpEIvln91zDIYO7SkZ2vSipRZ T5eJ+UfTswvmShDWNYdrd6VVRcpg779VsPw1GyJm5EO8n3p7+jmjguCb3 WdYGspTvSJEeUaQQTuxmyetb+2U5/sJCtntrTV0QmmJdvhOvFEQBQCv9P c=; IronPort-PHdr: =?us-ascii?q?A9a23=3AS2PSnRGD5LNYtdt9NH73oZ1GfiYY04WdBeZdw?= =?us-ascii?q?pYkircbdKOl8tyiOUHE/vxigRfPWpmT8PNLjefa8sWCEWwN6JqMqjYOJZpLU?= =?us-ascii?q?RJWhcAfhQd1BsmDBAXyJ+LraCpvGsNEWRdl8ni3PFITFtz5YgjZo2a56ngZH?= =?us-ascii?q?RCsXTc=3D?= IronPort-Data: =?us-ascii?q?A9a23=3ABSq9qK2ukHqoREjSTPbD5RVzkn2cJEfYwER7X?= =?us-ascii?q?KvMYLTBsI5bp2cHmzZKXmqOO/+LajD0ft12PIywph4E6MKAz9EwQAE63Hw8F?= =?us-ascii?q?HgiRegpqji6wuYcB84ZRyH6ZBoPA/42N5+QfKjYcleG/k33auK59CElvU21b?= =?us-ascii?q?uOU5NDsa3gZqTBMEE/NuTo78wIIqtYAbeqRWmthivuqyyHrA2JJ7hYvWo4iB?= =?us-ascii?q?w1vnzs01Bj6kGtwUlXT/pmntneG/5UeJMp3ya1csxLFrodo8u6SH44vzZmw+?= =?us-ascii?q?mffuhwqEN7gyPDwc1YBRfjZOg3mZnh+Avf5xEMc4HVplP9gaZLwam8P49mNt?= =?us-ascii?q?9tpydpLvIC5YQwoJabL3u8aVnG0FgkvbPEYqeGdeyXXXcu7iheun2HX6+5gB?= =?us-ascii?q?2k3MJEWvOFtDglm+uYVJzEIbwqYhPOez7eyS+0qjcMmROHrNZIWsGx7xD7CC?= =?us-ascii?q?N4pRJnCR+PB4tow4duarqiiBt7XY84fLDFodhmFOVtEO0wcD9Q1m+LAu5U2S?= =?us-ascii?q?BUAwHr9mEb9yzG7INRN7YXQ?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A1mbO6a4Rcbrc54LeoQPXwWuBI+orL9Y04l?= =?us-ascii?q?Q7vn2ZFiY1TiXIra6TdaoguiMc0AxhJ03Jmbi7Sc69qADnhOBICOgqTPaftW?= =?us-ascii?q?zd2FdAQ7sSlrcKrweQfhEWs9QtqZuIEJIOSOEYb2IK9/oSiTPQe71LrbX3k9?= =?us-ascii?q?HLuQ6d9QYRcegAUdAH0+4NMHfiLqQAfng+OXNWLuv52uN34x6bPVgHZMWyAX?= =?us-ascii?q?cIG8LZocfQqZ7gaRkaQzY69Qinl1qTmf3HOind+i1bfyJEwL8k/2SAuRf+/L?= =?us-ascii?q?+fv/ayzQKZ/3PP7q5RhMDqxrJ4dY6xY4kuW3DRYzSTFcNcso65zXYISSaUmQ?= =?us-ascii?q?8Xeez30lMd1gJImivsly+O0EDQMkLboUcTAjfZuC+laD3Y0JbErPZQMbscuW?= =?us-ascii?q?qfGSGptnbI9esMop5jziaXsYFaAgjHmzm479/UVwtynk7xunY6l/UP5kYvHb?= =?us-ascii?q?f3+Ndq3P8iFW5uYd099RjBmc0a+ShVfbfhzecTdUnfY2HSv2FpztDpVnMvHg?= =?us-ascii?q?2eSkxHvsCOyTBZkH1w0kNdnaUk7zk93YN4T4MB6/XPM6xumr0LRsgKbbhlDO?= =?us-ascii?q?NERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkfoIzfDvfIZNwIo5mZzHXl8dvW?= =?us-ascii?q?kue1j2AcnLx5FP+gClehT3Yd0s8LAX23FUgMyJeFPbC1zLdLl1qbrUnxw2OL?= =?us-ascii?q?ytZ8qO?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAADrHvlh/4cNJK1XAxwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBggYHAQELAYEgMSguB3daEyQxhEmDRwOEWWCFDoMCA4ETiX2?= =?us-ascii?q?QFIEuFIERA08FCwEBAQ0BASoBDAoEAQGFBQIXg0gCJTQJDgECBAEBARIBAQU?= =?us-ascii?q?BAQECAQYEgQkThWgNhkMBAQEDAQEQCAkdAQEsBAcBDwIBBgIHBwodAwEGAwI?= =?us-ascii?q?CAh8GCxQRAgQOBRsHgmIBgg5XAy4BDpJ3jzYBgToCih96gTGBAYIIAQEGBAS?= =?us-ascii?q?BNgETQUeCOw0LgjcJgSMXAYMNhBwBAYEehWknHIFJRIEVJxyBZkoHMD6CIUI?= =?us-ascii?q?BAQOBKAESASAYCgwJCAmCURcggi6RLBoBFEYtFyYBAy8UDwEFGwINLCAWMgI?= =?us-ascii?q?VBTULHgIoEJF0FIMAR4lOP4NBiXKQdD9DawqDRosBiC6GNYV5BS6DcowcWpc?= =?us-ascii?q?flkqCR4pIg06RRYQgAgQCBAUCDgEBBoFhPGlwcBU7KgGCPgk1ExkPjiCDcYU?= =?us-ascii?q?UhUp0AjYCBgEKAQEDCYxvXQEB?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208,217";a="994696225" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Feb 2022 04:06:46 +0000 Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 21E46kkP032669 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 14 Feb 2022 04:06:46 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Sun, 13 Feb 2022 22:06:45 -0600 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Sun, 13 Feb 2022 23:06:45 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Sun, 13 Feb 2022 22:06:45 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CzqKdi7QdCkan5iBWjSQ4Tfsntz5e1aab/3AgjCzE0jytLgWDUTeqkP4w2eorzc1w6d/kg9YhO2gQLowJKyyMPvGaCjWVOJ1m/YHlqddCiOJPGKU2wwO/Ym7wwMZnd+UAJUJJxd1Js7DE06DrD6lXiypWo3vzn5o+MDGIOPHYM663OgPqqXvkJ6hv7bEnaFYtR7GCnC/uJUtOd020GWorkqm+bHOd8bDRcmrbEXJPY6dRSkY5Tck9eopGHQFAgF4BWQkfQR5k9i8VSPBihUvjCWtSBzVMBqH+C6VVq1Ovbce980dR9HSHb/kB+2UyVKpr9VHGb7NA54/5B/kV9tamQ== 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=J2L91Sb3Y9EAuWbk5FbFgfePQtHAT7X+jxJ865HyEJ8=; b=OvhOO8xOyEFk9ig+G8TUgB6T8h3F5cUNJIM0HdD/jx4/ZfeWquHLE8d2R+/YbNxJVt7MWErzKRGqXzCQGxdKV649oMMIiHsmR8GJLf+v5++uNZHoQGhkDCtRHvUyIhbG4QI9xtuwIvmXb2Hp/UNJLB7Me34wStOtzjOQCWgmijwA5YYW27WRO55Cg0pgrS6X+ZDmZcjEarizsxiog2xtvaHEtR/hM2WdMTly3692bLCGwxP+lDV3fEwLwjoW+ngTsqIX9cuByNQ6Jaldu4f13FADHUzkqRRkssBUYv4zIL9anDXnTw3XpD8u7/RkR5/YAu+p2Qr6sYc+bvJSlCsQFw== 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=J2L91Sb3Y9EAuWbk5FbFgfePQtHAT7X+jxJ865HyEJ8=; b=b+MeHfkqfWIWKz4GiIcN5OHpBWGp2eFqpdAKQHej+GlSAixly8d9f+VRhjRqmiGrwRMq6XKYrnpbNjxf7Sml8rjp5QqtdvplZS72C01keMgCOmG3rMvAvfCeEzfE0j21lbPZFYXte5I67/G/LhDIDVVKerenkQ5bMexAPBeA5aU= Received: from DS7PR11MB6039.namprd11.prod.outlook.com (2603:10b6:8:76::6) by BYAPR11MB3175.namprd11.prod.outlook.com (2603:10b6:a03:7c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.14; Mon, 14 Feb 2022 04:06:43 +0000 Received: from DS7PR11MB6039.namprd11.prod.outlook.com ([fe80::e131:742a:954d:492c]) by DS7PR11MB6039.namprd11.prod.outlook.com ([fe80::e131:742a:954d:492c%6]) with mapi id 15.20.4975.012; Mon, 14 Feb 2022 04:06:42 +0000 From: "Carlos Pignataro (cpignata)" To: Gyan Mishra CC: Greg Mirsky , "sfc@ietf.org" Thread-Topic: [sfc] Progression of OAM work in the SFC WG Thread-Index: AdgYYtG+l/ju054uSCa0IEDodR5p4AAI1AYAAgogAwAADsqJgAAEeXQAAAD7PAAAFinEAA== Date: Mon, 14 Feb 2022 04:06:42 +0000 Message-ID: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3693.60.0.1.1) 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: 9069e14d-b9e7-4259-823e-08d9ef6f68dd x-ms-traffictypediagnostic: BYAPR11MB3175:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CdoiaSBHYZhkCfk0uwZXw/t9/YvngKJ2rg5vksNo2/xVNn54N/gJmDyjJP7dW9/iF5v5SoHdf6r0bi1muZ6UqdkoHgxXBT6hqa2+V3irBV7j9kpsTDfgOSLsmByD6rDiOo7Dtt4qnUxcvNRqwKkXSc3OM2qzF2ypVWxiIbMcPJdscCpHKhGjzHxkvAFpDDO3TRlrPu1/h2Lt96XtkdyG9lwjMPjRzrFjQs/SAiWVnvurhwvLmv3K28m7IGHKDUepqO01hHpJ76WIFRUDpPVus64NIy6p/BdF6FvV16LfBf9bEr64yk5qLaAUw2D59fJLwPz9sZUL5L9yuIKB9uxPOiqbR+SRSXLvloPt+OvSw/7qTXzxok1rHZpMWhoI44WFPDblvNADrVgENJJ/dNX+eAJtdQnPY+tjFNzrUT6pVtdXKiQBgfHhKQ8elhKv/AxWuisdLK8wHa0Se3myO7g0RLXXXE2zTjMdrtnFXhiM3ODrz+azYeoUoUSPvIEOiAeqc+8jsJmI5Ao2SFtt0dsgfsnkfsD2eAPh/JT/ZGH6MltcBIZX/tQQT6tyRMv3LwpHhNQYDDbQMYVcfCAd3SisNBB6PYTeMSlZb7mVptq223BszSBThjILncorFsl7kjBAP9muC540UqAIdSWTZHAbM3xqhAy5LB5C9/6f+AJyx2l2GZr4A3uSBj49XFQEB9hURl3V+Mm4fWgt5KD39wMecLfPP7xL0w7kzcgXrnux2MU2xl7mOpSsP4AV5fMsBPftVViao6ZtwO6b1elGcgaARMAkEFjC67GKNgJ+fpTnGfRjWah2OasE4iB3oFAnXq2q56HMIBkFXHwZjM28/G5o/nuu1QWwaAUi0YWWwCCNrS4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS7PR11MB6039.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(508600001)(66476007)(6506007)(38070700005)(66446008)(66556008)(38100700002)(64756008)(2906002)(122000001)(4326008)(66946007)(166002)(8676002)(5660300002)(186003)(26005)(6512007)(71200400001)(83380400001)(76116006)(8936002)(30864003)(6486002)(86362001)(53546011)(2616005)(36756003)(966005)(33656002)(54906003)(316002)(6916009)(40140700001)(91956017)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WWlvMVNjOGJWNStXeE5lQjdoaDVjYm5MdlFCZGdCbWFIRUkzVDJLWWpKME5Q?= =?utf-8?B?R2ZNcmFXQ1d3M2xrYjJGRndQV2lIN3lha2JYZWw0bW4yWUJIQi9IY0ZhdVV0?= =?utf-8?B?WFlxLzJOZkk0ekRHSkxYZEJtK3VXUkVzZURTdlFxM21lcXZNQWFkRlhYN3JH?= =?utf-8?B?ekNjYWIxbWtZUENnL0NvNkFnTkRiRGxaL0crT3pWR0NwL3pmRkZna09Ycy9W?= =?utf-8?B?SSt2Y204YThRbTNFS2VrNEdoRFdLWXhvWmNRMzhycFZRalVlOFlWb1RFUzZO?= =?utf-8?B?MmZvWEJSSjF6ZDNiUUp5VkNiZzAyMTB0cXBxUGMzMU02MnY4TkRjMUV3dXlp?= =?utf-8?B?Z1pRNDIwNkg5aGFrMmFUZG5SR2hNY0VuYitPaFRPbllGVFFuQmJqakxSY2dN?= =?utf-8?B?ZmdSeWxEZjNmUENSbURubmp2eXZ0SDBKMHZESHVpdUpBaHVCN2kxbFlNMmpM?= =?utf-8?B?eWt6aFJ2amlRb0dmQStsWkRISUdaaHNBNXNab1VqTE9pTzNOZnMxbEhOS1pp?= =?utf-8?B?WnlJOVk0RldmcUo2NjVFbDdvbk1KWVcrZWlTL3RhaDcyZWZUdFlpL0tsb0Vp?= =?utf-8?B?cEtXcS96S2xMWTQxUmUwWjhOT1NHVnlSQkFyT3BFeWNxN3Faa2k0Sk9lR2Ez?= =?utf-8?B?NWExSjhKMjVhNG9mU3oybkRQc0xkOEgrMjFob1M2MjhMajc4RDA3M0Q5bkty?= =?utf-8?B?ZGxaZHRIaTdPOHlCN08xK0hOUkY2ZEJ1ZTZOdU9nN1NpL0pjNHl5a1pla3lt?= =?utf-8?B?VHJlT1NNZThETDNPMkFmVnNQdkhQMzhvS2lySDRHUitWUnZNZ0w5eHdXVlRs?= =?utf-8?B?VXE1bmlqcWVQTUhXemNoQ1dnUXFYVkU1WXhTYnFLdDhKWEJwMTd4MHdlWGU4?= =?utf-8?B?bEp4SnNiUllmblk1cGtiVDFaSDdKMjdSYzY5eHZreEM3Z2ZZK2tBVDhGMHBm?= =?utf-8?B?K1d1SmNzV05sTHpndDFrU1p5N3lnaGtjTlpFNVM0Ynd5eTVITFFhaW1pMW9S?= =?utf-8?B?Q2hYRjlmSDIydmN5SGphMEFQU0dQLzdkQmVLdDhzSGo3RVFSdFR6NWdIeUcr?= =?utf-8?B?bVoxaDFmMllUVExsOGRCMDJaY0I4SXFkTURKKytpOGpIa0FEcW4vbWJ6OThH?= =?utf-8?B?NUd5aWUyalU4U1lGaC9vWWlWSlN4QWpXWmhSTkhpbE00OWFYK2JrNW9VMG13?= =?utf-8?B?eTk4aTNSNVZyUmRHYVVya0swa3lFeml5Wjk0eXU3ZDJPYVBlb3QreWRKR2tk?= =?utf-8?B?aENRUGNsaDVzN1VGWm5KZFBPVXNKcjgyd2c1NUltRWsyZFBiQnBYVUZHVkVS?= =?utf-8?B?ZUd3OWZjazk2d1doVVkrYW9HRWp1S05tYm9MY0tWdi9NWHBXdlRNb0ZDM1FI?= =?utf-8?B?a3ZQQ1QrTkdXckNGbHFFVlVrWERDNWVjZENGdFJxRDBSMllycXdhQjIyMUdH?= =?utf-8?B?TDNHSUtiK0IrYTBDNExOZXBvQUthOW85NFZ1dEZWT1BscVYvNnhRZFpqVjQv?= =?utf-8?B?UUhlNHBGZ2dYVHczcktGclBvaFFFZGI3OTdoQTNTdmhVT0M5RmtkTnBvZHUy?= =?utf-8?B?V29MVXJsbDkvV0VnSStuMHUwcXpEV2ZzOGJNOGFOTHhKbmJMOUI5RVM3dmFy?= =?utf-8?B?U2xDWkk1cEttbnFCTzQwK1Z3ZDVOcEduSDhaUCtPVHpBWHFqemt3V2lxb1o4?= =?utf-8?B?OVFZSU14ODU2RnBnMm4xS1FoU3ljVThOZlZwMHhpa2dVZnd0cW1ObE11Q2tu?= =?utf-8?B?K3RqNXp1MzRBTXJDK1k2R01iNHFwMGVBZ0Z6SlRxcjRVS0FZRDluQ1lCcjkw?= =?utf-8?B?U2VucUNGUHQzMklkS0orN0lZNmtYOFJWd1N0V2Y1RE9aclpDVms5akZyd3Ru?= =?utf-8?B?Q0xjSS9hVkRSN1VuaHlmWDhMdnhRQW9TQksydkVrT0lnTmVhRzRrN3IzOU9B?= =?utf-8?B?U1JJa2V4MmRwc0xrU3dBSUZkRDAzUXRmUnRxSVlKdW5YTWNHY0krLzR3d2dF?= =?utf-8?B?N0VBRnRwaEUyVWErVXRLSlFLV0EyV0NrNEJaS3h2V1pTbmNiMXNGUHpjYmlP?= =?utf-8?B?SnZyWUZtbHdrRWJ0VDc5b1VyRkVqUVdibzMyNHQydE03V0UyNy84QUIwaDhn?= =?utf-8?B?VDMzRXV4ejM3ckt0TnVlcWNISldNdzVEdmpQNUp6SW1BODFMVVFiWmxyMkMx?= =?utf-8?Q?M9DOckUaUWOrZty830JVK3o=3D?= Content-Type: multipart/alternative; boundary="_000_3CDEE7495A4044FF9E3A8C8EBBA94849ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB6039.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9069e14d-b9e7-4259-823e-08d9ef6f68dd X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2022 04:06:42.8610 (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: 4iBKAfaWe0bAYybTb2DFGQ1PlXP4WTu5ZkjE5GzZxhmFW7W8k2tyk3a+lHJrGDfiAhk8K78tFll16J5Qhz0eIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3175 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 04:07:10 -0000 --_000_3CDEE7495A4044FF9E3A8C8EBBA94849ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVwbHlpbmcgdG8gdGhpcyBzcGVjaWZpYyBlbWFpbCBpbiB0aGUgdGhyZWFkLCBvbmx5IGJlY2F1 c2UgaXQgaXMgdGhlIGxhdGVzdCBvbmUgYXQgdGhpcyBwb2ludCBpbiB0aW1lLCBidXQgYnVuZGxp bmcgY29tbWVudHMgZnJvbSB2YXJpb3VzIHBsYWNlcyBvbiB0aGUgdGhyZWFkLiBQbGVhc2UgZmlu ZCBzb21lIGZvbGxvdy11cCBjb21tZW50cyBhbmQgcXVlc3Rpb25zIG1hcmtlZCDigJxDTVDigJ0s IGluZGljYXRpbmcgdGhlIOKAnEZyb23igJ0sIGFuZCBvcmdhbml6ZWQgY2hyb25vbG9naWNhbGx5 Og0KDQpKYW1lcyBOIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208bWFp bHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4+Og0KDQoxKSBUaGUgY2hhaXJzIGhh dmUgcmV2aWV3ZWQgdGhlIE8gYml0IGRlZmluaXRpb24gaW4gUkZDIDgzMDAuICBUaGF0IGRlZmlu aXRpb24gaXMgYXQgYmVzdCBvcGVuIHRvIGludGVycHJldGF0aW9uIGFuZCB0aGVyZWZvcmUgaW5j b21wbGV0ZS4gIEZvciBleGFtcGxlLCB0aGUgY2xlYXIgaW50ZW50aW9uIGlzIG9ubHkgdG8gbWFy ayBwYWNrZXRzIHdoaWNoIGFyZSBpbnRlbmRlZCBmb3IgU0ZDIE9BTSBhdCB0aGUgU0ZDIHNlcnZp Y2UgbGF5ZXIuICBCdXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgY3VycmVudCB0ZXh0IHNheXMuICBU aGVyZSBpcyBhbHNvLCB1bmZvcnR1bmF0ZWx5LCBhbWJpZ3VpdHkgYXMgdG8gd2hhdCBjb25zdGl0 dXRlcyBhbiBPQU0gcGFja2V0LiAgU28gaXQgaXMgcmVhc29uYWJsZSBmb3IgZG9jdW1lbnRzIHRv IHVwZGF0ZSA4MzAwIHRvIGNsYXJpZnkgdGhlIGV4YWN0IGFwcGxpY2FiaWxpdHkgYW5kIGFjdGlv biBmb3IgdGhlIE8tYml0Lg0KDQpDTVA6IEl0IGlzIHVuY2xlYXIgdG8gbWUgd2hhdCBleGFjdCBp c3N1ZXMgdGhlIGNoYWlycyBhcmUgY2FsbGluZyBvdXQuIFRoZXJlIGFyZSB0d28gaXNzdWVzIG1l bnRpb25lZDoNCkNNUDogMS4gIkJ1dCB0aGF0IGlzIG5vdCB3aGF0IHRoZSBjdXJyZW50IHRleHQg c2F5cy7igJ0g4oCUPiB3aGF0IGRvZXMgdGhlIHRleHQgc2F5IHByZWNpc2VseT8gIENhbiB5b3Ug cG9pbnQgdG8gdGhlIHNwZWNpZmljIFJGQyA4MzAwIHRleHQgdGhhdCBpcyBiZWxpZXZlZCB0byBi ZSBpbmNvbXBsZXRlLCBhbmQgYSBkZXRhaWxlZCB1c2UgY2FzZSB0aGF0IHNob3djYXNlcyB0aGUg cG90ZW50aWFsIGlzc3VlPyBBbiBleHRyYXBvbGF0ZWQgY291bnRlci1leGFtcGxlIGp1c3QgdG8g bWFrZSBhIHBvaW50OiB0aGUgdGV4dCBkb2VzIG5vdCAgc2F5IHdoYXQgZGF5cyBvZiB0aGUgd2Vl ayBPQU0gcGFja2V0cyBjYW4gYmUgbWFya2VkLCB5ZXQgdGhlcmXigJlzIGFuIGV4cGVjdGF0aW9u IHRoYXQgdGhleSB3aWxsIHdvcmsgTW9uZGF5cyBhbmQgU2F0dXJkYXlzIGFsbCB0aGUgc2FtZSDi gJQgZXZlbiBob2xpZGF5cy4NCkNNUDogMi4gV2hhdCBzcGVjaWZpY2FsbHkgaXMgdGhlIGFtYmln dWl0eSB3aXRoIHdoYXQgYW4gT0FNIHBhY2tldCBpcz8gUGxlYXNlIGdyZXAgdGhlIFJGQyBzZXJp ZXMgZm9yIOKAnG9hbSBwYWNrZXTigJ0sIGl0IGlzIG5vdCBhIG5ldyB0ZXJtLg0KQ01QOiBOZXQt bmV0LCBPLWJpdD0xLCBPQU0gcGFja2V0Lg0KDQoyKSBIb3dldmVyLCByZWxhdGVkIHRvIHBvaW50 IDEpLCB3ZSBjYW4ndCBoYXZlIG11bHRpcGxlIGRvY3VtZW50cyB1cGRhdGluZyB0aGUgZGVmaW5p dGlvbiBkaWZmZXJlbnRseS4gIEFzIHN1Y2gsIHRoZSBhdXRob3JzIG9mIHRoZSBTRkMgaU9BTSBk cmFmdCBhbmQgdGhlIFNGQyBtdWx0aS1sYXllci1vYW0gZHJhZnQgbmVlZCB0byBjb21lIHRvZ2V0 aGVyIGFuZCBmaWd1cmUgb3V0IHdoYXQgdGhlIGNsYXJpZmljYXRpb24gaXMgZm9yIHRoZSBkZWZp bml0aW9uIG9mIHRoYXQgYml0LiBXZSBkbyBub3QgYmVsaWV2ZSBhcyBjaGFpcnMgdGhhdCBlaXRo ZXIgb2YgdGhlc2UgZG9jdW1lbnRzIGNhbiBtb3ZlIGZvcndhcmQgZnJvbSB0aGUgV0cgdW50aWwg c3VjaCBjbGFyaXR5IGhhcyBiZWVuIHJlYWNoZWQuDQoNCkNNUDogSWYgdGhlcmUgaXMgc3RpbGwg YmVsaWV2ZWQgdG8gYmUgYW4gYW1iaWd1aXR5IG9yIGEgY2xlYXIgb3Bwb3J0dW5pdHkgZm9yIGlt cHJvdmluZyB0aGUgZGVmaW5pdGlvbiwgSSBhZ3JlZSB3aXRoIGNvbnNvbGlkYXRpbmcgdGhhdCB1 cGRhdGUuIEkgaGFkIHN1Z2dlc3RlZCBiZWZvcmUgdGhhdCBpZiBzdWNoIG5ldyB0ZXh0IG9yIHJl YWwgY2xhcmlmaWNhdGlvbiBpcyBhZ3JlZWQsIGEgc2VwYXJhdGUgZG9jdW1lbnQgdGhhdCBvbmx5 IG1ha2VzIHRoYXQgTy1iaXQgY2xhcmlmaWNhdGlvbiBpcyB0aGUgbW9zdCBjbGVhciBhbmQgY2xl YW4gd2F5IHRvIGdvLiBUaGF0IGRvYyBzaG91bGQgYmUgYSBvbmUtcGFnZXIgb3IgbGVzcy4gSeKA mWQgYmUgaGFwcHkgdG8gY29udHJpYnV0ZSB0byB0aGF0IG1pbmltYWwgZG9jLCBpZiBpdCBpcyBz aG93biB0byBiZSBuZWVkZWQuDQoNCkNNUDogRm9yIGNvbXBsZXRlbmVzcyBhbHNvLCB0aGUgIlNG QyBtdWx0aS1sYXllci1vYW3igJ0gZG9jdW1lbnQgaGFzIG1hbnkgb3V0c3RhbmRpbmcgaXNzdWVz IGJlc2lkZXMgdGhlIE8tYml0Lg0KDQpHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29t PG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+Pg0KDQpJJ3ZlIHJldmlld2VkIG91ciBTRkMg T0FNIGRvY3VtZW50cyBhbmQgZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi4gQXMgSSB1bmRlcnN0YW5k IHRoZXNlIGRvY3VtZW50cywgdGhlIEFjdGl2ZSBTRkMgT0FNIGFuZCBJT0FNIGFyZSBpZGVudGlm aWVkIGJ5IHRoZSByZXNwZWN0aXZlIHZhbHVlcyBmb3IgdGhlIE5TSCBOZXh0IFByb3RvY29sIGZp ZWxkICh0byBiZSBhc3NpZ25lZCBieSBJQU5BKS4NCg0KQ01QOiBUaGVyZSBpcyBhIG1ham9yIGlz c3VlIHdpdGggdGhlIHNlbnRlbmNlIGFib3ZlLiBBY3RpdmUgU0ZDIE9BTSAoYXMgYSBjYXRlZ29y eSksIGFzIHBlciBSRkMgODMwMCwgbmVlZHMgdG8gYmUgaWRlbnRpZmllZCBieSBzZXR0aW5nIHRo ZSBPLWJpdC4gTm8gd2F5IGFyb3VuZCB0aGF0IGJhc2VkIG9uIFJGQyA4MzAwLiBIb3dldmVyLCB0 aGUgdGV4dCAidGhlIEFjdGl2ZSBTRkMgT0FN4oCdIGNyZWF0ZXMgY29uZnVzaW9uIHNpbmNlIGl0 IHJlZmVyIHRvIGEgc3BlY2lmaWMgT0FNIHByb3RvY29sIHdoaWNoIGhhcyB0aGUgc2FtZSBuYW1l IGFzIGEgdGhlIGNhdGVnb3J5IGFzIHdlbGwuIFRoYXQgbmFtZSBjb2xsaXNpb24gaXMgcXVpdGUg dW5mb3J0dW5hdGUgaW4gbXkgb3Bpbmlvbi4NCg0KQXQgdGhlIHNhbWUgdGltZSwgc28gZmFyIG5v IE9BTS1zcGVjaWZpYyBtZXRhIGRhdGEgVExWIGhhcyBiZWVuIGRlZmluZWQuIFRodXMsIGl0IGFw cGVhcnMgdGhhdCBvbmUgd2F5IGZvcndhcmQgY291bGQgYmUgdG8gbm90IGludm9sdmUgdGhlIE8g Yml0IGluIHRoZSBhY3RpdmUgU0ZDIE9BTSBvciBJT0FNIGFsdG9nZXRoZXIuIEluIG90aGVyIHdv cmRzLCB0byBkZXByZWNhdGUgdGhlIE5TSCBPIGJpdC4NCg0KQ01QOiBSRkMgODkyNCBhbHJlYWR5 IGluY2x1ZGVzIElDTVAgYW5kIEJGRCBhcyBleGFtcGxlIFNGQyBBY3Rpb24gT0FNIHByb3RvY29s cy4gVGhvc2UgY2FuIGJlIGVuY2Fwc3VsYXRlZCBpbiBJUCwgaW4gd2hpY2ggdGhlIE5leHQtUHJv dG9jb2wgaW5kaWNhdGVzIElQIOKAlCBhbmQgKGFzIHBlciBSRkMgODMwMCkgdGhlIE8tYml0IGlz IHNldCB0byBpbmRpY2F0ZSBhbiBPQU0gcGFja2V0Lg0KQ01QOiBUaGUgcHJvcG9zYWwgb2YgZGVw cmVjYXRpbmcgdGhlIE8tYml0IGJyZWFrcyB0aG9zZSBTRkMgT0FNIHByb3RvY29scyBhbHJlYWR5 IGluY2x1ZGVkIGluIGFuIFJGQy4NCkNNUDogVGhhdCBwcm9wb3NhbCBvZiBkZXByZWNhdGluZyB0 aGUgTy1iaXQgYWxzbyBicmVha3MgU2VjdGlvbiA0LjEgb2YgSU9BTS4NCkNNUDogVGhpcyBleHBp cmVkIEktRCB5ZXQgaW1wbGVtZW50ZWQgaW4gb3BlbiBzb3VyY2UgdXNlcyB0aGUgTy1iaXQ6IGh0 dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtcGVubm8tc2ZjLXRyYWNlLTAzLnR4 dA0KDQoNCkd5YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFpbC5jb208bWFpbHRvOmhheWFidXNh Z3NtQGdtYWlsLmNvbT4+DQoNCkkgYWdyZWUgdGhhdCB3aGF0IG1ha2VzIHNlbnNlIHRvIG1lIGFz IGEgcGF0aCBmb3J3YXJkIGlzIHRvIGRlcHJlY2F0ZSB0aGUgTyBiaXQgYW5kIG5vdCB1c2UgaW4g U0ZDIE11bHRpbGF5ZXIgT0FNIGFuZCBTRkMgSU9BTSwgYXMgYm90aCBTRkMgTXVsdGlsYXllciBP QU0gYW5kIFNGQyBJT0FNIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSByZXNwZWN0aXZlIHZhbHVlcyBm b3IgdGhlIE5TSCBOZXh0IFByb3RvY29sIGZpZWxkICh0byBiZSBhc3NpZ25lZCBieSBJQU5BKSwg YXMgd2VsbCBhcyBzbyBmYXIgbm8gT0FNLXNwZWNpZmljIG1ldGEgZGF0YSBUTFYgaGFzIGJlZW4g eWV0IGRlZmluZWQuDQoNCkNNUDogV2hhdCBpcyB0aGUg4oCcU0ZDIE11bHRpbGF5ZXIgT0FN4oCd Pw0KQ01QOiBUaGUgTy1iaXQgKHJlYWRpbmcgUkZDIDgzMDApIGRvZXMgbm90IGluZGljYXRlIGlm IHRoZXJlIGlzIE9BTSBNZXRhZGF0YS4gSXQgaW5kaWNhdGVzIGFuIE9BTSBwYWNrZXQuDQoNCg0K IkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20+Pg0KDQpBcyBmYXIgYXMgSSBjYW4gdGVsbCwgaWYgd2UgZGVwcmVjYXRlIHRoZSBP LWJpdCBhbmQgcmVseSBvbiB0aGUgbmV4dCBwcm90b2NvbCBmaWVsZCwgd2UgYXJlIHNheWluZyB0 aGF0IGluIHByYWN0aWNlIChub3QgYnkgcnVsZSkgTlNIIG1ldGFkYXRhIGNhbiBub3QgYmUgdXNl ZCBmb3IgT0FNLiAgVGhhdCdzIGZpbmUgd2l0aCBtZSBhcyBsb25nIGFzIHdlIGFncmVlIG9uIHRo YXQuDQoNCkNNUDogSSBkbyBub3QgZnVsbHkgZm9sbG93IHRoaXMuIENhbiB5b3UgZXhwbGFpbiB0 aGUgcmVsYXRpb25zaGlwIG9mIHRoZSBPLWJpdCB3aXRoIE1ldGFkYXRhPw0KQ01QOiBIZXJl4oCZ cyBhbiBleGFtcGxlOiBSRkMgODkyNCBzaG93cyBJQ01QIGFzIEFjdGl2ZSBPQU0uIFRoZSBTRkMg bmV4dCBwcm90b2NvbCBpcyBJUCwgdGhlIElQIG5leHQgcHJvdG9jb2wgaXMgSUNNUCwgdGhlIE8t Yml0IG5lZWRzIHRvIGJlIHNldC4NCg0KQ01QOiBDb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3Vt ZW50LCBpbmRlcGVuZGVudCBzdWJtaXNzaW9uIGFuZCBpbiB0aGUgUkZDIFB1YmxpY2F0aW9uIHF1 ZXVlIGFscmVhZHk6DQpDTVA6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LW15bWItc2ZjLW5zaC1hbGxvY2F0aW9uLXRpbWVzdGFtcC8NCkNNUDogSXMgYSBUaW1lc3RhbXAg aW4gTWV0YWRhdGEgYW4gT0FNIGVsZW1lbnQ/DQoNCkNNUDogQ29uc2lkZXIgdGhpcyBwcm9wb3Nh bCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktc2ZjLXBtYW1t Lw0KQ01QOiBXaGVyZSB0aGUgYmFzZSBoZWFkZXIgYm9ycm93cyBhIGJpdCBmb3IgYW4gT0FNIGZ1 bmN0aW9uLg0KDQpDTVA6IE5laXRoZXIgb2YgdGhvc2UgaGF2ZSBhbnkgaW1wYWN0IG9uIHRoZSBP LWJpdC4NCg0KDQpHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVn aW1pcnNreUBnbWFpbC5jb20+Pg0KDQpJIGFncmVlIHRoYXQsIGFzIHdlIGZpbmQgU0ZDIE5TSCBu b3csIG5vIE9BTSBtZXRhZGF0YSBoYXMgYmVlbiBkZWZpbmVkLiBJdCBhcHBlYXJzIHRvIG1lIHRo YXQgZGVwcmVjYXRpbmcgdGhlIE8gYml0IGRvZXMgbm90IGFmZmVjdCBhbnkgb2YgdGhlIGFscmVh ZHkgZGVmaW5lZCBtZWNoYW5pc21zIGluIHRoZSBTRkMgTlNILg0KDQpDTVA6IEl0IGFjdHVhbGx5 IGRvZXMsIHNlZSBteSBleGFtcGxlIGFib3ZlLg0KDQpJIHRoaW5rIHRoYXQgaWYgYSBuZXcsIGZv ciBleGFtcGxlLCBNRCBUeXBlID0gMiBUTFYgdGhhdCBpcyB1c2VkIGZvciBhbnkgT0FNIGZ1bmN0 aW9uYWxpdHkgdG8gYmUgcHJvcG9zZWQgaW4gdGhlIGZ1dHVyZSwgZGVwcmVjYXRlZCB0aGUgTyBi aXQgd291bGQgbm90IHByZXZlbnQgdXNpbmcgc3VjaCBOU0ggVExWLg0KDQpDTVA6IEkgYWdyZWUg d2l0aCB0aGlzIOKAlCBiZWNhdXNlIHRoZXJlIGlzIG5vIGNvcnJlbGF0aW9uIGJldHdlZW4gTUQg VHlwZSBmaWVsZCBhbmQgTy1iaXQgYXMgZGVmaW5lZC4NCg0KQmVzdCwNCg0KQ2FybG9zLg0KDQoN Cg0KMi8xMy8yMiDljYjlvowxMjozMuOAgUd5YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFpbC5j b208bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbT4+44Gu44Oh44O844OrOg0KDQpIaSBKb2Vs DQoNCkkgYW0gaW4gYWdyZWVtZW50IGFzIHdlbGwgd2l0aCB3aGF0IHlvdSBoYXZlIHN0YXRlZCB0 aGF0IG9uY2UgdGhlIE8gYml0IGlzIGRlcHJlY2F0ZWQgdGhhdCBOU0ggbWV0YWRhdGEgY2Fubm90 IGJlIHVzZWQgZm9yIE9BTSBhbmQgdGhhdCB3ZSB3b3VsZCBoYXZlIHRvIG5vdyBmcm9tIHRoYXQg cG9pbnQgZm9yd2FyZCByZWx5IG9uIHRoZSBuZXh0IHByb3RvY29sIGZpZWxkIGFzIHdlIHdpbGwg YmUgZG9pbmcgZm9yIFNGQyBNdWx0aWxheWVyIGFuZCBTRkMgSU9BTSBkcmFmdHMgYXMgd2VsbCBh cyB3aWxsIGhhdmUgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBhbnkgYWxyZWFkeSBleGlzdGlu ZyBkZWZpbmVkIG1lY2hhbmlzbXMgaW4gU0ZDIE5TSC4NCg0KSSBkb27igJl0IHNlZSBhbnkgaXNz dWVzIG9yIGltcGFjdCB3aXRoIG1vdmluZyBmb3J3YXJkLg0KDQpLaW5kIFJlZ2FyZHMNCg0KR3lh bg0KDQpPbiBTdW4sIEZlYiAxMywgMjAyMiBhdCAxMjowNCBQTSBHcmVnIE1pcnNreSA8Z3JlZ2lt aXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCkhp IEpvZWwsDQpJIGFncmVlIHRoYXQsIGFzIHdlIGZpbmQgU0ZDIE5TSCBub3csIG5vIE9BTSBtZXRh ZGF0YSBoYXMgYmVlbiBkZWZpbmVkLiBJdCBhcHBlYXJzIHRvIG1lIHRoYXQgZGVwcmVjYXRpbmcg dGhlIE8gYml0IGRvZXMgbm90IGFmZmVjdCBhbnkgb2YgdGhlIGFscmVhZHkgZGVmaW5lZCBtZWNo YW5pc21zIGluIHRoZSBTRkMgTlNILiBJIHRoaW5rIHRoYXQgaWYgYSBuZXcsIGZvciBleGFtcGxl LCBNRCBUeXBlID0gMiBUTFYgdGhhdCBpcyB1c2VkIGZvciBhbnkgT0FNIGZ1bmN0aW9uYWxpdHkg dG8gYmUgcHJvcG9zZWQgaW4gdGhlIGZ1dHVyZSwgZGVwcmVjYXRlZCB0aGUgTyBiaXQgd291bGQg bm90IHByZXZlbnQgdXNpbmcgc3VjaCBOU0ggVExWLg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNClJl Z2FyZHMsDQpHcmVnDQoNCk9uIFN1biwgRmViIDEzLCAyMDIyIGF0IDY6NTUgQU0gSm9lbCBNLiBI YWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4g d3JvdGU6DQpUaGVyZSBpcyBhbiBpbXBsaWNhdGlvbiBvZiBkZXByZWNhdGluZyB0aGUgTy1iaXQg dGhhdCBJIHdvdWxkIGxpa2UgdG8NCmhlYXIgZnJvbSBtb3JlIFdHIHBhcnRpY2lwYW50cyBhYm91 dC4NCg0KQXMgZmFyIGFzIEkgY2FuIHRlbGwsIGlmIHdlIGRlcHJlY2F0ZSB0aGUgTy1iaXQgYW5k IHJlbHkgb24gdGhlIG5leHQNCnByb3RvY29sIGZpZWxkLCB3ZSBhcmUgc2F5aW5nIHRoYXQgaW4g cHJhY3RpY2UgKG5vdCBieSBydWxlKSBOU0gNCm1ldGFkYXRhIGNhbiBub3QgYmUgdXNlZCBmb3Ig T0FNLiAgVGhhdCdzIGZpbmUgd2l0aCBtZSBhcyBsb25nIGFzIHdlDQphZ3JlZSBvbiB0aGF0Lg0K DQpZb3VycywNCkpvZWwNCg0KT24gMi8xMy8yMDIyIDI6NTIgQU0sIEd5YW4gTWlzaHJhIHdyb3Rl Og0KPg0KPiBIaSBKaW0sIEpvZWwgJiBTRkMgV0csDQo+DQo+IEkgYWdyZWUgdGhhdCB0aGUgUkZD IDgzMDAgZGVmaW5pdGlvbiBvZiBPIGJpdCBpcyBpbmNvbXBsZXRlIGFuZCBub3QNCj4gY2xlYXIg YXMgdG8gaXRzIGludGVuZGVkIHVzZS4NCj4NCj4gVGhhdCBpcyBhIHByb2JsZW0gdGhhdCBJIGFn cmVlIG5lZWRzIHRvIGJlIHJlY3RpZmllZC4NCj4NCj4gSSB1bmRlcnN0YW5kIHRoYXQgd2UgbmVl ZCB0byBnZXQgdGhpcyByZXNvbHZlZCBiZWZvcmUgd2UgY2FuIHByb2dyZXNzDQo+IE11bHRpbGF5 ZXIgU0ZDIE9BTSBkcmFmdC1pZXRmLXNmYy1tdWx0aS1sYXllci1vYW0tMTggYW5kIFNGQyBJT0FN Lg0KPg0KPiBJIGFncmVlIHRoYXQgd2hhdCBtYWtlcyBzZW5zZSB0byBtZSBhcyBhIHBhdGggZm9y d2FyZCBpcyB0byBkZXByZWNhdGUNCj4gdGhlIE8gYml0IGFuZCBub3QgdXNlIGluIFNGQyBNdWx0 aWxheWVyIE9BTSBhbmQgU0ZDIElPQU0sIGFzIGJvdGggU0ZDDQo+IE11bHRpbGF5ZXIgT0FNIGFu ZCBTRkMgSU9BTSBhcmUgaWRlbnRpZmllZCBieSB0aGUgcmVzcGVjdGl2ZSB2YWx1ZXMgZm9yDQo+ IHRoZSBOU0ggTmV4dCBQcm90b2NvbCBmaWVsZCAodG8gYmUgYXNzaWduZWQgYnkgSUFOQSksIGFz IHdlbGwgYXMgc28gZmFyDQo+IG5vIE9BTS1zcGVjaWZpYyBtZXRhIGRhdGEgVExWIGhhcyBiZWVu IHlldCBkZWZpbmVkLg0KPg0KPiBTbyB3ZSBoYXZlIEkgYmVsaWV2ZSBzb2xpZCBzb2x1dGlvbiBh bmQgcGF0aCBmb3J3YXJkIGFuZCBJIHN1cHBvcnQNCj4gZGVwcmVjYXRpbmcgdGhlIE8gYml0Lg0K Pg0KPiBLaW5kIFJlZ2FyZHMNCj4NCj4gR3lhbg0KPg0KPiBPbiBXZWQsIEZlYiAyLCAyMDIyIGF0 IDU6NDIgUE0gR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2lt aXJza3lAZ21haWwuY29tPg0KPiA8bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86 Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4+IHdyb3RlOg0KPg0KPiAgICAgVGhhbmsgeW91LCBKaW0g YW5kIEpvZWwsIGZvciBndWlkaW5nIHRoZSBTRkMgT0FNIHdvcmsgYW5kIHBvaW50aW5nDQo+ICAg ICBvdXQgdGhlIGlzc3VlIHRoYXQgbXVzdCBiZSBhZGRyZXNzZWQuDQo+DQo+ICAgICBJJ3ZlIHJl dmlld2VkIG91ciBTRkMgT0FNIGRvY3VtZW50cyBhbmQgZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi4g QXMgSQ0KPiAgICAgdW5kZXJzdGFuZCB0aGVzZSBkb2N1bWVudHMsIHRoZSBBY3RpdmUgU0ZDIE9B TSBhbmQgSU9BTSBhcmUNCj4gICAgIGlkZW50aWZpZWQgYnkgdGhlIHJlc3BlY3RpdmUgdmFsdWVz IGZvciB0aGUgTlNIIE5leHQgUHJvdG9jb2wgZmllbGQNCj4gICAgICh0byBiZSBhc3NpZ25lZCBi eSBJQU5BKS4gQXQgdGhlIHNhbWUgdGltZSwgc28gZmFyIG5vIE9BTS1zcGVjaWZpYw0KPiAgICAg bWV0YSBkYXRhIFRMViBoYXMgYmVlbiBkZWZpbmVkLiBUaHVzLCBpdCBhcHBlYXJzIHRoYXQgb25l IHdheQ0KPiAgICAgZm9yd2FyZCBjb3VsZCBiZSB0byBub3QgaW52b2x2ZSB0aGUgTyBiaXQgaW4g dGhlIGFjdGl2ZSBTRkMgT0FNIG9yDQo+ICAgICBJT0FNIGFsdG9nZXRoZXIuIEluIG90aGVyIHdv cmRzLCB0byBkZXByZWNhdGUgdGhlIE5TSCBPIGJpdC4NCj4NCj4gICAgIEkgZ3JlYXRseSBhcHBy ZWNpYXRlIHlvdXIgY29tbWVudHMgb24gdGhlIHByb3Bvc2FsIHRvIGRlcHJlY2F0ZSB0aGUNCj4g ICAgIE5TSCBPIGJpdC4NCj4NCj4gICAgIFJlZ2FyZHMsDQo+ICAgICBHcmVnDQo+DQo+ICAgICBP biBXZWQsIEZlYiAyLCAyMDIyIGF0IDEwOjM2IEFNIEphbWVzIEd1aWNoYXJkDQo+ICAgICA8amFt ZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVy ZXdlaS5jb20+DQo+ICAgICA8bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTxt YWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPj4+IHdyb3RlOg0KPg0KPiAgICAg ICAgIEhpIFdHOl9fX18NCj4NCj4gICAgICAgICBfXyBfXw0KPg0KPiAgICAgICAgIEhhdmluZyBy ZXZpZXdlZCBhbGwgb2YgdGhlIE9BTSByZWxhdGVkIGRvY3VtZW50cyBpbiBvdXIgV0csIHRoZQ0K PiAgICAgICAgIGNoYWlycyB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgYSBmZXcgY29tbWVudHMgdG8g aG9wZWZ1bGx5DQo+ICAgICAgICAgZ2VuZXJhdGUgZGlzY3Vzc2lvbiBhbmQgZm9yd2FyZCBwcm9n cmVzcyBvZiB0aGlzIHdvcms6X19fXw0KPg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAg MSkgVGhlIGNoYWlycyBoYXZlIHJldmlld2VkIHRoZSBPIGJpdCBkZWZpbml0aW9uIGluIFJGQyA4 MzAwLg0KPiAgICAgICAgIFRoYXQgZGVmaW5pdGlvbiBpcyBhdCBiZXN0IG9wZW4gdG8gaW50ZXJw cmV0YXRpb24gYW5kIHRoZXJlZm9yZQ0KPiAgICAgICAgIGluY29tcGxldGUuICBGb3IgZXhhbXBs ZSwgdGhlIGNsZWFyIGludGVudGlvbiBpcyBvbmx5IHRvIG1hcmsNCj4gICAgICAgICBwYWNrZXRz IHdoaWNoIGFyZSBpbnRlbmRlZCBmb3IgU0ZDIE9BTSBhdCB0aGUgU0ZDIHNlcnZpY2UNCj4gICAg ICAgICBsYXllci4gIEJ1dCB0aGF0IGlzIG5vdCB3aGF0IHRoZSBjdXJyZW50IHRleHQgc2F5cy4g IFRoZXJlIGlzDQo+ICAgICAgICAgYWxzbywgdW5mb3J0dW5hdGVseSwgYW1iaWd1aXR5IGFzIHRv IHdoYXQgY29uc3RpdHV0ZXMgYW4gT0FNDQo+ICAgICAgICAgcGFja2V0LiAgU28gaXQgaXMgcmVh c29uYWJsZSBmb3IgZG9jdW1lbnRzIHRvIHVwZGF0ZSA4MzAwIHRvDQo+ICAgICAgICAgY2xhcmlm eSB0aGUgZXhhY3QgYXBwbGljYWJpbGl0eSBhbmQgYWN0aW9uIGZvciB0aGUgTy1iaXQuX19fXw0K Pg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgMikgSG93ZXZlciwgcmVsYXRlZCB0byBw b2ludCAxKSwgd2UgY2FuJ3QgaGF2ZSBtdWx0aXBsZQ0KPiAgICAgICAgIGRvY3VtZW50cyB1cGRh dGluZyB0aGUgZGVmaW5pdGlvbiBkaWZmZXJlbnRseS4gIEFzIHN1Y2gsIHRoZQ0KPiAgICAgICAg IGF1dGhvcnMgb2YgdGhlIFNGQyBpT0FNIGRyYWZ0IGFuZCB0aGUgU0ZDIG11bHRpLWxheWVyLW9h bSBkcmFmdA0KPiAgICAgICAgIG5lZWQgdG8gY29tZSB0b2dldGhlciBhbmQgZmlndXJlIG91dCB3 aGF0IHRoZSBjbGFyaWZpY2F0aW9uIGlzDQo+ICAgICAgICAgZm9yIHRoZSBkZWZpbml0aW9uIG9m IHRoYXQgYml0LiBXZSBkbyBub3QgYmVsaWV2ZSBhcyBjaGFpcnMgdGhhdA0KPiAgICAgICAgIGVp dGhlciBvZiB0aGVzZSBkb2N1bWVudHMgY2FuIG1vdmUgZm9yd2FyZCBmcm9tIHRoZSBXRyB1bnRp bA0KPiAgICAgICAgIHN1Y2ggY2xhcml0eSBoYXMgYmVlbiByZWFjaGVkLiBfX19fDQo+DQo+ICAg ICAgICAgX18gX18NCj4NCj4gICAgICAgICAzKSBSZWxhdGVkIHRvIHRoZSBTRkMgaU9BTSwgd2Ug bmVlZCBhIGNsZWFyIGRlZmluaXRpb24gb2YgaU9BTS4NCj4gICAgICAgICBUaGVyZSBzZWVtIHRv IGJlIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIGRlZmluaXRpb25zIGluDQo+ICAgICAgICAgcHVi bGlzaGVkIFJGQ3MsIHRoZSB1c2FnZSAod2hpY2ggaXMgbm90IGEgZGVmaW5pdGlvbikgaW4gdGhl IFNGQw0KPiAgICAgICAgIGRyYWZ0LCBhbmQgdGhlIHZhcmlvdXMgaXBwbSBkcmFmdHMuICBBbnkg c3VjaCBkZWZpbml0aW9uIHdpbGwNCj4gICAgICAgICBuZWVkIHRvIGJlIHZldHRlZCB3aXRoIHRo ZSBpcHBtIHdvcmtpbmcgZ3JvdXAuX19fXw0KPg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAg ICAgQWdhaW4sIGl0IHdvdWxkIGJlIGdvb2QgaWYgbWVtYmVycyBvZiB0aGUgd29ya2luZyBncm91 cCBiZXlvbmQNCj4gICAgICAgICB0aGUgdHdvIGF1dGhvciB0ZWFtcyBzcG9rZSB1cCBhYm91dCB0 aGVpciByZWFkaW5ncyBvZiB0aGUNCj4gICAgICAgICBkb2N1bWVudHMsIGFuZCB0aGVpciB1bmRl cnN0YW5kaW5ncyBvZiB3aGF0IHdlIG5lZWQuX19fXw0KPg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ ICAgICAgICAgWW91cnMsX19fXw0KPg0KPiAgICAgICAgIEppbSBhbmQgSm9lbF9fX18NCj4NCj4g ICAgICAgICBfXyBfXw0KPg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgX18gX18NCj4N Cj4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiAgICAgICAgIHNmYyBtYWlsaW5nIGxpc3QNCj4gICAgICAgICBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4gPG1haWx0bzpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9y Zz4+DQo+ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4gICAgICAgICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM+DQo+ DQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiAgICAgc2ZjIG1haWxpbmcgbGlzdA0KPiAgICAgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0 Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KPiAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gICAgIDxodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYz4NCj4NCj4gLS0NCj4NCj4gPGh0dHA6 Ly93d3cudmVyaXpvbi5jb20vPg0KPg0KPiAqR3lhbiBNaXNocmEqDQo+DQo+IC9OZXR3b3JrIFNv bHV0aW9ucyBBLy9yY2hpdGVjdCAvDQo+DQo+IC9FbWFpbCBneWFuLnMubWlzaHJhQHZlcml6b24u Y29tPG1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tPiA8bWFpbHRvOmd5YW4ucy5taXNo cmFAdmVyaXpvbi5jb208bWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20+Pi8vDQo+IC8N Cj4NCj4gL00gMzAxIDUwMi0xMzQ3DQo+DQo+IC8NCj4NCj4NCi0tDQoNCltodHRwOi8vc3M3LnZ6 dy5jb20vaXMvaW1hZ2UvVmVyaXpvbldpcmVsZXNzL3Z6LWxvZ28tZW1haWxdPGh0dHA6Ly93d3cu dmVyaXpvbi5jb20vPg0KDQpHeWFuIE1pc2hyYQ0KTmV0d29yayBTb2x1dGlvbnMgQXJjaGl0ZWN0 DQpFbWFpbCBneWFuLnMubWlzaHJhQHZlcml6b24uY29tPG1haWx0bzpneWFuLnMubWlzaHJhQHZl cml6b24uY29tPg0KTSAzMDEgNTAyLTEzNDcNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KDQo= --_000_3CDEE7495A4044FF9E3A8C8EBBA94849ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClJlcGx5aW5nIHRvIHRoaXMgc3BlY2lmaWMgZW1h aWwgaW4gdGhlIHRocmVhZCwgb25seSBiZWNhdXNlIGl0IGlzIHRoZSBsYXRlc3Qgb25lIGF0IHRo aXMgcG9pbnQgaW4gdGltZSwgYnV0IGJ1bmRsaW5nIGNvbW1lbnRzIGZyb20gdmFyaW91cyBwbGFj ZXMgb24gdGhlIHRocmVhZC4gUGxlYXNlIGZpbmQgc29tZSBmb2xsb3ctdXAgY29tbWVudHMgYW5k IHF1ZXN0aW9ucyBtYXJrZWQg4oCcQ01Q4oCdLCBpbmRpY2F0aW5nIHRoZSDigJxGcm9t4oCdLCBh bmQgb3JnYW5pemVkDQogY2hyb25vbG9naWNhbGx5Og0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+SmFtZXMgTiBHdWljaGFyZCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbSIgY2xhc3M9 IiI+amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPC9hPiZndDs6PC9iPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQoxKSBUaGUgY2hhaXJzIGhhdmUgcmV2aWV3ZWQgdGhlIE8gYml0IGRlZmluaXRpb24gaW4gUkZD IDgzMDAuJm5ic3A7IFRoYXQgZGVmaW5pdGlvbiBpcyBhdCBiZXN0IG9wZW4gdG8gaW50ZXJwcmV0 YXRpb24gYW5kIHRoZXJlZm9yZSBpbmNvbXBsZXRlLiZuYnNwOyBGb3IgZXhhbXBsZSwgdGhlIGNs ZWFyIGludGVudGlvbiBpcyBvbmx5IHRvIG1hcmsgcGFja2V0cyB3aGljaCBhcmUgaW50ZW5kZWQg Zm9yIFNGQyBPQU0gYXQgdGhlIFNGQyBzZXJ2aWNlIGxheWVyLiZuYnNwOyBCdXQNCiB0aGF0IGlz IG5vdCB3aGF0IHRoZSBjdXJyZW50IHRleHQgc2F5cy4mbmJzcDsgVGhlcmUgaXMgYWxzbywgdW5m b3J0dW5hdGVseSwgYW1iaWd1aXR5IGFzIHRvIHdoYXQgY29uc3RpdHV0ZXMgYW4gT0FNIHBhY2tl dC4mbmJzcDsgU28gaXQgaXMgcmVhc29uYWJsZSBmb3IgZG9jdW1lbnRzIHRvIHVwZGF0ZSA4MzAw IHRvIGNsYXJpZnkgdGhlIGV4YWN0IGFwcGxpY2FiaWxpdHkgYW5kIGFjdGlvbiBmb3IgdGhlIE8t Yml0LjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q01QOiBJdCBpcyB1bmNsZWFyIHRvIG1lIHdoYXQgZXhhY3Qg aXNzdWVzIHRoZSBjaGFpcnMgYXJlIGNhbGxpbmcgb3V0LiBUaGVyZSBhcmUgdHdvIGlzc3VlcyBt ZW50aW9uZWQ6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNNUDogMS4gJnF1b3Q7QnV0IHRoYXQgaXMg bm90IHdoYXQgdGhlIGN1cnJlbnQgdGV4dCBzYXlzLuKAnSDigJQmZ3Q7IHdoYXQgZG9lcyB0aGUg dGV4dCBzYXkgcHJlY2lzZWx5PyAmbmJzcDtDYW4geW91IHBvaW50IHRvIHRoZSBzcGVjaWZpYyBS RkMgODMwMCB0ZXh0IHRoYXQgaXMgYmVsaWV2ZWQgdG8gYmUgaW5jb21wbGV0ZSwgYW5kIGEgZGV0 YWlsZWQgdXNlIGNhc2UgdGhhdCBzaG93Y2FzZXMgdGhlIHBvdGVudGlhbCBpc3N1ZT8gQW4gZXh0 cmFwb2xhdGVkDQogY291bnRlci1leGFtcGxlIGp1c3QgdG8gbWFrZSBhIHBvaW50OiB0aGUgdGV4 dCBkb2VzIG5vdCAmbmJzcDtzYXkgd2hhdCBkYXlzIG9mIHRoZSB3ZWVrIE9BTSBwYWNrZXRzIGNh biBiZSBtYXJrZWQsIHlldCB0aGVyZeKAmXMgYW4gZXhwZWN0YXRpb24gdGhhdCB0aGV5IHdpbGwg d29yayBNb25kYXlzIGFuZCBTYXR1cmRheXMgYWxsIHRoZSBzYW1lIOKAlCBldmVuIGhvbGlkYXlz LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DTVA6IDIuIFdoYXQgc3BlY2lmaWNhbGx5IGlzIHRoZSBh bWJpZ3VpdHkgd2l0aCB3aGF0IGFuIE9BTSBwYWNrZXQgaXM/IFBsZWFzZSBncmVwIHRoZSBSRkMg c2VyaWVzIGZvciDigJxvYW0gcGFja2V04oCdLCBpdCBpcyBub3QgYSBuZXcgdGVybS4mbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q01QOiBOZXQtbmV0LCBPLWJpdD0xLCBPQU0gcGFja2V0LiZu YnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQoyKSBIb3dldmVyLCByZWxhdGVkIHRvIHBvaW50IDEpLCB3ZSBjYW4n dCBoYXZlIG11bHRpcGxlIGRvY3VtZW50cyB1cGRhdGluZyB0aGUgZGVmaW5pdGlvbiBkaWZmZXJl bnRseS4mbmJzcDsgQXMgc3VjaCwgdGhlIGF1dGhvcnMgb2YgdGhlIFNGQyBpT0FNIGRyYWZ0IGFu ZCB0aGUgU0ZDIG11bHRpLWxheWVyLW9hbSBkcmFmdCBuZWVkIHRvIGNvbWUgdG9nZXRoZXIgYW5k IGZpZ3VyZSBvdXQgd2hhdCB0aGUgY2xhcmlmaWNhdGlvbiBpcyBmb3IgdGhlIGRlZmluaXRpb24N CiBvZiB0aGF0IGJpdC4gV2UgZG8gbm90IGJlbGlldmUgYXMgY2hhaXJzIHRoYXQgZWl0aGVyIG9m IHRoZXNlIGRvY3VtZW50cyBjYW4gbW92ZSBmb3J3YXJkIGZyb20gdGhlIFdHIHVudGlsIHN1Y2gg Y2xhcml0eSBoYXMgYmVlbiByZWFjaGVkLjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DTVA6IElm IHRoZXJlIGlzIHN0aWxsIGJlbGlldmVkIHRvIGJlIGFuIGFtYmlndWl0eSBvciBhIGNsZWFyIG9w cG9ydHVuaXR5IGZvciBpbXByb3ZpbmcgdGhlIGRlZmluaXRpb24sIEkgYWdyZWUgd2l0aCBjb25z b2xpZGF0aW5nIHRoYXQgdXBkYXRlLiBJIGhhZCBzdWdnZXN0ZWQgYmVmb3JlIHRoYXQgaWYgc3Vj aCBuZXcgdGV4dCBvciByZWFsIGNsYXJpZmljYXRpb24gaXMgYWdyZWVkLCBhIHNlcGFyYXRlIGRv Y3VtZW50IHRoYXQNCiBvbmx5IG1ha2VzIHRoYXQgTy1iaXQgY2xhcmlmaWNhdGlvbiBpcyB0aGUg bW9zdCBjbGVhciBhbmQgY2xlYW4gd2F5IHRvIGdvLiBUaGF0IGRvYyBzaG91bGQgYmUgYSBvbmUt cGFnZXIgb3IgbGVzcy4gSeKAmWQgYmUgaGFwcHkgdG8gY29udHJpYnV0ZSB0byB0aGF0IG1pbmlt YWwgZG9jLCBpZiBpdCBpcyBzaG93biB0byBiZSBuZWVkZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DTVA6IEZvciBjb21wbGV0ZW5l c3MgYWxzbywgdGhlICZxdW90O1NGQyBtdWx0aS1sYXllci1vYW3igJ0gZG9jdW1lbnQgaGFzIG1h bnkgb3V0c3RhbmRpbmcgaXNzdWVzIGJlc2lkZXMgdGhlIE8tYml0LjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+R3Jl ZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIGNsYXNz PSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7PC9iPjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj5JJ3ZlIHJldmlld2VkIG91ciBTRkMgT0FNIGRvY3VtZW50cyBhbmQg ZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi4gQXMgSSB1bmRlcnN0YW5kIHRoZXNlIGRvY3VtZW50cywg dGhlIEFjdGl2ZSBTRkMgT0FNIGFuZCBJT0FNIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSByZXNwZWN0 aXZlIHZhbHVlcyBmb3IgdGhlIE5TSCBOZXh0IFByb3RvY29sIGZpZWxkICh0byBiZSBhc3NpZ25l ZCBieSBJQU5BKS4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNNUDogVGhlcmUgaXMgYSBtYWpvciBpc3N1ZSB3aXRoIHRo ZSBzZW50ZW5jZSBhYm92ZS4gQWN0aXZlIFNGQyBPQU0gKGFzIGEgY2F0ZWdvcnkpLCBhcyBwZXIg UkZDIDgzMDAsIG5lZWRzIHRvIGJlIGlkZW50aWZpZWQgYnkgc2V0dGluZyB0aGUgTy1iaXQuIE5v IHdheSBhcm91bmQgdGhhdCBiYXNlZCBvbiBSRkMgODMwMC4gSG93ZXZlciwgdGhlIHRleHQgJnF1 b3Q7dGhlIEFjdGl2ZSBTRkMgT0FN4oCdIGNyZWF0ZXMgY29uZnVzaW9uIHNpbmNlDQogaXQgcmVm ZXIgdG8gYSBzcGVjaWZpYyBPQU0gcHJvdG9jb2wgd2hpY2ggaGFzIHRoZSBzYW1lIG5hbWUgYXMg YSB0aGUgY2F0ZWdvcnkgYXMgd2VsbC4gVGhhdCBuYW1lIGNvbGxpc2lvbiBpcyBxdWl0ZSB1bmZv cnR1bmF0ZSBpbiBteSBvcGluaW9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkF0IHRoZSBzYW1lIHRp bWUsIHNvIGZhciBubyBPQU0tc3BlY2lmaWMgbWV0YSBkYXRhIFRMViBoYXMgYmVlbiBkZWZpbmVk LiBUaHVzLCBpdCBhcHBlYXJzIHRoYXQgb25lIHdheSBmb3J3YXJkIGNvdWxkIGJlIHRvIG5vdCBp bnZvbHZlIHRoZSBPIGJpdCBpbiB0aGUgYWN0aXZlIFNGQyBPQU0gb3IgSU9BTSBhbHRvZ2V0aGVy LiBJbiBvdGhlciB3b3JkcywgdG8gZGVwcmVjYXRlIHRoZSBOU0gNCiBPIGJpdC48L2Jsb2NrcXVv dGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KQ01QOiBSRkMgODkyNCBh bHJlYWR5IGluY2x1ZGVzIElDTVAgYW5kIEJGRCBhcyBleGFtcGxlIFNGQyBBY3Rpb24gT0FNIHBy b3RvY29scy4gVGhvc2UgY2FuIGJlIGVuY2Fwc3VsYXRlZCBpbiBJUCwgaW4gd2hpY2ggdGhlIE5l eHQtUHJvdG9jb2wgaW5kaWNhdGVzIElQIOKAlCBhbmQgKGFzIHBlciBSRkMgODMwMCkgdGhlIE8t Yml0IGlzIHNldCB0byBpbmRpY2F0ZSBhbiBPQU0gcGFja2V0LjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5DTVA6IFRoZSBwcm9wb3NhbCBvZiBkZXByZWNhdGluZyB0aGUgTy1iaXQgYnJlYWtzIHRob3Nl IFNGQyBPQU0gcHJvdG9jb2xzIGFscmVhZHkgaW5jbHVkZWQgaW4gYW4gUkZDLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5DTVA6IFRoYXQgcHJvcG9zYWwgb2YgZGVwcmVjYXRpbmcgdGhlIE8tYml0IGFs c28gYnJlYWtzIFNlY3Rpb24gNC4xIG9mIElPQU0uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNNUDog VGhpcyBleHBpcmVkIEktRCB5ZXQgaW1wbGVtZW50ZWQgaW4gb3BlbiBzb3VyY2UgdXNlcyB0aGUg Ty1iaXQ6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFm dC1wZW5uby1zZmMtdHJhY2UtMDMudHh0IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9h cmNoaXZlL2lkL2RyYWZ0LXBlbm5vLXNmYy10cmFjZS0wMy50eHQ8L2E+Jm5ic3A7PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+R3lhbiBNaXNocmEgJmx0 OzxhIGhyZWY9Im1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20iIGNsYXNzPSIiPmhheWFidXNh Z3NtQGdtYWlsLmNvbTwvYT4mZ3Q7PC9iPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj5JIGFncmVlIHRoYXQgd2hhdCBtYWtlcyBz ZW5zZSB0byBtZSBhcyBhIHBhdGggZm9yd2FyZCBpcyB0byBkZXByZWNhdGUgdGhlIE8gYml0IGFu ZCBub3QgdXNlIGluIFNGQyBNdWx0aWxheWVyIE9BTSBhbmQgU0ZDIElPQU0sIGFzIGJvdGggU0ZD IE11bHRpbGF5ZXImbmJzcDtPQU0gYW5kIFNGQyZuYnNwO0lPQU0gYXJlIGlkZW50aWZpZWQgYnkg dGhlIHJlc3BlY3RpdmUgdmFsdWVzIGZvciB0aGUgTlNIIE5leHQgUHJvdG9jb2wNCiBmaWVsZCAo dG8gYmUgYXNzaWduZWQgYnkgSUFOQSksIGFzIHdlbGwgYXMgc28gZmFyIG5vIE9BTS1zcGVjaWZp YyBtZXRhIGRhdGEgVExWIGhhcyBiZWVuIHlldCBkZWZpbmVkLjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5DTVA6IFdoYXQgaXMgdGhlIOKAnFNGQyBNdWx0aWxheWVyIE9BTeKAnT88L2Rpdj4NCjxk aXYgY2xhc3M9IiI+Q01QOiBUaGUgTy1iaXQgKHJlYWRpbmcgUkZDIDgzMDApIGRvZXMgbm90IGlu ZGljYXRlIGlmIHRoZXJlIGlzIE9BTSBNZXRhZGF0YS4gSXQgaW5kaWNhdGVzIGFuIE9BTSBwYWNr ZXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+JnF1 b3Q7Sm9lbCBNLiBIYWxwZXJuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbSIgY2xhc3M9IiI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PC9iPjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5BcyBmYXIgYXMgSSBjYW4gdGVsbCwgaWYgd2Ug ZGVwcmVjYXRlIHRoZSBPLWJpdCBhbmQgcmVseSBvbiB0aGUgbmV4dCBwcm90b2NvbCBmaWVsZCwg d2UgYXJlIHNheWluZyB0aGF0IGluIHByYWN0aWNlIChub3QgYnkgcnVsZSkgTlNIIG1ldGFkYXRh IGNhbiBub3QgYmUgdXNlZCBmb3IgT0FNLiAmbmJzcDtUaGF0J3MgZmluZSB3aXRoIG1lIGFzIGxv bmcgYXMgd2UgYWdyZWUgb24gdGhhdC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5DTVA6IEkgZG8gbm90IGZ1bGx5IGZvbGxvdyB0 aGlzLiBDYW4geW91IGV4cGxhaW4gdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGUgTy1iaXQgd2l0aCBN ZXRhZGF0YT88L2Rpdj4NCjxkaXY+Q01QOiBIZXJl4oCZcyBhbiBleGFtcGxlOiBSRkMgODkyNCBz aG93cyBJQ01QIGFzIEFjdGl2ZSBPQU0uIFRoZSBTRkMgbmV4dCBwcm90b2NvbCBpcyBJUCwgdGhl IElQIG5leHQgcHJvdG9jb2wgaXMgSUNNUCwgdGhlIE8tYml0IG5lZWRzIHRvIGJlIHNldC4mbmJz cDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkNNUDogQ29uc2lkZXIg dGhlIGZvbGxvd2luZyBkb2N1bWVudCwgaW5kZXBlbmRlbnQgc3VibWlzc2lvbiBhbmQgaW4gdGhl IFJGQyBQdWJsaWNhdGlvbiBxdWV1ZSBhbHJlYWR5OjwvZGl2Pg0KPGRpdj5DTVA6Jm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbXltYi1zZmMtbnNo LWFsbG9jYXRpb24tdGltZXN0YW1wLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbXltYi1zZmMtbnNoLWFsbG9jYXRpb24tdGltZXN0YW1wLzwvYT48L2Rp dj4NCjxkaXY+Q01QOiBJcyBhIFRpbWVzdGFtcCBpbiBNZXRhZGF0YSBhbiBPQU0gZWxlbWVudD8m bmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkNNUDogQ29uc2lk ZXIgdGhpcyBwcm9wb3NhbCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LW1pcnNreS1zZmMtcG1hbW0vIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktc2ZjLXBtYW1tLzwvYT48L2Rpdj4NCjxkaXY+ Q01QOiBXaGVyZSB0aGUgYmFzZSBoZWFkZXIgYm9ycm93cyBhIGJpdCBmb3IgYW4gT0FNIGZ1bmN0 aW9uLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Q01QOiBOZWl0aGVy IG9mIHRob3NlIGhhdmUgYW55IGltcGFjdCBvbiB0aGUgTy1iaXQuJm5ic3A7PC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ PGIgY2xhc3M9IiI+R3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBn bWFpbC5jb20iIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7PC9iPjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj5JIGFncmVlIHRoYXQsIGFzIHdlIGZpbmQgU0ZDIE5TSCBub3csIG5vIE9B TSBtZXRhZGF0YSBoYXMgYmVlbiBkZWZpbmVkLiBJdCBhcHBlYXJzIHRvIG1lIHRoYXQgZGVwcmVj YXRpbmcgdGhlIE8gYml0IGRvZXMgbm90IGFmZmVjdCBhbnkgb2YgdGhlJm5ic3A7YWxyZWFkeSBk ZWZpbmVkIG1lY2hhbmlzbXMgaW4gdGhlJm5ic3A7U0ZDIE5TSC48L2Jsb2NrcXVvdGU+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5DTVA6IEl0IGFjdHVhbGx5IGRvZXMsIHNlZSBt eSBleGFtcGxlIGFib3ZlLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+SSB0aGluayB0aGF0IGlmIGEgbmV3LCBmb3IgZXhhbXBsZSwgTUQgVHlw ZSA9IDIgVExWIHRoYXQmbmJzcDtpcyB1c2VkIGZvciBhbnkgT0FNIGZ1bmN0aW9uYWxpdHkgdG8g YmUgcHJvcG9zZWQgaW4gdGhlIGZ1dHVyZSwgZGVwcmVjYXRlZCB0aGUgTyBiaXQgd291bGQmbmJz cDtub3QgcHJldmVudCB1c2luZyBzdWNoIE5TSCBUTFYuPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5DTVA6IEkgYWdyZWUgd2l0aCB0aGlzIOKA lCBiZWNhdXNlIHRoZXJlIGlzIG5vIGNvcnJlbGF0aW9uIGJldHdlZW4gTUQgVHlwZSBmaWVsZCBh bmQgTy1iaXQgYXMgZGVmaW5lZC48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PkJlc3QsPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5DYXJsb3Mu PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPjIvMTMvMjIg5Y2I5b6MMTI6MzLjgIFHeWFuIE1pc2hyYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbSIgY2xhc3M9IiI+aGF5YWJ1c2Fn c21AZ21haWwuY29tPC9hPiZndDvjga7jg6Hjg7zjg6s6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxl LWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBj bGFzcz0iIj5IaSBKb2VsPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+SSBhbSBpbiBhZ3JlZW1lbnQg YXMgd2VsbCB3aXRoIHdoYXQgeW91IGhhdmUgc3RhdGVkIHRoYXQgb25jZSB0aGUgTyBiaXQgaXMg ZGVwcmVjYXRlZCB0aGF0IE5TSCBtZXRhZGF0YSBjYW5ub3QgYmUgdXNlZCBmb3IgT0FNIGFuZCB0 aGF0IHdlIHdvdWxkIGhhdmUgdG8gbm93IGZyb20gdGhhdCBwb2ludCBmb3J3YXJkIHJlbHkgb24g dGhlIG5leHQgcHJvdG9jb2wgZmllbGQgYXMgd2Ugd2lsbCBiZSBkb2luZw0KIGZvciBTRkMgTXVs dGlsYXllciBhbmQgU0ZDIElPQU0gZHJhZnRzIGFzIHdlbGwgYXMgd2lsbCBoYXZlIGJhY2t3YXJk cyBjb21wYXRpYmxlIHdpdGggYW55IGFscmVhZHkgZXhpc3RpbmcgZGVmaW5lZCBtZWNoYW5pc21z IGluIFNGQyBOU0guICZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iIGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iIGNsYXNzPSIiPkkgZG9u4oCZdCBzZWUg YW55IGlzc3VlcyBvciBpbXBhY3Qgd2l0aCBtb3ZpbmcgZm9yd2FyZC48L2Rpdj4NCjxkaXYgZGly PSJhdXRvIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIiBj bGFzcz0iIj5LaW5kIFJlZ2FyZHMmbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj5HeWFuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBTdW4sIEZlYiAxMywgMjAy MiBhdCAxMjowNCBQTSBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5 QGdtYWlsLmNvbSIgY2xhc3M9IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xh c3M9IiI+SGkgSm9lbCwNCjxkaXYgY2xhc3M9IiI+SSBhZ3JlZSB0aGF0LCBhcyB3ZSBmaW5kIFNG QyBOU0ggbm93LCBubyBPQU0gbWV0YWRhdGEgaGFzIGJlZW4gZGVmaW5lZC4gSXQgYXBwZWFycyB0 byBtZSB0aGF0IGRlcHJlY2F0aW5nIHRoZSBPIGJpdCBkb2VzIG5vdCBhZmZlY3QgYW55IG9mIHRo ZSZuYnNwO2FscmVhZHkgZGVmaW5lZCBtZWNoYW5pc21zIGluIHRoZSZuYnNwO1NGQyBOU0guIEkg dGhpbmsgdGhhdCBpZiBhIG5ldywgZm9yIGV4YW1wbGUsIE1EIFR5cGUgPSAyIFRMViB0aGF0Jm5i c3A7aXMNCiB1c2VkIGZvciBhbnkgT0FNIGZ1bmN0aW9uYWxpdHkgdG8gYmUgcHJvcG9zZWQgaW4g dGhlIGZ1dHVyZSwgZGVwcmVjYXRlZCB0aGUgTyBiaXQgd291bGQmbmJzcDtub3QgcHJldmVudCB1 c2luZyBzdWNoIE5TSCBUTFYuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldoYXQgZG8geW91IHRoaW5r PzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+R3JlZzwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBTdW4sIEZl YiAxMywgMjAyMiBhdCA2OjU1IEFNIEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5qbWhAam9lbGhh bHBlcm4uY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQpU aGVyZSBpcyBhbiBpbXBsaWNhdGlvbiBvZiBkZXByZWNhdGluZyB0aGUgTy1iaXQgdGhhdCBJIHdv dWxkIGxpa2UgdG8gPGJyIGNsYXNzPSIiPg0KaGVhciBmcm9tIG1vcmUgV0cgcGFydGljaXBhbnRz IGFib3V0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFzIGZhciBhcyBJIGNhbiB0ZWxs LCBpZiB3ZSBkZXByZWNhdGUgdGhlIE8tYml0IGFuZCByZWx5IG9uIHRoZSBuZXh0IDxiciBjbGFz cz0iIj4NCnByb3RvY29sIGZpZWxkLCB3ZSBhcmUgc2F5aW5nIHRoYXQgaW4gcHJhY3RpY2UgKG5v dCBieSBydWxlKSBOU0ggPGJyIGNsYXNzPSIiPg0KbWV0YWRhdGEgY2FuIG5vdCBiZSB1c2VkIGZv ciBPQU0uJm5ic3A7IFRoYXQncyBmaW5lIHdpdGggbWUgYXMgbG9uZyBhcyB3ZSA8YnIgY2xhc3M9 IiI+DQphZ3JlZSBvbiB0aGF0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCllvdXJzLDxi ciBjbGFzcz0iIj4NCkpvZWw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiAyLzEzLzIw MjIgMjo1MiBBTSwgR3lhbiBNaXNocmEgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xh c3M9IiI+DQomZ3Q7IEhpIEppbSwgSm9lbCAmYW1wOyBTRkMgV0csPGJyIGNsYXNzPSIiPg0KJmd0 OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IEkgYWdyZWUgdGhhdCB0aGUgUkZDIDgzMDAgZGVmaW5pdGlv biBvZiBPIGJpdCBpcyBpbmNvbXBsZXRlIGFuZCBub3QgPGJyIGNsYXNzPSIiPg0KJmd0OyBjbGVh ciBhcyB0byBpdHMgaW50ZW5kZWQgdXNlLjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIi Pg0KJmd0OyBUaGF0IGlzIGEgcHJvYmxlbSB0aGF0IEkgYWdyZWUgbmVlZHMgdG8gYmUgcmVjdGlm aWVkLjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBJIHVuZGVyc3RhbmQg dGhhdCB3ZSBuZWVkIHRvIGdldCB0aGlzIHJlc29sdmVkIGJlZm9yZSB3ZSBjYW4gcHJvZ3Jlc3Mg PGJyIGNsYXNzPSIiPg0KJmd0OyBNdWx0aWxheWVyIFNGQyBPQU0gZHJhZnQtaWV0Zi1zZmMtbXVs dGktbGF5ZXItb2FtLTE4IGFuZCBTRkMgSU9BTS48YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFz cz0iIj4NCiZndDsgSSBhZ3JlZSB0aGF0IHdoYXQgbWFrZXMgc2Vuc2UgdG8gbWUgYXMgYSBwYXRo IGZvcndhcmQgaXMgdG8gZGVwcmVjYXRlIDxiciBjbGFzcz0iIj4NCiZndDsgdGhlIE8gYml0IGFu ZCBub3QgdXNlIGluIFNGQyBNdWx0aWxheWVyIE9BTSBhbmQgU0ZDIElPQU0sIGFzIGJvdGggU0ZD IDxiciBjbGFzcz0iIj4NCiZndDsgTXVsdGlsYXllciBPQU0gYW5kIFNGQyBJT0FNIGFyZSBpZGVu dGlmaWVkIGJ5IHRoZSByZXNwZWN0aXZlIHZhbHVlcyBmb3IgPGJyIGNsYXNzPSIiPg0KJmd0OyB0 aGUgTlNIIE5leHQgUHJvdG9jb2wgZmllbGQgKHRvIGJlIGFzc2lnbmVkIGJ5IElBTkEpLCBhcyB3 ZWxsIGFzIHNvIGZhciA8YnIgY2xhc3M9IiI+DQomZ3Q7IG5vIE9BTS1zcGVjaWZpYyBtZXRhIGRh dGEgVExWIGhhcyBiZWVuIHlldCBkZWZpbmVkLjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNz PSIiPg0KJmd0OyBTbyB3ZSBoYXZlIEkgYmVsaWV2ZSBzb2xpZCBzb2x1dGlvbiBhbmQgcGF0aCBm b3J3YXJkIGFuZCBJIHN1cHBvcnQgPGJyIGNsYXNzPSIiPg0KJmd0OyBkZXByZWNhdGluZyB0aGUg TyBiaXQuPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IEtpbmQgUmVnYXJk czxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBHeWFuPGJyIGNsYXNzPSIi Pg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IE9uIFdlZCwgRmViIDIsIDIwMjIgYXQgNTo0MiBQ TSBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4NCjxiciBj bGFzcz0iIj4NCiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9h PiZndDsmZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7VGhhbmsgeW91LCBKaW0gYW5kIEpvZWwsIGZvciBndWlkaW5nIHRo ZSBTRkMgT0FNIHdvcmsgYW5kIHBvaW50aW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7b3V0IHRoZSBpc3N1ZSB0aGF0IG11c3QgYmUgYWRkcmVzc2VkLjxiciBjbGFzcz0i Ij4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7SSd2ZSByZXZp ZXdlZCBvdXIgU0ZDIE9BTSBkb2N1bWVudHMgYW5kIGRyYWZ0LWlldGYtc2ZjLW5zaC10bHYuIEFz IEk8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt1bmRlcnN0YW5kIHRoZXNl IGRvY3VtZW50cywgdGhlIEFjdGl2ZSBTRkMgT0FNIGFuZCBJT0FNIGFyZTxiciBjbGFzcz0iIj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2lkZW50aWZpZWQgYnkgdGhlIHJlc3BlY3RpdmUgdmFs dWVzIGZvciB0aGUgTlNIIE5leHQgUHJvdG9jb2wgZmllbGQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsodG8gYmUgYXNzaWduZWQgYnkgSUFOQSkuIEF0IHRoZSBzYW1lIHRp bWUsIHNvIGZhciBubyBPQU0tc3BlY2lmaWM8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDttZXRhIGRhdGEgVExWIGhhcyBiZWVuIGRlZmluZWQuIFRodXMsIGl0IGFwcGVhcnMg dGhhdCBvbmUgd2F5PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9yd2Fy ZCBjb3VsZCBiZSB0byBub3QgaW52b2x2ZSB0aGUgTyBiaXQgaW4gdGhlIGFjdGl2ZSBTRkMgT0FN IG9yPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7SU9BTSBhbHRvZ2V0aGVy LiBJbiBvdGhlciB3b3JkcywgdG8gZGVwcmVjYXRlIHRoZSBOU0ggTyBiaXQuPGJyIGNsYXNzPSIi Pg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtJIGdyZWF0bHkg YXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzIG9uIHRoZSBwcm9wb3NhbCB0byBkZXByZWNhdGUgdGhl PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7TlNIIE8gYml0LjxiciBjbGFz cz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7UmVnYXJk cyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtHcmVnPGJyIGNsYXNzPSIi Pg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtPbiBXZWQsIEZl YiAyLCAyMDIyIGF0IDEwOjM2IEFNIEphbWVzIEd1aWNoYXJkPGJyIGNsYXNzPSIiPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1 dHVyZXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5qYW1lcy5uLmd1aWNoYXJkQGZ1 dHVyZXdlaS5jb208L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPC9h PiZndDsmZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtIaSBXRzpfX19fPGJyIGNsYXNzPSIiPg0K Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O19fIF9fPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0hhdmluZyByZXZpZXdlZCBhbGwgb2YgdGhlIE9BTSByZWxh dGVkIGRvY3VtZW50cyBpbiBvdXIgV0csIHRoZTxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2hhaXJzIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBhIGZl dyBjb21tZW50cyB0byBob3BlZnVsbHk8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2dlbmVyYXRlIGRpc2N1c3Npb24gYW5kIGZvcndhcmQgcHJvZ3Jl c3Mgb2YgdGhpcyB3b3JrOl9fX188YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18gX188YnIgY2xhc3M9IiI+DQom Z3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 MSkgVGhlIGNoYWlycyBoYXZlIHJldmlld2VkIHRoZSBPIGJpdCBkZWZpbml0aW9uIGluIFJGQyA4 MzAwLiA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O1RoYXQgZGVmaW5pdGlvbiBpcyBhdCBiZXN0IG9wZW4gdG8gaW50ZXJwcmV0YXRpb24gYW5kIHRo ZXJlZm9yZTxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7aW5jb21wbGV0ZS4mbmJzcDsgRm9yIGV4YW1wbGUsIHRoZSBjbGVhciBpbnRlbnRpb24gaXMg b25seSB0byBtYXJrPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtwYWNrZXRzIHdoaWNoIGFyZSBpbnRlbmRlZCBmb3IgU0ZDIE9BTSBhdCB0aGUgU0ZD IHNlcnZpY2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2xheWVyLiZuYnNwOyBCdXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgY3VycmVudCB0ZXh0IHNh eXMuJm5ic3A7IFRoZXJlIGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDthbHNvLCB1bmZvcnR1bmF0ZWx5LCBhbWJpZ3VpdHkgYXMgdG8gd2hhdCBj b25zdGl0dXRlcyBhbiBPQU08YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3BhY2tldC4mbmJzcDsgU28gaXQgaXMgcmVhc29uYWJsZSBmb3IgZG9jdW1l bnRzIHRvIHVwZGF0ZSA4MzAwIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtjbGFyaWZ5IHRoZSBleGFjdCBhcHBsaWNhYmlsaXR5IGFuZCBhY3Rp b24gZm9yIHRoZSBPLWJpdC5fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyIGNsYXNzPSIiPg0K Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzIpIEhvd2V2ZXIsIHJlbGF0ZWQgdG8gcG9pbnQgMSksIHdlIGNhbid0IGhhdmUgbXVsdGlwbGU8 YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RvY3Vt ZW50cyB1cGRhdGluZyB0aGUgZGVmaW5pdGlvbiBkaWZmZXJlbnRseS4mbmJzcDsgQXMgc3VjaCwg dGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDth dXRob3JzIG9mIHRoZSBTRkMgaU9BTSBkcmFmdCBhbmQgdGhlIFNGQyBtdWx0aS1sYXllci1vYW0g ZHJhZnQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O25lZWQgdG8gY29tZSB0b2dldGhlciBhbmQgZmlndXJlIG91dCB3aGF0IHRoZSBjbGFyaWZpY2F0 aW9uIGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtmb3IgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBiaXQuIFdlIGRvIG5vdCBiZWxpZXZlIGFzIGNo YWlycyB0aGF0PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtlaXRoZXIgb2YgdGhlc2UgZG9jdW1lbnRzIGNhbiBtb3ZlIGZvcndhcmQgZnJvbSB0aGUg V0cgdW50aWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3N1Y2ggY2xhcml0eSBoYXMgYmVlbiByZWFjaGVkLiBfX19fPGJyIGNsYXNzPSIiPg0KJmd0 OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19f IF9fPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzMpIFJlbGF0ZWQgdG8gdGhlIFNGQyBpT0FNLCB3ZSBuZWVkIGEg Y2xlYXIgZGVmaW5pdGlvbiBvZiBpT0FNLiA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZXJlIHNlZW0gdG8gYmUgZGlmZmVyZW5jZXMgYmV0d2Vl biB0aGUgZGVmaW5pdGlvbnMgaW48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3B1Ymxpc2hlZCBSRkNzLCB0aGUgdXNhZ2UgKHdoaWNoIGlzIG5vdCBh IGRlZmluaXRpb24pIGluIHRoZSBTRkM8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LCBhbmQgdGhlIHZhcmlvdXMgaXBwbSBkcmFmdHMuJm5i c3A7IEFueSBzdWNoIGRlZmluaXRpb24gd2lsbDxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmVlZCB0byBiZSB2ZXR0ZWQgd2l0aCB0aGUgaXBwbSB3 b3JraW5nIGdyb3VwLl9fX188YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18gX188YnIgY2xhc3M9IiI+DQomZ3Q7 IDxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QWdh aW4sIGl0IHdvdWxkIGJlIGdvb2QgaWYgbWVtYmVycyBvZiB0aGUgd29ya2luZyBncm91cCBiZXlv bmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Ro ZSB0d28gYXV0aG9yIHRlYW1zIHNwb2tlIHVwIGFib3V0IHRoZWlyIHJlYWRpbmdzIG9mIHRoZTxi ciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZG9jdW1l bnRzLCBhbmQgdGhlaXIgdW5kZXJzdGFuZGluZ3Mgb2Ygd2hhdCB3ZSBuZWVkLl9fX188YnIgY2xh c3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7X18gX188YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7WW91cnMsX19fXzxiciBjbGFzcz0iIj4NCiZn dDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtK aW0gYW5kIEpvZWxfX19fPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyIGNsYXNzPSIiPg0KJmd0OyA8 YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9f PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZmMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij5zZmNAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiByZWw9Im5vcmVmZXJyZXIiIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3NmYyBtYWlsaW5n IGxpc3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+c2ZjQGlldGYub3JnPC9h PiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPiZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgLS0gPGJyIGNsYXNzPSIiPg0KJmd0 OyA8YnIgY2xhc3M9IiI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vd3d3LnZlcml6b24uY29t LyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cDovL3d3dy52 ZXJpem9uLmNvbS88L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0 OyAqR3lhbiBNaXNocmEqPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IC9O ZXR3b3JrIFNvbHV0aW9ucyBBLy9yY2hpdGVjdCAvPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xh c3M9IiI+DQomZ3Q7IC9FbWFpbCA8YSBocmVmPSJtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9u LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208 L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20i IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5neWFuLnMubWlzaHJhQHZlcml6b24uY29tPC9hPiZn dDsvLzxiciBjbGFzcz0iIj4NCiZndDsgLzxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIi Pg0KJmd0OyAvTSAzMDEgNTAyLTEzNDc8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4N CiZndDsgLzxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCi0tIDxiciBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9z aWduYXR1cmUiIGRhdGEtc21hcnRtYWlsPSJnbWFpbF9zaWduYXR1cmUiPg0KPGRpdiBkaXI9Imx0 ciIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0i Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPHAgc3R5bGU9ImNvbG9yOnJnYigzNCwzNCwzNCkiIGNsYXNzPSIiPjxh IGhyZWY9Imh0dHA6Ly93d3cudmVyaXpvbi5jb20vIiBzdHlsZT0iY29sb3I6cmdiKDE3LDg1LDIw NCk7cGFkZGluZy1ib3R0b206MWVtO2Rpc3BsYXk6aW5saW5lLWJsb2NrIiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+PGltZyBzcmM9Imh0dHA6Ly9zczcudnp3LmNvbS9pcy9pbWFnZS9WZXJpem9u V2lyZWxlc3MvdnotbG9nby1lbWFpbCIgd2lkdGg9IjgxIiBoZWlnaHQ9IjE4IiBzdHlsZT0iaGVp Z2h0OjE4cHg7d2lkdGg6ODFweCIgY2xhc3M9IiI+PC9hPjxiciBjbGFzcz0iIj4NCjwvcD4NCjxk aXYgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyBtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6ICZxdW90 O1Zlcml6b24gTkhHIERTJnF1b3Q7LCBBcmlhbCwgc2Fucy1zZXJpZjsgbGluZS1oZWlnaHQ6IDEz cHg7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkd5YW4gTWlzaHJhPC9iPjwvZGl2Pg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgbWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiAx M3B4OyIgY2xhc3M9IiI+PGZvbnQgZmFjZT0iZ2VvcmdpYSwgc2VyaWYiIHN0eWxlPSJmb250LXNp emU6IDFlbTsiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPk5ldHdvcmsgU29sdXRpb25zIEE8L2k+PC9m b250Pjxmb250IGZhY2U9Imdlb3JnaWEsIHNlcmlmIiBjbGFzcz0iIj48aSBjbGFzcz0iIj5yY2hp dGVjdCZuYnNwOzwvaT48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDM0LCAz NCwgMzQpOyBtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IDEzcHg7IiBjbGFzcz0iIj48aSBzdHls ZT0iZm9udC1zaXplOiAxM3B4OyIgY2xhc3M9IiI+PGZvbnQgZmFjZT0iZ2VvcmdpYSwgc2VyaWYi IGNsYXNzPSIiPkVtYWlsDQo8YSBocmVmPSJtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208L2E+ PC9mb250PjwvaT48Zm9udCBmYWNlPSJnZW9yZ2lhLCBzZXJpZiIgY2xhc3M9IiI+PGkgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9pPjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZTogMWVtOyBtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IDEzcHg7IiBjbGFzcz0iIj48aSBjbGFz cz0iIj48Zm9udCBmYWNlPSJnZW9yZ2lhLCBzZXJpZiIgY2xhc3M9IiI+TSAzMDEgNTAyLTEzNDc8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+PC9pPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0Kc2ZjIG1haWxp bmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIGNsYXNz PSIiPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3CDEE7495A4044FF9E3A8C8EBBA94849ciscocom_-- From nobody Mon Feb 14 04:05:40 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103E23A0A40 for ; Mon, 14 Feb 2022 04:05:39 -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=unavailable 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 fCNrDGsPuJVW for ; Mon, 14 Feb 2022 04:05:33 -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 82E213A0A22 for ; Mon, 14 Feb 2022 04:05:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Jy2ws0Wlhz6GYLB; Mon, 14 Feb 2022 04:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1644840333; bh=1pLXPECLZvMxWzVCdSvAtZnWJvIc4xmHOySKR5zA/u4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=FoVFCAxKa7FJi2g8/WqRTI0fdJ8WeMMyLCbisAUbSvgPZ5nbhfnC8z6VM67mEnP/h RL9dwWn6hk7pB1pZrrDcQKK3KL1KFmdIaJzWRDpQDpcijxcEW7YWJ1ZaDrYkMGOt+T 4Z90E6PBsCSIK7Mm+mVwgUbJYgpq4BlJqJc0nP3I= 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)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4Jy2wr3Z5tz6G9Jb; Mon, 14 Feb 2022 04:05:32 -0800 (PST) Message-ID: Date: Mon, 14 Feb 2022 07:05:32 -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 To: "Carlos Pignataro (cpignata)" Cc: "sfc@ietf.org" References: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.com> From: "Joel M. Halpern" In-Reply-To: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG - OAM Packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 12:05:39 -0000 Thank you for taking the time to provide a careful reply. It appears, from your description of ICMP packets that your understanding of 8300 is that in SFC an external ICMP packet will get the O bit set in the NSH header. Presumably, base on this, the SFF or SF are supposed to look through and notice this content? (Otherwise, why set the bit?) This seems an undesirable and expensive implications which other readers have not drawn from the RFC 8300 text. (It also requires the encapsulating node to do extra checking to discover this case.) Am I reading your expectation correctly? Yours, Joel On 2/13/2022 11:06 PM, Carlos Pignataro (cpignata) wrote: > Replying to this specific email in the thread, only because it is the > latest one at this point in time, but bundling comments from various > places on the thread. Please find some follow-up comments and questions > marked “CMP”, indicating the “From”, and organized chronologically: > > *James N Guichard >:* > >> 1) The chairs have reviewed the O bit definition in RFC 8300.  That >> definition is at best open to interpretation and therefore >> incomplete.  For example, the clear intention is only to mark packets >> which are intended for SFC OAM at the SFC service layer.  But that is >> not what the current text says.  There is also, unfortunately, >> ambiguity as to what constitutes an OAM packet.  So it is reasonable >> for documents to update 8300 to clarify the exact applicability and >> action for the O-bit. > > CMP: It is unclear to me what exact issues the chairs are calling out. > There are two issues mentioned: > CMP: 1. "But that is not what the current text says.” —> what does the > text say precisely?  Can you point to the specific RFC 8300 text that is > believed to be incomplete, and a detailed use case that showcases the > potential issue? An extrapolated counter-example just to make a point: > the text does not  say what days of the week OAM packets can be marked, > yet there’s an expectation that they will work Mondays and Saturdays all > the same — even holidays. > CMP: 2. What specifically is the ambiguity with what an OAM packet is? > Please grep the RFC series for “oam packet”, it is not a new term. > CMP: Net-net, O-bit=1, OAM packet. > >> 2) However, related to point 1), we can't have multiple documents >> updating the definition differently.  As such, the authors of the SFC >> iOAM draft and the SFC multi-layer-oam draft need to come together and >> figure out what the clarification is for the definition of that bit. >> We do not believe as chairs that either of these documents can move >> forward from the WG until such clarity has been reached. > > CMP: If there is still believed to be an ambiguity or a clear > opportunity for improving the definition, I agree with consolidating > that update. I had suggested before that if such new text or real > clarification is agreed, a separate document that only makes that O-bit > clarification is the most clear and clean way to go. That doc should be > a one-pager or less. I’d be happy to contribute to that minimal doc, if > it is shown to be needed. > > CMP: For completeness also, the "SFC multi-layer-oam” document has many > outstanding issues besides the O-bit. > > *Greg Mirsky >* > >> I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I >> understand these documents, the Active SFC OAM and IOAM are identified >> by the respective values for the NSH Next Protocol field (to be >> assigned by IANA). > > CMP: There is a major issue with the sentence above. Active SFC OAM (as > a category), as per RFC 8300, needs to be identified by setting the > O-bit. No way around that based on RFC 8300. However, the text "the > Active SFC OAM” creates confusion since it refer to a specific OAM > protocol which has the same name as a the category as well. That name > collision is quite unfortunate in my opinion. > >> At the same time, so far no OAM-specific meta data TLV has been >> defined. Thus, it appears that one way forward could be to not involve >> the O bit in the active SFC OAM or IOAM altogether. In other words, to >> deprecate the NSH O bit. > > CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM > protocols. Those can be encapsulated in IP, in which the Next-Protocol > indicates IP — and (as per RFC 8300) the O-bit is set to indicate an OAM > packet. > CMP: The proposal of deprecating the O-bit breaks those SFC OAM > protocols already included in an RFC. > CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM. > CMP: This expired I-D yet implemented in open source uses the O-bit: > https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt > > > > *Gyan Mishra >* > >> I agree that what makes sense to me as a path forward is to deprecate >> the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC >> Multilayer OAM and SFC IOAM are identified by the respective values >> for the NSH Next Protocol field (to be assigned by IANA), as well as >> so far no OAM-specific meta data TLV has been yet defined. > > CMP: What is the “SFC Multilayer OAM”? > CMP: The O-bit (reading RFC 8300) does not indicate if there is OAM > Metadata. It indicates an OAM packet. > > > *"Joel M. Halpern" >* > >> As far as I can tell, if we deprecate the O-bit and rely on the next >> protocol field, we are saying that in practice (not by rule) NSH >> metadata can not be used for OAM.  That's fine with me as long as we >> agree on that. > > CMP: I do not fully follow this. Can you explain the relationship of the > O-bit with Metadata? > CMP: Here’s an example: RFC 8924 shows ICMP as Active OAM. The SFC next > protocol is IP, the IP next protocol is ICMP, the O-bit needs to be set. > > CMP: Consider the following document, independent submission and in the > RFC Publication queue already: > CMP: > https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/ > CMP: Is a Timestamp in Metadata an OAM element? > > CMP: Consider this proposal > https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/ > > CMP: Where the base header borrows a bit for an OAM function. > > CMP: Neither of those have any impact on the O-bit. > > > *Greg Mirsky >* > >> I agree that, as we find SFC NSH now, no OAM metadata has been >> defined. It appears to me that deprecating the O bit does not affect >> any of the already defined mechanisms in the SFC NSH. > > CMP: It actually does, see my example above. > >> I think that if a new, for example, MD Type = 2 TLV that is used for >> any OAM functionality to be proposed in the future, deprecated the O >> bit would not prevent using such NSH TLV. > > CMP: I agree with this — because there is no correlation between MD Type > field and O-bit as defined. > > Best, > > Carlos. > > > >> 2/13/22 午後12:32、Gyan Mishra > >のメール: >> >> Hi Joel >> >> I am in agreement as well with what you have stated that once the O >> bit is deprecated that NSH metadata cannot be used for OAM and that we >> would have to now from that point forward rely on the next protocol >> field as we will be doing for SFC Multilayer and SFC IOAM drafts as >> well as will have backwards compatible with any already existing >> defined mechanisms in SFC NSH. >> >> I don’t see any issues or impact with moving forward. >> >> Kind Regards >> >> Gyan >> >> On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky > > wrote: >> >> Hi Joel, >> I agree that, as we find SFC NSH now, no OAM metadata has been >> defined. It appears to me that deprecating the O bit does not >> affect any of the already defined mechanisms in the SFC NSH. I >> think that if a new, for example, MD Type = 2 TLV that is used for >> any OAM functionality to be proposed in the future, deprecated the >> O bit would not prevent using such NSH TLV. >> What do you think? >> >> Regards, >> Greg >> >> On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern >> > wrote: >> >> There is an implication of deprecating the O-bit that I would >> like to >> hear from more WG participants about. >> >> As far as I can tell, if we deprecate the O-bit and rely on >> the next >> protocol field, we are saying that in practice (not by rule) NSH >> metadata can not be used for OAM.  That's fine with me as long >> as we >> agree on that. >> >> Yours, >> Joel >> >> On 2/13/2022 2:52 AM, Gyan Mishra wrote: >> > >> > Hi Jim, Joel & SFC WG, >> > >> > I agree that the RFC 8300 definition of O bit is incomplete >> and not >> > clear as to its intended use. >> > >> > That is a problem that I agree needs to be rectified. >> > >> > I understand that we need to get this resolved before we can >> progress >> > Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC >> IOAM. >> > >> > I agree that what makes sense to me as a path forward is to >> deprecate >> > the O bit and not use in SFC Multilayer OAM and SFC IOAM, as >> both SFC >> > Multilayer OAM and SFC IOAM are identified by the respective >> values for >> > the NSH Next Protocol field (to be assigned by IANA), as >> well as so far >> > no OAM-specific meta data TLV has been yet defined. >> > >> > So we have I believe solid solution and path forward and I >> support >> > deprecating the O bit. >> > >> > Kind Regards >> > >> > Gyan >> > >> > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky >> >> > > >> wrote: >> > >> >     Thank you, Jim and Joel, for guiding the SFC OAM work >> and pointing >> >     out the issue that must be addressed. >> > >> >     I've reviewed our SFC OAM documents and >> draft-ietf-sfc-nsh-tlv. As I >> >     understand these documents, the Active SFC OAM and IOAM are >> >     identified by the respective values for the NSH Next >> Protocol field >> >     (to be assigned by IANA). At the same time, so far no >> OAM-specific >> >     meta data TLV has been defined. Thus, it appears that >> one way >> >     forward could be to not involve the O bit in the active >> SFC OAM or >> >     IOAM altogether. In other words, to deprecate the NSH O bit. >> > >> >     I greatly appreciate your comments on the proposal to >> deprecate the >> >     NSH O bit. >> > >> >     Regards, >> >     Greg >> > >> >     On Wed, Feb 2, 2022 at 10:36 AM James Guichard >> >     > >> >     > >> wrote: >> > >> >         Hi WG:____ >> > >> >         __ __ >> > >> >         Having reviewed all of the OAM related documents in >> our WG, the >> >         chairs would like to provide a few comments to hopefully >> >         generate discussion and forward progress of this >> work:____ >> > >> >         __ __ >> > >> >         1) The chairs have reviewed the O bit definition in >> RFC 8300. >> >         That definition is at best open to interpretation >> and therefore >> >         incomplete.  For example, the clear intention is >> only to mark >> >         packets which are intended for SFC OAM at the SFC >> service >> >         layer.  But that is not what the current text says. >> There is >> >         also, unfortunately, ambiguity as to what >> constitutes an OAM >> >         packet.  So it is reasonable for documents to update >> 8300 to >> >         clarify the exact applicability and action for the >> O-bit.____ >> > >> >         __ __ >> > >> >         2) However, related to point 1), we can't have multiple >> >         documents updating the definition differently.  As >> such, the >> >         authors of the SFC iOAM draft and the SFC >> multi-layer-oam draft >> >         need to come together and figure out what the >> clarification is >> >         for the definition of that bit. We do not believe as >> chairs that >> >         either of these documents can move forward from the >> WG until >> >         such clarity has been reached. ____ >> > >> >         __ __ >> > >> >         3) Related to the SFC iOAM, we need a clear >> definition of iOAM. >> >         There seem to be differences between the definitions in >> >         published RFCs, the usage (which is not a >> definition) in the SFC >> >         draft, and the various ippm drafts.  Any such >> definition will >> >         need to be vetted with the ippm working group.____ >> > >> >         __ __ >> > >> >         Again, it would be good if members of the working >> group beyond >> >         the two author teams spoke up about their readings >> of the >> >         documents, and their understandings of what we need.____ >> > >> >         __ __ >> > >> >         Yours,____ >> > >> >         Jim and Joel____ >> > >> >         __ __ >> > >> >         __ __ >> > >> >         __ __ >> > >> >         _______________________________________________ >> >         sfc mailing list >> > sfc@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/sfc >> >> >         > > >> > >> >     _______________________________________________ >> >     sfc mailing list >> > sfc@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/sfc >> >> >     > > >> > >> > -- >> > >> > > >> > >> > *Gyan Mishra* >> > >> > /Network Solutions A//rchitect / >> > >> > /Email gyan.s.mishra@verizon.com >> >> > >// >> > / >> > >> > /M 301 502-1347 >> > >> > / >> > >> > >> >> -- >> >> >> >> *Gyan Mishra* >> /Network Solutions A//rchitect / >> /Email gyan.s.mishra@verizon.com // >> / >> /M 301 502-1347 >> >> / >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 14 05:02:23 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DD93A0B72 for ; Mon, 14 Feb 2022 05:02:21 -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_H5=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=Z76g8qhC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NAY13Plk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-7ObEKslIA6 for ; Mon, 14 Feb 2022 05:02:16 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47B13A0B64 for ; Mon, 14 Feb 2022 05:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=71881; q=dns/txt; s=iport; t=1644843735; x=1646053335; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UVE9PrBhf3ZG/ZH8CkP2XffUgghgp2QcnkQprsoObZU=; b=Z76g8qhCNNqL5IebbssN7RaDuorYciQlPL62VfImOW3FNxyW1SBgjm1L HO0KulVa3hLV330mvogBn/NLn3yL8jFdU02bWxtngpZCBjOxPJdq98gSW aHp9GuNDo4ZBTmDg0wHNZVOUiuZy7kGFxsDYC/NYw0sTpw3D31flH48TC 4=; IronPort-PHdr: =?us-ascii?q?A9a23=3ASEKvwh2kYGBetedCsmDPr1BlVkEcU/3cMg0U7?= =?us-ascii?q?88hjLRDOuSm8o/5NUPSrfNqkBfSXIrd5v4F7oies63pVWEap5rUtncEfc9AU?= =?us-ascii?q?hYfgpAQmAotSMeOFUz8KqvsaCo3VMRPXVNo5Te1K09QTc3/fFbV5Ha16G16J?= =?us-ascii?q?w=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3A1w2Kvq1l4AQtQp4nJPbD5fxzkn2cJEfYwER7X?= =?us-ascii?q?KvMYLTBsI5bpz0DxjcfW2CGOPeIYGanet50Oozj90xVvMfdm4dhHAM93Hw8F?= =?us-ascii?q?HgiRegpqji6wuYcB84ZRyH6ZBoPA/42N5+QfKjYcleG/k33auK59CElvU21b?= =?us-ascii?q?uOU5NDsa3gZqTBMEE/NuTo78wIIqtYAbeqRWmthivuqyyHrA2JJ7hYvWo4iB?= =?us-ascii?q?w1vnzs01Bj6kGtwUlXT/pmntneG/5UeJMp3ya1csxLFrodo8u6SH44vzZmj9?= =?us-ascii?q?W/fuhwqEN7gyPDwc1YBRfjZOg3mZnh+Avf5xEMd4H1plP9mb5Lwam8P49mNt?= =?us-ascii?q?9tpydpLvIC5YQwoJabL3u8aVnG0FgkvbfMdoeSeeSbXXcu7iheun2HX6+5gB?= =?us-ascii?q?2k3MJEWvOFtDglm9/kYADIKYxSDjuauzai9DOJrg6wewGPDVG8EkmtrwTecB?= =?us-ascii?q?vE8TNWZBa7L/tRfmjw3g6hz8T/lT5JxQVJSgN7oOXWj4msqNa8=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3At6W4yqFcLv0yx5B3pLqFS5HXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskdvZJkh8erwX5VoMkmsi6KdgLNhfItKOT?= =?us-ascii?q?OHhILGFvAY0WKP+UyEJ8S6zJ8g6U4CSdk/NDSTNykBsS+S2mDReLxMrKjlgc?= =?us-ascii?q?KVbKXlvgpQpGpRGsddBnJCe36m+zpNNXB77PQCZf6hz/sCgwDlVWUcb8y9CH?= =?us-ascii?q?VAdfPEvcf3mJXvZgNDLwI76SGV5AnYq4LSIly95FMzQjlPybAt/SzuiAri/J?= =?us-ascii?q?iutPm911v1y3LT1ZJLg9Hso+EzRvBky/JlbwkEuDzYI7iJaIfy+gzdZ9vfsW?= =?us-ascii?q?rCpeO85yvI+f4Ds085MFvF+icFkDOQoQrGo0WSuWNwx0GT+/AQgFkBepZ8bU?= =?us-ascii?q?UzSGqF16NohqAP7Itbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0SbW?= =?us-ascii?q?OPAIUh3rD30XklWqvoJhiKpbzP0dMeev309bJTaxeXfnrZtm5gzJilWWkyBA?= =?us-ascii?q?6PRgwHttaO2zZbkXhlxw9ArfZv0Eso5dY4Ud1J9u7EOqNnmPVHSdIXd7t0AK?= =?us-ascii?q?METdGsAmLATBrQOCaZIEjhFqsAJ3XRwqSHr4kd9aWvYtgF3ZEykJPOXBdRsn?= =?us-ascii?q?MzYVvnDYmU0JhC4nn2MS6AtPTWu4ljDrRCy8nBrYvQQGS+oQoV4r6dSt0kc7?= =?us-ascii?q?rmZ8o=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AADWHflh/5ldJa1XAxwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBggYHAQELAYFRKC4Hd1oTJDGESYNHA4RZYIUOgwIDgROJfYU?= =?us-ascii?q?qimqBLhSBEQNPBQsBAQENAQEqAQwKBAEBhAWBAAIXg0gCJTQJDgECBAEBARI?= =?us-ascii?q?BAQUBAQECAQYEgQkThWgNhkMBAQEDAQEQCAkdAQEsBAcBDwIBBgIHESABBgM?= =?us-ascii?q?CAgIfBgsUEQIEDgUbB4JiAYIOVwMuAQ6Sco82AYE6AoofeoExgQGCCAEBBgQ?= =?us-ascii?q?EgUpBR4I7DQuCNwmBOgGDDYQcAQGBHoVpJxyBSUSBFSccgWZKBzA+giFCAQE?= =?us-ascii?q?DgScBARIBIBgKDBEJglE3gi6RLBoBFEYtFyYBAy8UDwEgAg0sIBYyAhUFIwM?= =?us-ascii?q?PCx4CCR8QkVoaFINHiU4/g0GJcpB0P0NrCoNGiwGILoUzgQKFeQUug3JEi1h?= =?us-ascii?q?ahgCRH4cTjzeCR4pIg06Qb1aEIAIEAgQFAg4BAQaBYTxpcHAVOyoBgj4JNRM?= =?us-ascii?q?ZD44gg3GFFIVKdAI2AgYBCgEBAwmMb10BAQ?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208,217";a="986313106" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Feb 2022 13:02:13 +0000 Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 21ED2Drk021246 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 14 Feb 2022 13:02:13 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 14 Feb 2022 07:02:12 -0600 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 14 Feb 2022 08:02:11 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Mon, 14 Feb 2022 07:02:11 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nsjOdkaO3zyodFGqhbmU7q06BV5Cn//9efeO4ciI64lvuDltMLuYcYFREsofNvoBkPWhEn3/G9if2AXrnGAcW9cv1TYsEudOVLf0CdCBAXIsabSDOyUNgTNqZwgT02EWS/obrLriIxKZVhPOn/9Mb8pNu7AyUXi6t9jYzVG54cTDqD4sCqMGuDf/XQOLaW3gKF0iy9icH8r8ngnz270jmOYzU4b7afBzHN6iD3Gg0wGistDSGXsY/pHbJdlCYpjBDrjzZPLSc8Us65pRJxg8gVO8gzdKnzCW3uOIuX+Gi93mAnLBQRfQnuoTYCIVO6o3kQ00hpT5ejeNsd8CENNJig== 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=UVE9PrBhf3ZG/ZH8CkP2XffUgghgp2QcnkQprsoObZU=; b=awmEpTGxjD+RQlQXzVLQpka0nnMmFloQ9dif0IOMZEbZmgWWz4luIaMODwP7KwXdZo1keZWRzufPiIZ2oFA+k9Y4GLGsQ7RQyf1i7XsMIymI0UJnJFKRz+AJRnnuEf3Ly0yFze3An6M1EwaA8QefBvdf7ma8Hun1rzCnd4ywN2k0VxBUJH6cBRhN/anXankMYhwWM48ela+HZz4ipvy4SiCPfZXtnD6EZ14SkL8oUVoAENyq1VqNMCwHdFZ74xlAgRs3CBz4S0PPTQqyztaPNu3WMMARWhPpI1U/A8aUibbaFn6flPEgGnGXvGLl1tLU2fHhQ2GcpxLdsglNP/WCqg== 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=UVE9PrBhf3ZG/ZH8CkP2XffUgghgp2QcnkQprsoObZU=; b=NAY13Plk/2jZwptWnycVYCFWqbhhqI1bwYK9ydJEOObeuCZaHeWYpJ0wdUAHaUyl2tnXW5/IqdUskpIoHC3NpFyghYRGm+XC0fLvtPbsithXsML3bE5TytZsuionAzFVWn19kmeHLm6VdKS/Mkf/mNUxbWEOuRcBtaAqfQjBipk= Received: from DS7PR11MB6039.namprd11.prod.outlook.com (2603:10b6:8:76::6) by BN7PR11MB2865.namprd11.prod.outlook.com (2603:10b6:406:ac::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11; Mon, 14 Feb 2022 13:02:09 +0000 Received: from DS7PR11MB6039.namprd11.prod.outlook.com ([fe80::e131:742a:954d:492c]) by DS7PR11MB6039.namprd11.prod.outlook.com ([fe80::e131:742a:954d:492c%6]) with mapi id 15.20.4975.012; Mon, 14 Feb 2022 13:02:09 +0000 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" CC: "sfc@ietf.org" Thread-Topic: [sfc] Progression of OAM work in the SFC WG - OAM Packet Thread-Index: AQHYIZs0zI0ukiw7l0yxCfkGbsuMUKyTAu+A Date: Mon, 14 Feb 2022 13:02:09 +0000 Message-ID: <69B3DD8B-1A6D-4D07-B41E-A2958A117E33@cisco.com> References: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.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.3693.60.0.1.1) 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: e4f4c79f-884d-4c38-0fa1-08d9efba3601 x-ms-traffictypediagnostic: BN7PR11MB2865:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P/uzQ6OplvlcYF2vyaekwGoEERb+/F44B3BVOWLR6yDVjxDOGN9M/+s/CSW/z6he9tM+Seht0coPwbjUG3a7f+m2B4w67x9b/5DsTxYskOmJcARUjULbesu45R7Da13tRCwCrVgUHUY7z//3o86J4K4YZtj4+8WRPhIFKWI6eJdwDAzcog5ack6cVRHK0TrgBIi5E+Lak1a/byXLwCmFJeeG9gyF1/bd4dFb5zxjESxJvRhUHxbUcYeI/LHiHcHFuTeEozM+/GYIqC4C0aGEW5pnQ114ce8twFftUBs0WUGT9zAkHWqVHniPUx374IBuPOgabWSwiCmemjEW8YZErC0Z0hNhwHn6aSA2PW4pdYokMBACzixRw4xEn1tXgPhSpKQXRgV89LyNxd2KVCtOFSBDqIOicAhlxk3mfgDpbS7BCUTpPXlIxpMTaG7gFHy/MlFQJSiPCAGttTcFzTlaH5iUQoP5tOYNTrKjv/S+6IMcJ3AG+CSwnPvBzxJ2me1DRk4jb+S1vl8HTt1KXeBNo3XGIKJ+CISrnwp8zpsXWdCcTHWhfXe+DkkJGQ/iYH24Dh69boAaBnQbUQpLvBsLborMQSXIlamJpJRa0ufiouNpJdUvZAxANBFmp6OTYFcDRaKDzb9kMg3et0XINe5JT2VekqTDF0l0zf5763XMgx3Neem7f8ZSzNu5RDoro9BFhy3CYU+ABlwrNSAdYhI0mYgb9wV7biJ6oJ+0IAFbuSH3rk+jqfTw/7m9zHL6Vii2RYmmXKv6x9hv353cPiXdW7fhekDCNjtKeUbgznNyKYALhVXQ3iGLAu7zhHINnEjMbiBxBTloATcCvV/cWNbh6fpBJ/U0i2I/YzTpd5ZYSSw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS7PR11MB6039.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(83380400001)(508600001)(966005)(86362001)(6486002)(8676002)(91956017)(76116006)(66446008)(64756008)(66476007)(36756003)(4326008)(66556008)(66946007)(71200400001)(8936002)(5660300002)(166002)(316002)(186003)(26005)(30864003)(6916009)(38100700002)(33656002)(122000001)(2906002)(2616005)(40140700001)(53546011)(6512007)(38070700005)(6506007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WmVYMVNSLzJRTjNqVUdFd3Y3blM2ZFRBaDVzRDBRQ2JLL2gzMWVRRWs3RDFm?= =?utf-8?B?TzR5UGY4S01lSnIyTWs1ZDhCVHFOM2lqQTZzbWkzMkZxTlJ5cEJNM2VJSEQz?= =?utf-8?B?c1k1bFE0N2ZmMVowek12bVZHUjhRR1U2ZzNoNUpia1NCZFRtdGN6NDhLK0M2?= =?utf-8?B?TEJtbnl2dW5EWDZJVnhhbEI5RmJLMWtVSHRXMnBVZWtWNUF1N2tnSGRJVWlX?= =?utf-8?B?UFJROXdFNDgzUlJ4dzVMN2xyUUtsMzZra25vcmxVdTc3bTJ6U3NleDBhaS84?= =?utf-8?B?TzdnRlJPaHdFK2IxRzNoU0RnV2RLRHFHeXhyUVk3TSt6clJMenI5amFhV2o5?= =?utf-8?B?ZG9ybFR5REZZVWhvVWdFQUJCTmZ1UWRtQ0VEOGNKaVp2RTZ6WEd2L3h6d3FE?= =?utf-8?B?dWw5ZVVRY25iVis4SzJ4QkNCWFlHQkxJR29lQStxa3FmVnBoMVBpVmNzOUZE?= =?utf-8?B?d05YczdzWVVVaElNblcyNk45M1o4cGdwdUtCMzV0dDQrdGMzb3pKbC9OT1Jn?= =?utf-8?B?cTg2YVdhVkRmSi9zTmJjaEJxWG50bXU0TEd4dWh3akxodVRhZFgvaWZTSWdp?= =?utf-8?B?UEFzYjhCNGNBWk1vOUd0UlMweVdNMklvQ1ZVd1dNRGNwZ3lMcktVWmJ6ajdj?= =?utf-8?B?cXlzTGVTc1lYNWM0bHlOci9QWGlRc1lKV3FYN3ZxV2FiRnFCU0dCM2prdXRk?= =?utf-8?B?d2NsZEwzcHo4YjVNT1ovSW10ME9tcm1NaFJuUkU0UU9FZk9Ra29xTDNFMG94?= =?utf-8?B?bSt0alJCNGExdzFOZnhGNWdTd0QyTjAyR3pWeXVpaHk2cjZRSVhOL2wzY21R?= =?utf-8?B?WjhaR2UrV1NHQXB5S2NTczF2azFIUzdZZi9NS0NWYnBRUUZVMkZqajF5WHJX?= =?utf-8?B?Sm5CU1ZLYzdBVnh6dndJZEVNb0kxNkR0VGR5QjFYRk43TzhMTVVNaVdPSE1I?= =?utf-8?B?TTROM2p4NHBNdjc4WEdSQko0VXFFYURpazdIbE9jNmxWRnFPMzl3TStlbVBH?= =?utf-8?B?MWZSWlVEbk44VG96bmU3bjFEVTN1a0FSTXp4SG5jVEJjNy9lY0pUQVRkcG1N?= =?utf-8?B?YUcyeWpudnY3SFdqUnVVN2hFUWZVS2N3d2QrakJiWlFEZXlIRVpTczBKcVRu?= =?utf-8?B?SlVQM1haM2xWTlhKaXBQMlZXK3RUQWJnbGxMWVNLSXdvSzdORzMxZkdXWnIw?= =?utf-8?B?L0NDSlFTdVJzTzluQmUvSE51RmFhVlg4S3NwMTY5eUlhMm9EYjVYcjhUMkwv?= =?utf-8?B?Y3U0MWFPb24rWlFjcHJxVDN6V1pTMTdBVmdwY21aNWsrNlZCZHpFTFc3cHAy?= =?utf-8?B?ME9zMjNrb2t0aUxqYUh2QVc1UlBUTjdmQjQ1OCttYmZsZmRiTmRGNzUrTERx?= =?utf-8?B?aXk2WllVTTJscGMzc0Y3UmNSMjlZTmMvQXVIUUZ3UTJvMmlQaTVYbzhsdFNj?= =?utf-8?B?K1RlQTh0clJoL28yTVN6UDJsa290VlBsUkRlM2owMWZjQlo0WVUyS3JxbitZ?= =?utf-8?B?T01KUVI5UE5Db3VpODJGSGJBMlZJRjRGMmlTcWVzeVRRazFkdjdrTGcyYXJG?= =?utf-8?B?UWpYVmlTWnkzeDEvYmNma1FqZ2QwTTI4cGFkWkFrOVJJTE5YRG8rNE0wNWxF?= =?utf-8?B?MmJFRWg3TU9VbUhHaEhENUIxU3dvQnlyRVM4cm56S2FZWHVFVjVyM1JWemJZ?= =?utf-8?B?L1A2eWNBOTloSzZuQTJpYVlXL3NZTXhneURCUWJOUlVIWDlZVWVDTnZ5U3Na?= =?utf-8?B?ODdKdzNDZ0s4ZURpQjkzNmk4aEJmSjI3S3grclhjODRGa2c2RHFQWml5NjQw?= =?utf-8?B?cGI2UElBNXVia1BPaVhYc3gzWnI4ZXB4cWc2OFloVnNoYTdWVlN2N041bHJQ?= =?utf-8?B?Wnd4RElob1VvMnJZRkIzS3pSZm5pZkxtcUw4eVhlZ0thaStHYVAwa1RaNjNy?= =?utf-8?B?NWhucFA2NDREVzBDM0tXODV4Y01iQ1MyNXIyZDZzZUY2bTJBQW5aRVRUUTVU?= =?utf-8?B?MmJpbmx0Y3JNT285RTFab3RqeGx1cTZKb0xYYkpQU1U5SExnZ2xhYjVIQUhG?= =?utf-8?B?cDVydWx1RjZFL05qM3loZ2pXa0dtV2hwNXZzRm56WHJkeWRkYjBObmpxNW9S?= =?utf-8?B?TlY4TkZRSXB1cTJUYjVqZGJWd29SWXdOakVNcHhSMXd4U09LQzFHRjNlSlFJ?= =?utf-8?Q?YAz6NyfAEnPDLUHr9dhY2eI=3D?= Content-Type: multipart/alternative; boundary="_000_69B3DD8B1A6D4D07B41EA2958A117E33ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB6039.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e4f4c79f-884d-4c38-0fa1-08d9efba3601 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2022 13:02:09.8318 (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: GjiFlmMdu5PSNaoJ56/a5wZ9mqvSSbz0iymGfd3oLeC0ezZl0cQxyzGLiYfElVYpSDy6TN5tVHc+wHmNnDyC2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2865 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG - OAM Packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 13:02:22 -0000 --_000_69B3DD8B1A6D4D07B41EA2958A117E33ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9lbCwNCg0KSGFwcHkgdG8uDQoNCk5vLCB0aGF0IGlzIG5vdCB3aGF0IEkgbWVhbnQuIEkgYW0g bm90IHN1cmUgd2hlcmUgKG9yIHdoeSkgeW91IGFkZGVkIHRoZSB3b3JkIOKAnGV4dGVybmFs4oCd LCBidXQgdGhhdCB3YXMga2V5IHRvIHNob3dpbmcgYSBkaXNjb25uZWN0IChJIG1pZ2h0IG5vdCBo YXZlIGJlZW4gY2xlYXIgYW5kL29yIHlvdSBtaWdodCBub3QgaGF2ZSByZWFkIGNvcnJlY3RseSku DQoNCkxldCBtZSB0cnkgZGlmZmVyZW50IHdheToNCg0KVGhlcmUgaXMgYW4gSS1EIG5vdywgc2Zj LW11bHRpLWxheWVyLW9hbSwgdGhhdCBzZW5kcyDigJxTRkMgQWN0aXZlIE9BTSIgcGFja2V0cyB3 aXRoIGEgbmV3IFNGQyBuZXh0IHByb3RvY29sIGZvciBhIG5ld2x5IGNyZWF0ZWQgcHJvdG9jb2wu IEluIHRoaXMgY2FzZSwgdGhlIFNGQyBuZXh0IHByb3RvY29sIGlzIG5vdCBleHBlY3RlZCB0byBi ZSB1c2VkIGluIHVzZXIgcGFja2V0cywgYXQgbGVhc3QgZm9yIG5vdyAob3IgcGVvcGxlIGhhdmUg bm90IHRob3VnaHQgYWJvdXQgdGhhdCBpbiBoaWVyYXJjaGljYWwgY2FzZXMpDQoNCkltYWdpbmUg bm93IHRoYXQgQkZEIG9yIElDTVAgd2FudCB0byBiZSB1c2VkIGFzIGFuIFNGQyBBY3RpdmUgT0FN IHByb3RvY29scywgaW5zdGVhZCBvZiB0aGUgc2ZjLW11bHRpLWxheWVyLW9hbSBvbmUuIFRob3Nl IGNhbiBiZSBlbmNhcHN1bGF0ZWQgaW4gSVAgKGV2ZW4gd2l0aCBhIDEyNy84IGRlc3RpbmF0aW9u KS4gVXNpbmcgdGhlIE8tYml0IHNldCBhbmQgU0ZDIE5QIGFzIElQIGlzIHRoZSBSRkMgODMwMCBl eHBlY3RlZCB3YXkuIChJIGltYWdpbmUgY3JlYXRpbmcgYSBuZXcgU0ZDIG5leHQgcHJvdG9jb2wg Zm9yIOKAnEJGRC1pbi1JUC11c2VkLWluLVNGQ+KAnSBzbyBhcyB0byBhdm9pZCBhbiBTRkMgTlAg ZXhwZWN0ZWQgb24gZXh0ZXJuYWwgcGFja2V0cyB3b3VsZCBiZSBhbiBhcHByb2FjaCBpZiB0aGVy ZSB3YXMgbm8gTy1iaXQgZGVmaW5lZCkNCg0KQmVzdCwNCg0KQ2FybG9zLg0KDQoyLzE0LzIyIOWN iOWJjTc6MDXjgIFKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmpt aEBqb2VsaGFscGVybi5jb20+PuOBruODoeODvOODqzoNCg0KVGhhbmsgeW91IGZvciB0YWtpbmcg dGhlIHRpbWUgdG8gcHJvdmlkZSBhIGNhcmVmdWwgcmVwbHkuDQoNCkl0IGFwcGVhcnMsIGZyb20g eW91ciBkZXNjcmlwdGlvbiBvZiBJQ01QIHBhY2tldHMgdGhhdCB5b3VyIHVuZGVyc3RhbmRpbmcg b2YgODMwMCBpcyB0aGF0IGluIFNGQyBhbiBleHRlcm5hbCBJQ01QIHBhY2tldCB3aWxsIGdldCB0 aGUgTyBiaXQgc2V0IGluIHRoZSBOU0ggaGVhZGVyLiAgUHJlc3VtYWJseSwgYmFzZSBvbiB0aGlz LCB0aGUgU0ZGIG9yIFNGIGFyZSBzdXBwb3NlZCB0byBsb29rIHRocm91Z2ggYW5kIG5vdGljZSB0 aGlzIGNvbnRlbnQ/ICAgKE90aGVyd2lzZSwgd2h5IHNldCB0aGUgYml0PykgIFRoaXMgc2VlbXMg YW4gdW5kZXNpcmFibGUgYW5kIGV4cGVuc2l2ZSBpbXBsaWNhdGlvbnMgd2hpY2ggb3RoZXIgcmVh ZGVycyBoYXZlIG5vdCBkcmF3biBmcm9tIHRoZSBSRkMgODMwMCB0ZXh0LiAgKEl0IGFsc28gcmVx dWlyZXMgdGhlIGVuY2Fwc3VsYXRpbmcgbm9kZSB0byBkbyBleHRyYSBjaGVja2luZyB0byBkaXNj b3ZlciB0aGlzIGNhc2UuKQ0KDQpBbSBJIHJlYWRpbmcgeW91ciBleHBlY3RhdGlvbiBjb3JyZWN0 bHk/DQoNCllvdXJzLA0KSm9lbA0KDQpPbiAyLzEzLzIwMjIgMTE6MDYgUE0sIENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKSB3cm90ZToNClJlcGx5aW5nIHRvIHRoaXMgc3BlY2lmaWMgZW1haWwg aW4gdGhlIHRocmVhZCwgb25seSBiZWNhdXNlIGl0IGlzIHRoZSBsYXRlc3Qgb25lIGF0IHRoaXMg cG9pbnQgaW4gdGltZSwgYnV0IGJ1bmRsaW5nIGNvbW1lbnRzIGZyb20gdmFyaW91cyBwbGFjZXMg b24gdGhlIHRocmVhZC4gUGxlYXNlIGZpbmQgc29tZSBmb2xsb3ctdXAgY29tbWVudHMgYW5kIHF1 ZXN0aW9ucyBtYXJrZWQg4oCcQ01Q4oCdLCBpbmRpY2F0aW5nIHRoZSDigJxGcm9t4oCdLCBhbmQg b3JnYW5pemVkIGNocm9ub2xvZ2ljYWxseToNCipKYW1lcyBOIEd1aWNoYXJkIDxqYW1lcy5uLmd1 aWNoYXJkQGZ1dHVyZXdlaS5jb208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNv bT4gPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+PjoqDQoxKSBUaGUgY2hh aXJzIGhhdmUgcmV2aWV3ZWQgdGhlIE8gYml0IGRlZmluaXRpb24gaW4gUkZDIDgzMDAuICBUaGF0 IGRlZmluaXRpb24gaXMgYXQgYmVzdCBvcGVuIHRvIGludGVycHJldGF0aW9uIGFuZCB0aGVyZWZv cmUgaW5jb21wbGV0ZS4gIEZvciBleGFtcGxlLCB0aGUgY2xlYXIgaW50ZW50aW9uIGlzIG9ubHkg dG8gbWFyayBwYWNrZXRzIHdoaWNoIGFyZSBpbnRlbmRlZCBmb3IgU0ZDIE9BTSBhdCB0aGUgU0ZD IHNlcnZpY2UgbGF5ZXIuICBCdXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgY3VycmVudCB0ZXh0IHNh eXMuICBUaGVyZSBpcyBhbHNvLCB1bmZvcnR1bmF0ZWx5LCBhbWJpZ3VpdHkgYXMgdG8gd2hhdCBj b25zdGl0dXRlcyBhbiBPQU0gcGFja2V0LiAgU28gaXQgaXMgcmVhc29uYWJsZSBmb3IgZG9jdW1l bnRzIHRvIHVwZGF0ZSA4MzAwIHRvIGNsYXJpZnkgdGhlIGV4YWN0IGFwcGxpY2FiaWxpdHkgYW5k IGFjdGlvbiBmb3IgdGhlIE8tYml0Lg0KQ01QOiBJdCBpcyB1bmNsZWFyIHRvIG1lIHdoYXQgZXhh Y3QgaXNzdWVzIHRoZSBjaGFpcnMgYXJlIGNhbGxpbmcgb3V0LiBUaGVyZSBhcmUgdHdvIGlzc3Vl cyBtZW50aW9uZWQ6DQpDTVA6IDEuICJCdXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgY3VycmVudCB0 ZXh0IHNheXMu4oCdIOKAlD4gd2hhdCBkb2VzIHRoZSB0ZXh0IHNheSBwcmVjaXNlbHk/ICBDYW4g eW91IHBvaW50IHRvIHRoZSBzcGVjaWZpYyBSRkMgODMwMCB0ZXh0IHRoYXQgaXMgYmVsaWV2ZWQg dG8gYmUgaW5jb21wbGV0ZSwgYW5kIGEgZGV0YWlsZWQgdXNlIGNhc2UgdGhhdCBzaG93Y2FzZXMg dGhlIHBvdGVudGlhbCBpc3N1ZT8gQW4gZXh0cmFwb2xhdGVkIGNvdW50ZXItZXhhbXBsZSBqdXN0 IHRvIG1ha2UgYSBwb2ludDogdGhlIHRleHQgZG9lcyBub3QgIHNheSB3aGF0IGRheXMgb2YgdGhl IHdlZWsgT0FNIHBhY2tldHMgY2FuIGJlIG1hcmtlZCwgeWV0IHRoZXJl4oCZcyBhbiBleHBlY3Rh dGlvbiB0aGF0IHRoZXkgd2lsbCB3b3JrIE1vbmRheXMgYW5kIFNhdHVyZGF5cyBhbGwgdGhlIHNh bWUg4oCUIGV2ZW4gaG9saWRheXMuDQpDTVA6IDIuIFdoYXQgc3BlY2lmaWNhbGx5IGlzIHRoZSBh bWJpZ3VpdHkgd2l0aCB3aGF0IGFuIE9BTSBwYWNrZXQgaXM/IFBsZWFzZSBncmVwIHRoZSBSRkMg c2VyaWVzIGZvciDigJxvYW0gcGFja2V04oCdLCBpdCBpcyBub3QgYSBuZXcgdGVybS4NCkNNUDog TmV0LW5ldCwgTy1iaXQ9MSwgT0FNIHBhY2tldC4NCjIpIEhvd2V2ZXIsIHJlbGF0ZWQgdG8gcG9p bnQgMSksIHdlIGNhbid0IGhhdmUgbXVsdGlwbGUgZG9jdW1lbnRzIHVwZGF0aW5nIHRoZSBkZWZp bml0aW9uIGRpZmZlcmVudGx5LiAgQXMgc3VjaCwgdGhlIGF1dGhvcnMgb2YgdGhlIFNGQyBpT0FN IGRyYWZ0IGFuZCB0aGUgU0ZDIG11bHRpLWxheWVyLW9hbSBkcmFmdCBuZWVkIHRvIGNvbWUgdG9n ZXRoZXIgYW5kIGZpZ3VyZSBvdXQgd2hhdCB0aGUgY2xhcmlmaWNhdGlvbiBpcyBmb3IgdGhlIGRl ZmluaXRpb24gb2YgdGhhdCBiaXQuIFdlIGRvIG5vdCBiZWxpZXZlIGFzIGNoYWlycyB0aGF0IGVp dGhlciBvZiB0aGVzZSBkb2N1bWVudHMgY2FuIG1vdmUgZm9yd2FyZCBmcm9tIHRoZSBXRyB1bnRp bCBzdWNoIGNsYXJpdHkgaGFzIGJlZW4gcmVhY2hlZC4NCkNNUDogSWYgdGhlcmUgaXMgc3RpbGwg YmVsaWV2ZWQgdG8gYmUgYW4gYW1iaWd1aXR5IG9yIGEgY2xlYXIgb3Bwb3J0dW5pdHkgZm9yIGlt cHJvdmluZyB0aGUgZGVmaW5pdGlvbiwgSSBhZ3JlZSB3aXRoIGNvbnNvbGlkYXRpbmcgdGhhdCB1 cGRhdGUuIEkgaGFkIHN1Z2dlc3RlZCBiZWZvcmUgdGhhdCBpZiBzdWNoIG5ldyB0ZXh0IG9yIHJl YWwgY2xhcmlmaWNhdGlvbiBpcyBhZ3JlZWQsIGEgc2VwYXJhdGUgZG9jdW1lbnQgdGhhdCBvbmx5 IG1ha2VzIHRoYXQgTy1iaXQgY2xhcmlmaWNhdGlvbiBpcyB0aGUgbW9zdCBjbGVhciBhbmQgY2xl YW4gd2F5IHRvIGdvLiBUaGF0IGRvYyBzaG91bGQgYmUgYSBvbmUtcGFnZXIgb3IgbGVzcy4gSeKA mWQgYmUgaGFwcHkgdG8gY29udHJpYnV0ZSB0byB0aGF0IG1pbmltYWwgZG9jLCBpZiBpdCBpcyBz aG93biB0byBiZSBuZWVkZWQuDQpDTVA6IEZvciBjb21wbGV0ZW5lc3MgYWxzbywgdGhlICJTRkMg bXVsdGktbGF5ZXItb2Ft4oCdIGRvY3VtZW50IGhhcyBtYW55IG91dHN0YW5kaW5nIGlzc3VlcyBi ZXNpZGVzIHRoZSBPLWJpdC4NCipHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1h aWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+IDxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29t Pj4qDQpJJ3ZlIHJldmlld2VkIG91ciBTRkMgT0FNIGRvY3VtZW50cyBhbmQgZHJhZnQtaWV0Zi1z ZmMtbnNoLXRsdi4gQXMgSSB1bmRlcnN0YW5kIHRoZXNlIGRvY3VtZW50cywgdGhlIEFjdGl2ZSBT RkMgT0FNIGFuZCBJT0FNIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSByZXNwZWN0aXZlIHZhbHVlcyBm b3IgdGhlIE5TSCBOZXh0IFByb3RvY29sIGZpZWxkICh0byBiZSBhc3NpZ25lZCBieSBJQU5BKS4N CkNNUDogVGhlcmUgaXMgYSBtYWpvciBpc3N1ZSB3aXRoIHRoZSBzZW50ZW5jZSBhYm92ZS4gQWN0 aXZlIFNGQyBPQU0gKGFzIGEgY2F0ZWdvcnkpLCBhcyBwZXIgUkZDIDgzMDAsIG5lZWRzIHRvIGJl IGlkZW50aWZpZWQgYnkgc2V0dGluZyB0aGUgTy1iaXQuIE5vIHdheSBhcm91bmQgdGhhdCBiYXNl ZCBvbiBSRkMgODMwMC4gSG93ZXZlciwgdGhlIHRleHQgInRoZSBBY3RpdmUgU0ZDIE9BTeKAnSBj cmVhdGVzIGNvbmZ1c2lvbiBzaW5jZSBpdCByZWZlciB0byBhIHNwZWNpZmljIE9BTSBwcm90b2Nv bCB3aGljaCBoYXMgdGhlIHNhbWUgbmFtZSBhcyBhIHRoZSBjYXRlZ29yeSBhcyB3ZWxsLiBUaGF0 IG5hbWUgY29sbGlzaW9uIGlzIHF1aXRlIHVuZm9ydHVuYXRlIGluIG15IG9waW5pb24uDQpBdCB0 aGUgc2FtZSB0aW1lLCBzbyBmYXIgbm8gT0FNLXNwZWNpZmljIG1ldGEgZGF0YSBUTFYgaGFzIGJl ZW4gZGVmaW5lZC4gVGh1cywgaXQgYXBwZWFycyB0aGF0IG9uZSB3YXkgZm9yd2FyZCBjb3VsZCBi ZSB0byBub3QgaW52b2x2ZSB0aGUgTyBiaXQgaW4gdGhlIGFjdGl2ZSBTRkMgT0FNIG9yIElPQU0g YWx0b2dldGhlci4gSW4gb3RoZXIgd29yZHMsIHRvIGRlcHJlY2F0ZSB0aGUgTlNIIE8gYml0Lg0K Q01QOiBSRkMgODkyNCBhbHJlYWR5IGluY2x1ZGVzIElDTVAgYW5kIEJGRCBhcyBleGFtcGxlIFNG QyBBY3Rpb24gT0FNIHByb3RvY29scy4gVGhvc2UgY2FuIGJlIGVuY2Fwc3VsYXRlZCBpbiBJUCwg aW4gd2hpY2ggdGhlIE5leHQtUHJvdG9jb2wgaW5kaWNhdGVzIElQIOKAlCBhbmQgKGFzIHBlciBS RkMgODMwMCkgdGhlIE8tYml0IGlzIHNldCB0byBpbmRpY2F0ZSBhbiBPQU0gcGFja2V0Lg0KQ01Q OiBUaGUgcHJvcG9zYWwgb2YgZGVwcmVjYXRpbmcgdGhlIE8tYml0IGJyZWFrcyB0aG9zZSBTRkMg T0FNIHByb3RvY29scyBhbHJlYWR5IGluY2x1ZGVkIGluIGFuIFJGQy4NCkNNUDogVGhhdCBwcm9w b3NhbCBvZiBkZXByZWNhdGluZyB0aGUgTy1iaXQgYWxzbyBicmVha3MgU2VjdGlvbiA0LjEgb2Yg SU9BTS4NCkNNUDogVGhpcyBleHBpcmVkIEktRCB5ZXQgaW1wbGVtZW50ZWQgaW4gb3BlbiBzb3Vy Y2UgdXNlcyB0aGUgTy1iaXQ6IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQt cGVubm8tc2ZjLXRyYWNlLTAzLnR4dCA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9k cmFmdC1wZW5uby1zZmMtdHJhY2UtMDMudHh0Pg0KKkd5YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBn bWFpbC5jb208bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbT4gPG1haWx0bzpoYXlhYnVzYWdz bUBnbWFpbC5jb20+PioNCkkgYWdyZWUgdGhhdCB3aGF0IG1ha2VzIHNlbnNlIHRvIG1lIGFzIGEg cGF0aCBmb3J3YXJkIGlzIHRvIGRlcHJlY2F0ZSB0aGUgTyBiaXQgYW5kIG5vdCB1c2UgaW4gU0ZD IE11bHRpbGF5ZXIgT0FNIGFuZCBTRkMgSU9BTSwgYXMgYm90aCBTRkMgTXVsdGlsYXllciBPQU0g YW5kIFNGQyBJT0FNIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSByZXNwZWN0aXZlIHZhbHVlcyBmb3Ig dGhlIE5TSCBOZXh0IFByb3RvY29sIGZpZWxkICh0byBiZSBhc3NpZ25lZCBieSBJQU5BKSwgYXMg d2VsbCBhcyBzbyBmYXIgbm8gT0FNLXNwZWNpZmljIG1ldGEgZGF0YSBUTFYgaGFzIGJlZW4geWV0 IGRlZmluZWQuDQpDTVA6IFdoYXQgaXMgdGhlIOKAnFNGQyBNdWx0aWxheWVyIE9BTeKAnT8NCkNN UDogVGhlIE8tYml0IChyZWFkaW5nIFJGQyA4MzAwKSBkb2VzIG5vdCBpbmRpY2F0ZSBpZiB0aGVy ZSBpcyBPQU0gTWV0YWRhdGEuIEl0IGluZGljYXRlcyBhbiBPQU0gcGFja2V0Lg0KKiJKb2VsIE0u IEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PioNCkFzIGZhciBhcyBJIGNhbiB0ZWxsLCBp ZiB3ZSBkZXByZWNhdGUgdGhlIE8tYml0IGFuZCByZWx5IG9uIHRoZSBuZXh0IHByb3RvY29sIGZp ZWxkLCB3ZSBhcmUgc2F5aW5nIHRoYXQgaW4gcHJhY3RpY2UgKG5vdCBieSBydWxlKSBOU0ggbWV0 YWRhdGEgY2FuIG5vdCBiZSB1c2VkIGZvciBPQU0uICBUaGF0J3MgZmluZSB3aXRoIG1lIGFzIGxv bmcgYXMgd2UgYWdyZWUgb24gdGhhdC4NCkNNUDogSSBkbyBub3QgZnVsbHkgZm9sbG93IHRoaXMu IENhbiB5b3UgZXhwbGFpbiB0aGUgcmVsYXRpb25zaGlwIG9mIHRoZSBPLWJpdCB3aXRoIE1ldGFk YXRhPw0KQ01QOiBIZXJl4oCZcyBhbiBleGFtcGxlOiBSRkMgODkyNCBzaG93cyBJQ01QIGFzIEFj dGl2ZSBPQU0uIFRoZSBTRkMgbmV4dCBwcm90b2NvbCBpcyBJUCwgdGhlIElQIG5leHQgcHJvdG9j b2wgaXMgSUNNUCwgdGhlIE8tYml0IG5lZWRzIHRvIGJlIHNldC4NCkNNUDogQ29uc2lkZXIgdGhl IGZvbGxvd2luZyBkb2N1bWVudCwgaW5kZXBlbmRlbnQgc3VibWlzc2lvbiBhbmQgaW4gdGhlIFJG QyBQdWJsaWNhdGlvbiBxdWV1ZSBhbHJlYWR5Og0KQ01QOiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1teW1iLXNmYy1uc2gtYWxsb2NhdGlvbi10aW1lc3RhbXAvIDxodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1teW1iLXNmYy1uc2gtYWxsb2NhdGlv bi10aW1lc3RhbXAvPg0KQ01QOiBJcyBhIFRpbWVzdGFtcCBpbiBNZXRhZGF0YSBhbiBPQU0gZWxl bWVudD8NCkNNUDogQ29uc2lkZXIgdGhpcyBwcm9wb3NhbCBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1taXJza3ktc2ZjLXBtYW1tLyA8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5LXNmYy1wbWFtbS8+DQpDTVA6IFdoZXJlIHRoZSBiYXNl IGhlYWRlciBib3Jyb3dzIGEgYml0IGZvciBhbiBPQU0gZnVuY3Rpb24uDQpDTVA6IE5laXRoZXIg b2YgdGhvc2UgaGF2ZSBhbnkgaW1wYWN0IG9uIHRoZSBPLWJpdC4NCipHcmVnIE1pcnNreSA8Z3Jl Z2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+IDxtYWlsdG86 Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4qDQpJIGFncmVlIHRoYXQsIGFzIHdlIGZpbmQgU0ZDIE5T SCBub3csIG5vIE9BTSBtZXRhZGF0YSBoYXMgYmVlbiBkZWZpbmVkLiBJdCBhcHBlYXJzIHRvIG1l IHRoYXQgZGVwcmVjYXRpbmcgdGhlIE8gYml0IGRvZXMgbm90IGFmZmVjdCBhbnkgb2YgdGhlIGFs cmVhZHkgZGVmaW5lZCBtZWNoYW5pc21zIGluIHRoZSBTRkMgTlNILg0KQ01QOiBJdCBhY3R1YWxs eSBkb2VzLCBzZWUgbXkgZXhhbXBsZSBhYm92ZS4NCkkgdGhpbmsgdGhhdCBpZiBhIG5ldywgZm9y IGV4YW1wbGUsIE1EIFR5cGUgPSAyIFRMViB0aGF0IGlzIHVzZWQgZm9yIGFueSBPQU0gZnVuY3Rp b25hbGl0eSB0byBiZSBwcm9wb3NlZCBpbiB0aGUgZnV0dXJlLCBkZXByZWNhdGVkIHRoZSBPIGJp dCB3b3VsZCBub3QgcHJldmVudCB1c2luZyBzdWNoIE5TSCBUTFYuDQpDTVA6IEkgYWdyZWUgd2l0 aCB0aGlzIOKAlCBiZWNhdXNlIHRoZXJlIGlzIG5vIGNvcnJlbGF0aW9uIGJldHdlZW4gTUQgVHlw ZSBmaWVsZCBhbmQgTy1iaXQgYXMgZGVmaW5lZC4NCkJlc3QsDQpDYXJsb3MuDQoyLzEzLzIyIOWN iOW+jDEyOjMy44CBR3lhbiBNaXNocmEgPGhheWFidXNhZ3NtQGdtYWlsLmNvbTxtYWlsdG86aGF5 YWJ1c2Fnc21AZ21haWwuY29tPiA8bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbT4+44Gu44Oh 44O844OrOg0KDQpIaSBKb2VsDQoNCkkgYW0gaW4gYWdyZWVtZW50IGFzIHdlbGwgd2l0aCB3aGF0 IHlvdSBoYXZlIHN0YXRlZCB0aGF0IG9uY2UgdGhlIE8gYml0IGlzIGRlcHJlY2F0ZWQgdGhhdCBO U0ggbWV0YWRhdGEgY2Fubm90IGJlIHVzZWQgZm9yIE9BTSBhbmQgdGhhdCB3ZSB3b3VsZCBoYXZl IHRvIG5vdyBmcm9tIHRoYXQgcG9pbnQgZm9yd2FyZCByZWx5IG9uIHRoZSBuZXh0IHByb3RvY29s IGZpZWxkIGFzIHdlIHdpbGwgYmUgZG9pbmcgZm9yIFNGQyBNdWx0aWxheWVyIGFuZCBTRkMgSU9B TSBkcmFmdHMgYXMgd2VsbCBhcyB3aWxsIGhhdmUgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBh bnkgYWxyZWFkeSBleGlzdGluZyBkZWZpbmVkIG1lY2hhbmlzbXMgaW4gU0ZDIE5TSC4NCg0KSSBk b27igJl0IHNlZSBhbnkgaXNzdWVzIG9yIGltcGFjdCB3aXRoIG1vdmluZyBmb3J3YXJkLg0KDQpL aW5kIFJlZ2FyZHMNCg0KR3lhbg0KDQpPbiBTdW4sIEZlYiAxMywgMjAyMiBhdCAxMjowNCBQTSBH cmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFp bC5jb20+IDxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQoNCiAgIEhpIEpv ZWwsDQogICBJIGFncmVlIHRoYXQsIGFzIHdlIGZpbmQgU0ZDIE5TSCBub3csIG5vIE9BTSBtZXRh ZGF0YSBoYXMgYmVlbg0KICAgZGVmaW5lZC4gSXQgYXBwZWFycyB0byBtZSB0aGF0IGRlcHJlY2F0 aW5nIHRoZSBPIGJpdCBkb2VzIG5vdA0KICAgYWZmZWN0IGFueSBvZiB0aGUgYWxyZWFkeSBkZWZp bmVkIG1lY2hhbmlzbXMgaW4gdGhlIFNGQyBOU0guIEkNCiAgIHRoaW5rIHRoYXQgaWYgYSBuZXcs IGZvciBleGFtcGxlLCBNRCBUeXBlID0gMiBUTFYgdGhhdCBpcyB1c2VkIGZvcg0KICAgYW55IE9B TSBmdW5jdGlvbmFsaXR5IHRvIGJlIHByb3Bvc2VkIGluIHRoZSBmdXR1cmUsIGRlcHJlY2F0ZWQg dGhlDQogICBPIGJpdCB3b3VsZCBub3QgcHJldmVudCB1c2luZyBzdWNoIE5TSCBUTFYuDQogICBX aGF0IGRvIHlvdSB0aGluaz8NCg0KICAgUmVnYXJkcywNCiAgIEdyZWcNCg0KICAgT24gU3VuLCBG ZWIgMTMsIDIwMjIgYXQgNjo1NSBBTSBKb2VsIE0uIEhhbHBlcm4NCiAgIDxqbWhAam9lbGhhbHBl cm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPiA8bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20+PiB3cm90ZToNCg0KICAgICAgIFRoZXJlIGlzIGFuIGltcGxpY2F0aW9uIG9mIGRlcHJl Y2F0aW5nIHRoZSBPLWJpdCB0aGF0IEkgd291bGQNCiAgICAgICBsaWtlIHRvDQogICAgICAgaGVh ciBmcm9tIG1vcmUgV0cgcGFydGljaXBhbnRzIGFib3V0Lg0KDQogICAgICAgQXMgZmFyIGFzIEkg Y2FuIHRlbGwsIGlmIHdlIGRlcHJlY2F0ZSB0aGUgTy1iaXQgYW5kIHJlbHkgb24NCiAgICAgICB0 aGUgbmV4dA0KICAgICAgIHByb3RvY29sIGZpZWxkLCB3ZSBhcmUgc2F5aW5nIHRoYXQgaW4gcHJh Y3RpY2UgKG5vdCBieSBydWxlKSBOU0gNCiAgICAgICBtZXRhZGF0YSBjYW4gbm90IGJlIHVzZWQg Zm9yIE9BTS4gIFRoYXQncyBmaW5lIHdpdGggbWUgYXMgbG9uZw0KICAgICAgIGFzIHdlDQogICAg ICAgYWdyZWUgb24gdGhhdC4NCg0KICAgICAgIFlvdXJzLA0KICAgICAgIEpvZWwNCg0KICAgICAg IE9uIDIvMTMvMjAyMiAyOjUyIEFNLCBHeWFuIE1pc2hyYSB3cm90ZToNCiAgICAgICA+DQogICAg ICAgPiBIaSBKaW0sIEpvZWwgJiBTRkMgV0csDQogICAgICAgPg0KICAgICAgID4gSSBhZ3JlZSB0 aGF0IHRoZSBSRkMgODMwMCBkZWZpbml0aW9uIG9mIE8gYml0IGlzIGluY29tcGxldGUNCiAgICAg ICBhbmQgbm90DQogICAgICAgPiBjbGVhciBhcyB0byBpdHMgaW50ZW5kZWQgdXNlLg0KICAgICAg ID4NCiAgICAgICA+IFRoYXQgaXMgYSBwcm9ibGVtIHRoYXQgSSBhZ3JlZSBuZWVkcyB0byBiZSBy ZWN0aWZpZWQuDQogICAgICAgPg0KICAgICAgID4gSSB1bmRlcnN0YW5kIHRoYXQgd2UgbmVlZCB0 byBnZXQgdGhpcyByZXNvbHZlZCBiZWZvcmUgd2UgY2FuDQogICAgICAgcHJvZ3Jlc3MNCiAgICAg ICA+IE11bHRpbGF5ZXIgU0ZDIE9BTSBkcmFmdC1pZXRmLXNmYy1tdWx0aS1sYXllci1vYW0tMTgg YW5kIFNGQw0KICAgICAgIElPQU0uDQogICAgICAgPg0KICAgICAgID4gSSBhZ3JlZSB0aGF0IHdo YXQgbWFrZXMgc2Vuc2UgdG8gbWUgYXMgYSBwYXRoIGZvcndhcmQgaXMgdG8NCiAgICAgICBkZXBy ZWNhdGUNCiAgICAgICA+IHRoZSBPIGJpdCBhbmQgbm90IHVzZSBpbiBTRkMgTXVsdGlsYXllciBP QU0gYW5kIFNGQyBJT0FNLCBhcw0KICAgICAgIGJvdGggU0ZDDQogICAgICAgPiBNdWx0aWxheWVy IE9BTSBhbmQgU0ZDIElPQU0gYXJlIGlkZW50aWZpZWQgYnkgdGhlIHJlc3BlY3RpdmUNCiAgICAg ICB2YWx1ZXMgZm9yDQogICAgICAgPiB0aGUgTlNIIE5leHQgUHJvdG9jb2wgZmllbGQgKHRvIGJl IGFzc2lnbmVkIGJ5IElBTkEpLCBhcw0KICAgICAgIHdlbGwgYXMgc28gZmFyDQogICAgICAgPiBu byBPQU0tc3BlY2lmaWMgbWV0YSBkYXRhIFRMViBoYXMgYmVlbiB5ZXQgZGVmaW5lZC4NCiAgICAg ICA+DQogICAgICAgPiBTbyB3ZSBoYXZlIEkgYmVsaWV2ZSBzb2xpZCBzb2x1dGlvbiBhbmQgcGF0 aCBmb3J3YXJkIGFuZCBJDQogICAgICAgc3VwcG9ydA0KICAgICAgID4gZGVwcmVjYXRpbmcgdGhl IE8gYml0Lg0KICAgICAgID4NCiAgICAgICA+IEtpbmQgUmVnYXJkcw0KICAgICAgID4NCiAgICAg ICA+IEd5YW4NCiAgICAgICA+DQogICAgICAgPiBPbiBXZWQsIEZlYiAyLCAyMDIyIGF0IDU6NDIg UE0gR3JlZyBNaXJza3kNCiAgICAgICA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVn aW1pcnNreUBnbWFpbC5jb20+IDxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPg0KICAgICAg ID4gPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20NCiAgICAgICA8bWFpbHRvOmdyZWdpbWly c2t5QGdtYWlsLmNvbT4+PiB3cm90ZToNCiAgICAgICA+DQogICAgICAgPiAgICAgVGhhbmsgeW91 LCBKaW0gYW5kIEpvZWwsIGZvciBndWlkaW5nIHRoZSBTRkMgT0FNIHdvcmsNCiAgICAgICBhbmQg cG9pbnRpbmcNCiAgICAgICA+ICAgICBvdXQgdGhlIGlzc3VlIHRoYXQgbXVzdCBiZSBhZGRyZXNz ZWQuDQogICAgICAgPg0KICAgICAgID4gICAgIEkndmUgcmV2aWV3ZWQgb3VyIFNGQyBPQU0gZG9j dW1lbnRzIGFuZA0KICAgICAgIGRyYWZ0LWlldGYtc2ZjLW5zaC10bHYuIEFzIEkNCiAgICAgICA+ ICAgICB1bmRlcnN0YW5kIHRoZXNlIGRvY3VtZW50cywgdGhlIEFjdGl2ZSBTRkMgT0FNIGFuZCBJ T0FNIGFyZQ0KICAgICAgID4gICAgIGlkZW50aWZpZWQgYnkgdGhlIHJlc3BlY3RpdmUgdmFsdWVz IGZvciB0aGUgTlNIIE5leHQNCiAgICAgICBQcm90b2NvbCBmaWVsZA0KICAgICAgID4gICAgICh0 byBiZSBhc3NpZ25lZCBieSBJQU5BKS4gQXQgdGhlIHNhbWUgdGltZSwgc28gZmFyIG5vDQogICAg ICAgT0FNLXNwZWNpZmljDQogICAgICAgPiAgICAgbWV0YSBkYXRhIFRMViBoYXMgYmVlbiBkZWZp bmVkLiBUaHVzLCBpdCBhcHBlYXJzIHRoYXQNCiAgICAgICBvbmUgd2F5DQogICAgICAgPiAgICAg Zm9yd2FyZCBjb3VsZCBiZSB0byBub3QgaW52b2x2ZSB0aGUgTyBiaXQgaW4gdGhlIGFjdGl2ZQ0K ICAgICAgIFNGQyBPQU0gb3INCiAgICAgICA+ICAgICBJT0FNIGFsdG9nZXRoZXIuIEluIG90aGVy IHdvcmRzLCB0byBkZXByZWNhdGUgdGhlIE5TSCBPIGJpdC4NCiAgICAgICA+DQogICAgICAgPiAg ICAgSSBncmVhdGx5IGFwcHJlY2lhdGUgeW91ciBjb21tZW50cyBvbiB0aGUgcHJvcG9zYWwgdG8N CiAgICAgICBkZXByZWNhdGUgdGhlDQogICAgICAgPiAgICAgTlNIIE8gYml0Lg0KICAgICAgID4N CiAgICAgICA+ICAgICBSZWdhcmRzLA0KICAgICAgID4gICAgIEdyZWcNCiAgICAgICA+DQogICAg ICAgPiAgICAgT24gV2VkLCBGZWIgMiwgMjAyMiBhdCAxMDozNiBBTSBKYW1lcyBHdWljaGFyZA0K ICAgICAgID4gICAgIDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208bWFpbHRvOmphbWVz Lm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4NCiAgICAgICA8bWFpbHRvOmphbWVzLm4uZ3VpY2hh cmRAZnV0dXJld2VpLmNvbT4NCiAgICAgICA+ICAgICA8bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRA ZnV0dXJld2VpLmNvbQ0KICAgICAgIDxtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWku Y29tPj4+IHdyb3RlOg0KICAgICAgID4NCiAgICAgICA+ICAgICAgICAgSGkgV0c6X19fXw0KICAg ICAgID4NCiAgICAgICA+ICAgICAgICAgX18gX18NCiAgICAgICA+DQogICAgICAgPiAgICAgICAg IEhhdmluZyByZXZpZXdlZCBhbGwgb2YgdGhlIE9BTSByZWxhdGVkIGRvY3VtZW50cyBpbg0KICAg ICAgIG91ciBXRywgdGhlDQogICAgICAgPiAgICAgICAgIGNoYWlycyB3b3VsZCBsaWtlIHRvIHBy b3ZpZGUgYSBmZXcgY29tbWVudHMgdG8gaG9wZWZ1bGx5DQogICAgICAgPiAgICAgICAgIGdlbmVy YXRlIGRpc2N1c3Npb24gYW5kIGZvcndhcmQgcHJvZ3Jlc3Mgb2YgdGhpcw0KICAgICAgIHdvcms6 X19fXw0KICAgICAgID4NCiAgICAgICA+ICAgICAgICAgX18gX18NCiAgICAgICA+DQogICAgICAg PiAgICAgICAgIDEpIFRoZSBjaGFpcnMgaGF2ZSByZXZpZXdlZCB0aGUgTyBiaXQgZGVmaW5pdGlv biBpbg0KICAgICAgIFJGQyA4MzAwLg0KICAgICAgID4gICAgICAgICBUaGF0IGRlZmluaXRpb24g aXMgYXQgYmVzdCBvcGVuIHRvIGludGVycHJldGF0aW9uDQogICAgICAgYW5kIHRoZXJlZm9yZQ0K ICAgICAgID4gICAgICAgICBpbmNvbXBsZXRlLiAgRm9yIGV4YW1wbGUsIHRoZSBjbGVhciBpbnRl bnRpb24gaXMNCiAgICAgICBvbmx5IHRvIG1hcmsNCiAgICAgICA+ICAgICAgICAgcGFja2V0cyB3 aGljaCBhcmUgaW50ZW5kZWQgZm9yIFNGQyBPQU0gYXQgdGhlIFNGQw0KICAgICAgIHNlcnZpY2UN CiAgICAgICA+ICAgICAgICAgbGF5ZXIuICBCdXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgY3VycmVu dCB0ZXh0IHNheXMuICAgICAgICAgVGhlcmUgaXMNCiAgICAgICA+ICAgICAgICAgYWxzbywgdW5m b3J0dW5hdGVseSwgYW1iaWd1aXR5IGFzIHRvIHdoYXQNCiAgICAgICBjb25zdGl0dXRlcyBhbiBP QU0NCiAgICAgICA+ICAgICAgICAgcGFja2V0LiAgU28gaXQgaXMgcmVhc29uYWJsZSBmb3IgZG9j dW1lbnRzIHRvIHVwZGF0ZQ0KICAgICAgIDgzMDAgdG8NCiAgICAgICA+ICAgICAgICAgY2xhcmlm eSB0aGUgZXhhY3QgYXBwbGljYWJpbGl0eSBhbmQgYWN0aW9uIGZvciB0aGUNCiAgICAgICBPLWJp dC5fX19fDQogICAgICAgPg0KICAgICAgID4gICAgICAgICBfXyBfXw0KICAgICAgID4NCiAgICAg ICA+ICAgICAgICAgMikgSG93ZXZlciwgcmVsYXRlZCB0byBwb2ludCAxKSwgd2UgY2FuJ3QgaGF2 ZSBtdWx0aXBsZQ0KICAgICAgID4gICAgICAgICBkb2N1bWVudHMgdXBkYXRpbmcgdGhlIGRlZmlu aXRpb24gZGlmZmVyZW50bHkuICBBcw0KICAgICAgIHN1Y2gsIHRoZQ0KICAgICAgID4gICAgICAg ICBhdXRob3JzIG9mIHRoZSBTRkMgaU9BTSBkcmFmdCBhbmQgdGhlIFNGQw0KICAgICAgIG11bHRp LWxheWVyLW9hbSBkcmFmdA0KICAgICAgID4gICAgICAgICBuZWVkIHRvIGNvbWUgdG9nZXRoZXIg YW5kIGZpZ3VyZSBvdXQgd2hhdCB0aGUNCiAgICAgICBjbGFyaWZpY2F0aW9uIGlzDQogICAgICAg PiAgICAgICAgIGZvciB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IGJpdC4gV2UgZG8gbm90IGJlbGll dmUgYXMNCiAgICAgICBjaGFpcnMgdGhhdA0KICAgICAgID4gICAgICAgICBlaXRoZXIgb2YgdGhl c2UgZG9jdW1lbnRzIGNhbiBtb3ZlIGZvcndhcmQgZnJvbSB0aGUNCiAgICAgICBXRyB1bnRpbA0K ICAgICAgID4gICAgICAgICBzdWNoIGNsYXJpdHkgaGFzIGJlZW4gcmVhY2hlZC4gX19fXw0KICAg ICAgID4NCiAgICAgICA+ICAgICAgICAgX18gX18NCiAgICAgICA+DQogICAgICAgPiAgICAgICAg IDMpIFJlbGF0ZWQgdG8gdGhlIFNGQyBpT0FNLCB3ZSBuZWVkIGEgY2xlYXINCiAgICAgICBkZWZp bml0aW9uIG9mIGlPQU0uDQogICAgICAgPiAgICAgICAgIFRoZXJlIHNlZW0gdG8gYmUgZGlmZmVy ZW5jZXMgYmV0d2VlbiB0aGUgZGVmaW5pdGlvbnMgaW4NCiAgICAgICA+ICAgICAgICAgcHVibGlz aGVkIFJGQ3MsIHRoZSB1c2FnZSAod2hpY2ggaXMgbm90IGENCiAgICAgICBkZWZpbml0aW9uKSBp biB0aGUgU0ZDDQogICAgICAgPiAgICAgICAgIGRyYWZ0LCBhbmQgdGhlIHZhcmlvdXMgaXBwbSBk cmFmdHMuICBBbnkgc3VjaA0KICAgICAgIGRlZmluaXRpb24gd2lsbA0KICAgICAgID4gICAgICAg ICBuZWVkIHRvIGJlIHZldHRlZCB3aXRoIHRoZSBpcHBtIHdvcmtpbmcgZ3JvdXAuX19fXw0KICAg ICAgID4NCiAgICAgICA+ICAgICAgICAgX18gX18NCiAgICAgICA+DQogICAgICAgPiAgICAgICAg IEFnYWluLCBpdCB3b3VsZCBiZSBnb29kIGlmIG1lbWJlcnMgb2YgdGhlIHdvcmtpbmcNCiAgICAg ICBncm91cCBiZXlvbmQNCiAgICAgICA+ICAgICAgICAgdGhlIHR3byBhdXRob3IgdGVhbXMgc3Bv a2UgdXAgYWJvdXQgdGhlaXIgcmVhZGluZ3MNCiAgICAgICBvZiB0aGUNCiAgICAgICA+ICAgICAg ICAgZG9jdW1lbnRzLCBhbmQgdGhlaXIgdW5kZXJzdGFuZGluZ3Mgb2Ygd2hhdCB3ZSBuZWVkLl9f X18NCiAgICAgICA+DQogICAgICAgPiAgICAgICAgIF9fIF9fDQogICAgICAgPg0KICAgICAgID4g ICAgICAgICBZb3VycyxfX19fDQogICAgICAgPg0KICAgICAgID4gICAgICAgICBKaW0gYW5kIEpv ZWxfX19fDQogICAgICAgPg0KICAgICAgID4gICAgICAgICBfXyBfXw0KICAgICAgID4NCiAgICAg ICA+ICAgICAgICAgX18gX18NCiAgICAgICA+DQogICAgICAgPiAgICAgICAgIF9fIF9fDQogICAg ICAgPg0KICAgICAgID4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KICAgICAgID4gICAgICAgICBzZmMgbWFpbGluZyBsaXN0DQogICAgICAg PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ IDxtYWlsdG86c2ZjQGlldGYub3JnDQogICAgICAgPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KICAg ICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCiAgICAgICA8 aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM+DQogICAgICAgPiAgICAg ICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KICAgICAgIDxo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYz4+DQogICAgICAgPg0KICAg ICAgID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogICAgICAgPiAgICAgc2ZjIG1haWxpbmcgbGlzdA0KICAgICAgID4gc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYub3JnPiA8bWFpbHRvOnNmY0BpZXRm Lm9yZw0KICAgICAgIDxtYWlsdG86c2ZjQGlldGYub3JnPj4NCiAgICAgICA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQogICAgICAgPGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPg0KICAgICAgID4gICAgIDxodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KICAgICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYz4+DQogICAgICAgPg0KICAgICAgID4gLS0NCiAgICAgICA+DQog ICAgICAgPiA8aHR0cDovL3d3dy52ZXJpem9uLmNvbS8gPGh0dHA6Ly93d3cudmVyaXpvbi5jb20v Pj4NCiAgICAgICA+DQogICAgICAgPiAqR3lhbiBNaXNocmEqDQogICAgICAgPg0KICAgICAgID4g L05ldHdvcmsgU29sdXRpb25zIEEvL3JjaGl0ZWN0IC8NCiAgICAgICA+DQogICAgICAgPiAvRW1h aWwgZ3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTxtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9u LmNvbT4NCiAgICAgICA8bWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20+DQogICAgICAg PG1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tDQogICAgICAgPG1haWx0bzpneWFuLnMu bWlzaHJhQHZlcml6b24uY29tPj4vLw0KICAgICAgID4gLw0KICAgICAgID4NCiAgICAgICA+IC9N IDMwMSA1MDItMTM0Nw0KICAgICAgID4NCiAgICAgICA+IC8NCiAgICAgICA+DQogICAgICAgPg0K DQotLQ0KDQo8aHR0cDovL3d3dy52ZXJpem9uLmNvbS8+DQoNCipHeWFuIE1pc2hyYSoNCi9OZXR3 b3JrIFNvbHV0aW9ucyBBLy9yY2hpdGVjdCAvDQovRW1haWwgZ3lhbi5zLm1pc2hyYUB2ZXJpem9u LmNvbTxtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbT4gPG1haWx0bzpneWFuLnMubWlz aHJhQHZlcml6b24uY29tPi8vDQovDQovTSAzMDEgNTAyLTEzNDcNCg0KLw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0K c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQoNCg== --_000_69B3DD8B1A6D4D07B41EA2958A117E33ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8124BBAB7944D0458FACCB4A3E0AE150@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkpvZWwsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5IYXBweSB0by48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk5vLCB0aGF0IGlzIG5vdCB3 aGF0IEkgbWVhbnQuIEkgYW0gbm90IHN1cmUgd2hlcmUgKG9yIHdoeSkgeW91IGFkZGVkIHRoZSB3 b3JkIOKAnGV4dGVybmFs4oCdLCBidXQgdGhhdCB3YXMga2V5IHRvIHNob3dpbmcgYSBkaXNjb25u ZWN0IChJIG1pZ2h0IG5vdCBoYXZlIGJlZW4gY2xlYXIgYW5kL29yIHlvdSBtaWdodCBub3QgaGF2 ZSByZWFkIGNvcnJlY3RseSkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5MZXQgbWUgdHJ5IGRpZmZlcmVudCB3YXk6PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjb2xv cj0iIzAwMDAwMCIgY2xhc3M9IiI+VGhlcmUgaXMgYW4gSS1EIG5vdywgc2ZjLW11bHRpLWxheWVy LW9hbSwgdGhhdCBzZW5kcyZuYnNwO+KAnFNGQyBBY3RpdmUgT0FNJnF1b3Q7IHBhY2tldHMgd2l0 aCBhIG5ldyBTRkMgbmV4dCBwcm90b2NvbCBmb3IgYSBuZXdseSBjcmVhdGVkIHByb3RvY29sLiBJ biB0aGlzIGNhc2UsIHRoZSBTRkMgbmV4dCBwcm90b2NvbCBpcyBub3QgZXhwZWN0ZWQgdG8gYmUg dXNlZCBpbiB1c2VyIHBhY2tldHMsDQogYXQgbGVhc3QgZm9yIG5vdyAob3IgcGVvcGxlIGhhdmUg bm90IHRob3VnaHQgYWJvdXQgdGhhdCBpbiZuYnNwO2hpZXJhcmNoaWNhbCZuYnNwO2Nhc2VzKTwv Zm9udD48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW1hZ2luZSBub3cgdGhh dCBCRkQgb3IgSUNNUCB3YW50IHRvIGJlIHVzZWQgYXMgYW4gU0ZDIEFjdGl2ZSBPQU0gcHJvdG9j b2xzLCBpbnN0ZWFkIG9mIHRoZSZuYnNwOzxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyIgY2xhc3M9IiI+c2ZjLW11bHRpLWxheWVyLW9h bSBvbmU8L3NwYW4+LiBUaG9zZSBjYW4gYmUgZW5jYXBzdWxhdGVkIGluIElQIChldmVuIHdpdGgg YSAxMjcvOA0KIGRlc3RpbmF0aW9uKS4gVXNpbmcgdGhlIE8tYml0IHNldCBhbmQgU0ZDIE5QIGFz IElQIGlzIHRoZSBSRkMgODMwMCBleHBlY3RlZCB3YXkuIChJIGltYWdpbmUmbmJzcDs8c3BhbiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsiIGNs YXNzPSIiPmNyZWF0aW5nIGEgbmV3IFNGQyBuZXh0IHByb3RvY29sIGZvciDigJxCRkQtaW4tSVAt dXNlZC1pbi1TRkPigJ0gc28gYXMgdG8gYXZvaWQgYW4gU0ZDIE5QIGV4cGVjdGVkDQogb24gZXh0 ZXJuYWwgcGFja2V0cyB3b3VsZCBiZSBhbiBhcHByb2FjaCBpZiB0aGVyZSB3YXMgbm8gTy1iaXQg ZGVmaW5lZCk8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyIgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsiIGNsYXNzPSIiPkJlc3Qs PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N Cjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IiBjbGFzcz0iIj5DYXJsb3MuJm5ic3A7 PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjIvMTQvMjIg5Y2I5YmN NzowNeOAgUpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20iIGNsYXNzPSIiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0O+OBruODoeODvOODqzo8 L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj5UaGFuayB5b3UgZm9yIHRha2luZyB0aGUgdGltZSB0byBwcm92 aWRlIGEgY2FyZWZ1bCByZXBseS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdCBhcHBl YXJzLCBmcm9tIHlvdXIgZGVzY3JpcHRpb24gb2YgSUNNUCBwYWNrZXRzIHRoYXQgeW91ciB1bmRl cnN0YW5kaW5nIG9mIDgzMDAgaXMgdGhhdCBpbiBTRkMgYW4gZXh0ZXJuYWwgSUNNUCBwYWNrZXQg d2lsbCBnZXQgdGhlIE8gYml0IHNldCBpbiB0aGUgTlNIIGhlYWRlci4gJm5ic3A7UHJlc3VtYWJs eSwgYmFzZSBvbiB0aGlzLCB0aGUgU0ZGIG9yIFNGIGFyZSBzdXBwb3NlZCB0byBsb29rIHRocm91 Z2ggYW5kIG5vdGljZSB0aGlzIGNvbnRlbnQ/DQogJm5ic3A7Jm5ic3A7KE90aGVyd2lzZSwgd2h5 IHNldCB0aGUgYml0PykgJm5ic3A7VGhpcyBzZWVtcyBhbiB1bmRlc2lyYWJsZSBhbmQgZXhwZW5z aXZlIGltcGxpY2F0aW9ucyB3aGljaCBvdGhlciByZWFkZXJzIGhhdmUgbm90IGRyYXduIGZyb20g dGhlIFJGQyA4MzAwIHRleHQuICZuYnNwOyhJdCBhbHNvIHJlcXVpcmVzIHRoZSBlbmNhcHN1bGF0 aW5nIG5vZGUgdG8gZG8gZXh0cmEgY2hlY2tpbmcgdG8gZGlzY292ZXIgdGhpcyBjYXNlLik8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBbSBJIHJlYWRpbmcgeW91ciBleHBlY3RhdGlvbiBj b3JyZWN0bHk/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KWW91cnMsPGJyIGNsYXNzPSIi Pg0KSm9lbDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDIvMTMvMjAyMiAxMTowNiBQ TSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPlJlcGx5aW5nIHRvIHRoaXMgc3BlY2lmaWMgZW1h aWwgaW4gdGhlIHRocmVhZCwgb25seSBiZWNhdXNlIGl0IGlzIHRoZSBsYXRlc3Qgb25lIGF0IHRo aXMgcG9pbnQgaW4gdGltZSwgYnV0IGJ1bmRsaW5nIGNvbW1lbnRzIGZyb20gdmFyaW91cyBwbGFj ZXMgb24gdGhlIHRocmVhZC4gUGxlYXNlIGZpbmQgc29tZSBmb2xsb3ctdXAgY29tbWVudHMgYW5k IHF1ZXN0aW9ucyBtYXJrZWQg4oCcQ01Q4oCdLA0KIGluZGljYXRpbmcgdGhlIOKAnEZyb23igJ0s IGFuZCBvcmdhbml6ZWQgY2hyb25vbG9naWNhbGx5OjxiciBjbGFzcz0iIj4NCipKYW1lcyBOIEd1 aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29t IiBjbGFzcz0iIj5qYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208L2E+ICZsdDs8YSBocmVm PSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tIiBjbGFzcz0iIj5tYWlsdG86 amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPC9hPiZndDsmZ3Q7Oio8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4xKSBUaGUgY2hhaXJzIGhhdmUgcmV2 aWV3ZWQgdGhlIE8gYml0IGRlZmluaXRpb24gaW4gUkZDIDgzMDAuJm5ic3A7IFRoYXQgZGVmaW5p dGlvbiBpcyBhdCBiZXN0IG9wZW4gdG8gaW50ZXJwcmV0YXRpb24gYW5kIHRoZXJlZm9yZSBpbmNv bXBsZXRlLiZuYnNwOyBGb3IgZXhhbXBsZSwgdGhlIGNsZWFyIGludGVudGlvbiBpcyBvbmx5IHRv IG1hcmsgcGFja2V0cyB3aGljaCBhcmUgaW50ZW5kZWQgZm9yIFNGQw0KIE9BTSBhdCB0aGUgU0ZD IHNlcnZpY2UgbGF5ZXIuJm5ic3A7IEJ1dCB0aGF0IGlzIG5vdCB3aGF0IHRoZSBjdXJyZW50IHRl eHQgc2F5cy4mbmJzcDsgVGhlcmUgaXMgYWxzbywgdW5mb3J0dW5hdGVseSwgYW1iaWd1aXR5IGFz IHRvIHdoYXQgY29uc3RpdHV0ZXMgYW4gT0FNIHBhY2tldC4mbmJzcDsgU28gaXQgaXMgcmVhc29u YWJsZSBmb3IgZG9jdW1lbnRzIHRvIHVwZGF0ZSA4MzAwIHRvIGNsYXJpZnkgdGhlIGV4YWN0IGFw cGxpY2FiaWxpdHkgYW5kIGFjdGlvbiBmb3IgdGhlDQogTy1iaXQuPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KQ01QOiBJdCBpcyB1bmNsZWFyIHRvIG1lIHdoYXQgZXhhY3QgaXNzdWVzIHRo ZSBjaGFpcnMgYXJlIGNhbGxpbmcgb3V0LiBUaGVyZSBhcmUgdHdvIGlzc3VlcyBtZW50aW9uZWQ6 PGJyIGNsYXNzPSIiPg0KQ01QOiAxLiAmcXVvdDtCdXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgY3Vy cmVudCB0ZXh0IHNheXMu4oCdIOKAlCZndDsgd2hhdCBkb2VzIHRoZSB0ZXh0IHNheSBwcmVjaXNl bHk/ICZuYnNwO0NhbiB5b3UgcG9pbnQgdG8gdGhlIHNwZWNpZmljIFJGQyA4MzAwIHRleHQgdGhh dCBpcyBiZWxpZXZlZCB0byBiZSBpbmNvbXBsZXRlLCBhbmQgYSBkZXRhaWxlZCB1c2UgY2FzZSB0 aGF0IHNob3djYXNlcyB0aGUgcG90ZW50aWFsIGlzc3VlPyBBbiBleHRyYXBvbGF0ZWQgY291bnRl ci1leGFtcGxlDQoganVzdCB0byBtYWtlIGEgcG9pbnQ6IHRoZSB0ZXh0IGRvZXMgbm90ICZuYnNw O3NheSB3aGF0IGRheXMgb2YgdGhlIHdlZWsgT0FNIHBhY2tldHMgY2FuIGJlIG1hcmtlZCwgeWV0 IHRoZXJl4oCZcyBhbiBleHBlY3RhdGlvbiB0aGF0IHRoZXkgd2lsbCB3b3JrIE1vbmRheXMgYW5k IFNhdHVyZGF5cyBhbGwgdGhlIHNhbWUg4oCUIGV2ZW4gaG9saWRheXMuPGJyIGNsYXNzPSIiPg0K Q01QOiAyLiBXaGF0IHNwZWNpZmljYWxseSBpcyB0aGUgYW1iaWd1aXR5IHdpdGggd2hhdCBhbiBP QU0gcGFja2V0IGlzPyBQbGVhc2UgZ3JlcCB0aGUgUkZDIHNlcmllcyBmb3Ig4oCcb2FtIHBhY2tl dOKAnSwgaXQgaXMgbm90IGEgbmV3IHRlcm0uPGJyIGNsYXNzPSIiPg0KQ01QOiBOZXQtbmV0LCBP LWJpdD0xLCBPQU0gcGFja2V0LjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPjIpIEhvd2V2ZXIsIHJlbGF0ZWQgdG8gcG9pbnQgMSksIHdlIGNhbid0IGhhdmUg bXVsdGlwbGUgZG9jdW1lbnRzIHVwZGF0aW5nIHRoZSBkZWZpbml0aW9uIGRpZmZlcmVudGx5LiZu YnNwOyBBcyBzdWNoLCB0aGUgYXV0aG9ycyBvZiB0aGUgU0ZDIGlPQU0gZHJhZnQgYW5kIHRoZSBT RkMgbXVsdGktbGF5ZXItb2FtIGRyYWZ0IG5lZWQgdG8gY29tZSB0b2dldGhlciBhbmQgZmlndXJl IG91dCB3aGF0IHRoZQ0KIGNsYXJpZmljYXRpb24gaXMgZm9yIHRoZSBkZWZpbml0aW9uIG9mIHRo YXQgYml0LiBXZSBkbyBub3QgYmVsaWV2ZSBhcyBjaGFpcnMgdGhhdCBlaXRoZXIgb2YgdGhlc2Ug ZG9jdW1lbnRzIGNhbiBtb3ZlIGZvcndhcmQgZnJvbSB0aGUgV0cgdW50aWwgc3VjaCBjbGFyaXR5 IGhhcyBiZWVuIHJlYWNoZWQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KQ01QOiBJZiB0 aGVyZSBpcyBzdGlsbCBiZWxpZXZlZCB0byBiZSBhbiBhbWJpZ3VpdHkgb3IgYSBjbGVhciBvcHBv cnR1bml0eSBmb3IgaW1wcm92aW5nIHRoZSBkZWZpbml0aW9uLCBJIGFncmVlIHdpdGggY29uc29s aWRhdGluZyB0aGF0IHVwZGF0ZS4gSSBoYWQgc3VnZ2VzdGVkIGJlZm9yZSB0aGF0IGlmIHN1Y2gg bmV3IHRleHQgb3IgcmVhbCBjbGFyaWZpY2F0aW9uIGlzIGFncmVlZCwgYSBzZXBhcmF0ZSBkb2N1 bWVudCB0aGF0IG9ubHkgbWFrZXMNCiB0aGF0IE8tYml0IGNsYXJpZmljYXRpb24gaXMgdGhlIG1v c3QgY2xlYXIgYW5kIGNsZWFuIHdheSB0byBnby4gVGhhdCBkb2Mgc2hvdWxkIGJlIGEgb25lLXBh Z2VyIG9yIGxlc3MuIEnigJlkIGJlIGhhcHB5IHRvIGNvbnRyaWJ1dGUgdG8gdGhhdCBtaW5pbWFs IGRvYywgaWYgaXQgaXMgc2hvd24gdG8gYmUgbmVlZGVkLjxiciBjbGFzcz0iIj4NCkNNUDogRm9y IGNvbXBsZXRlbmVzcyBhbHNvLCB0aGUgJnF1b3Q7U0ZDIG11bHRpLWxheWVyLW9hbeKAnSBkb2N1 bWVudCBoYXMgbWFueSBvdXRzdGFuZGluZyBpc3N1ZXMgYmVzaWRlcyB0aGUgTy1iaXQuPGJyIGNs YXNzPSIiPg0KKkdyZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21h aWwuY29tIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiBjbGFzcz0iIj5tYWlsdG86Z3JlZ2ltaXJza3lA Z21haWwuY29tPC9hPiZndDsmZ3Q7KjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPkkndmUgcmV2aWV3ZWQgb3VyIFNGQyBPQU0gZG9jdW1lbnRzIGFuZCBkcmFm dC1pZXRmLXNmYy1uc2gtdGx2LiBBcyBJIHVuZGVyc3RhbmQgdGhlc2UgZG9jdW1lbnRzLCB0aGUg QWN0aXZlIFNGQyBPQU0gYW5kIElPQU0gYXJlIGlkZW50aWZpZWQgYnkgdGhlIHJlc3BlY3RpdmUg dmFsdWVzIGZvciB0aGUgTlNIIE5leHQgUHJvdG9jb2wgZmllbGQgKHRvIGJlIGFzc2lnbmVkIGJ5 IElBTkEpLg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KQ01QOiBUaGVyZSBpcyBhIG1h am9yIGlzc3VlIHdpdGggdGhlIHNlbnRlbmNlIGFib3ZlLiBBY3RpdmUgU0ZDIE9BTSAoYXMgYSBj YXRlZ29yeSksIGFzIHBlciBSRkMgODMwMCwgbmVlZHMgdG8gYmUgaWRlbnRpZmllZCBieSBzZXR0 aW5nIHRoZSBPLWJpdC4gTm8gd2F5IGFyb3VuZCB0aGF0IGJhc2VkIG9uIFJGQyA4MzAwLiBIb3dl dmVyLCB0aGUgdGV4dCAmcXVvdDt0aGUgQWN0aXZlIFNGQyBPQU3igJ0gY3JlYXRlcyBjb25mdXNp b24gc2luY2UgaXQgcmVmZXINCiB0byBhIHNwZWNpZmljIE9BTSBwcm90b2NvbCB3aGljaCBoYXMg dGhlIHNhbWUgbmFtZSBhcyBhIHRoZSBjYXRlZ29yeSBhcyB3ZWxsLiBUaGF0IG5hbWUgY29sbGlz aW9uIGlzIHF1aXRlIHVuZm9ydHVuYXRlIGluIG15IG9waW5pb24uPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+QXQgdGhlIHNhbWUgdGltZSwgc28gZmFyIG5v IE9BTS1zcGVjaWZpYyBtZXRhIGRhdGEgVExWIGhhcyBiZWVuIGRlZmluZWQuIFRodXMsIGl0IGFw cGVhcnMgdGhhdCBvbmUgd2F5IGZvcndhcmQgY291bGQgYmUgdG8gbm90IGludm9sdmUgdGhlIE8g Yml0IGluIHRoZSBhY3RpdmUgU0ZDIE9BTSBvciBJT0FNIGFsdG9nZXRoZXIuIEluIG90aGVyIHdv cmRzLCB0byBkZXByZWNhdGUgdGhlIE5TSA0KIE8gYml0LjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCkNNUDogUkZDIDg5MjQgYWxyZWFkeSBpbmNsdWRlcyBJQ01QIGFuZCBCRkQgYXMgZXhh bXBsZSBTRkMgQWN0aW9uIE9BTSBwcm90b2NvbHMuIFRob3NlIGNhbiBiZSBlbmNhcHN1bGF0ZWQg aW4gSVAsIGluIHdoaWNoIHRoZSBOZXh0LVByb3RvY29sIGluZGljYXRlcyBJUCDigJQgYW5kIChh cyBwZXIgUkZDIDgzMDApIHRoZSBPLWJpdCBpcyBzZXQgdG8gaW5kaWNhdGUgYW4gT0FNIHBhY2tl dC48YnIgY2xhc3M9IiI+DQpDTVA6IFRoZSBwcm9wb3NhbCBvZiBkZXByZWNhdGluZyB0aGUgTy1i aXQgYnJlYWtzIHRob3NlIFNGQyBPQU0gcHJvdG9jb2xzIGFscmVhZHkgaW5jbHVkZWQgaW4gYW4g UkZDLjxiciBjbGFzcz0iIj4NCkNNUDogVGhhdCBwcm9wb3NhbCBvZiBkZXByZWNhdGluZyB0aGUg Ty1iaXQgYWxzbyBicmVha3MgU2VjdGlvbiA0LjEgb2YgSU9BTS48YnIgY2xhc3M9IiI+DQpDTVA6 IFRoaXMgZXhwaXJlZCBJLUQgeWV0IGltcGxlbWVudGVkIGluIG9wZW4gc291cmNlIHVzZXMgdGhl IE8tYml0OiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXBl bm5vLXNmYy10cmFjZS0wMy50eHQiIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJj aGl2ZS9pZC9kcmFmdC1wZW5uby1zZmMtdHJhY2UtMDMudHh0PC9hPiAmbHQ7PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1wZW5uby1zZmMtdHJhY2UtMDMudHh0 IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXBlbm5vLXNm Yy10cmFjZS0wMy50eHQ8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCipHeWFuIE1pc2hyYSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbSIgY2xhc3M9IiI+aGF5YWJ1c2Fnc21A Z21haWwuY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbSIg Y2xhc3M9IiI+bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0Oyo8YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5JIGFncmVlIHRoYXQgd2hh dCBtYWtlcyBzZW5zZSB0byBtZSBhcyBhIHBhdGggZm9yd2FyZCBpcyB0byBkZXByZWNhdGUgdGhl IE8gYml0IGFuZCBub3QgdXNlIGluIFNGQyBNdWx0aWxheWVyIE9BTSBhbmQgU0ZDIElPQU0sIGFz IGJvdGggU0ZDIE11bHRpbGF5ZXImbmJzcDtPQU0gYW5kIFNGQyZuYnNwO0lPQU0gYXJlIGlkZW50 aWZpZWQgYnkgdGhlIHJlc3BlY3RpdmUgdmFsdWVzIGZvciB0aGUgTlNIIE5leHQNCiBQcm90b2Nv bCBmaWVsZCAodG8gYmUgYXNzaWduZWQgYnkgSUFOQSksIGFzIHdlbGwgYXMgc28gZmFyIG5vIE9B TS1zcGVjaWZpYyBtZXRhIGRhdGEgVExWIGhhcyBiZWVuIHlldCBkZWZpbmVkLjxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCkNNUDogV2hhdCBpcyB0aGUg4oCcU0ZDIE11bHRpbGF5ZXIgT0FN 4oCdPzxiciBjbGFzcz0iIj4NCkNNUDogVGhlIE8tYml0IChyZWFkaW5nIFJGQyA4MzAwKSBkb2Vz IG5vdCBpbmRpY2F0ZSBpZiB0aGVyZSBpcyBPQU0gTWV0YWRhdGEuIEl0IGluZGljYXRlcyBhbiBP QU0gcGFja2V0LjxiciBjbGFzcz0iIj4NCiomcXVvdDtKb2VsIE0uIEhhbHBlcm4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiBjbGFzcz0iIj5qbWhAam9lbGhh bHBlcm4uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIGNs YXNzPSIiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7KjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkFzIGZhciBhcyBJIGNhbiB0ZWxs LCBpZiB3ZSBkZXByZWNhdGUgdGhlIE8tYml0IGFuZCByZWx5IG9uIHRoZSBuZXh0IHByb3RvY29s IGZpZWxkLCB3ZSBhcmUgc2F5aW5nIHRoYXQgaW4gcHJhY3RpY2UgKG5vdCBieSBydWxlKSBOU0gg bWV0YWRhdGEgY2FuIG5vdCBiZSB1c2VkIGZvciBPQU0uICZuYnNwO1RoYXQncyBmaW5lIHdpdGgg bWUgYXMgbG9uZyBhcyB3ZSBhZ3JlZSBvbiB0aGF0LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCkNNUDogSSBkbyBub3QgZnVsbHkgZm9sbG93IHRoaXMuIENhbiB5b3UgZXhwbGFpbiB0aGUg cmVsYXRpb25zaGlwIG9mIHRoZSBPLWJpdCB3aXRoIE1ldGFkYXRhPzxiciBjbGFzcz0iIj4NCkNN UDogSGVyZeKAmXMgYW4gZXhhbXBsZTogUkZDIDg5MjQgc2hvd3MgSUNNUCBhcyBBY3RpdmUgT0FN LiBUaGUgU0ZDIG5leHQgcHJvdG9jb2wgaXMgSVAsIHRoZSBJUCBuZXh0IHByb3RvY29sIGlzIElD TVAsIHRoZSBPLWJpdCBuZWVkcyB0byBiZSBzZXQuPGJyIGNsYXNzPSIiPg0KQ01QOiBDb25zaWRl ciB0aGUgZm9sbG93aW5nIGRvY3VtZW50LCBpbmRlcGVuZGVudCBzdWJtaXNzaW9uIGFuZCBpbiB0 aGUgUkZDIFB1YmxpY2F0aW9uIHF1ZXVlIGFscmVhZHk6PGJyIGNsYXNzPSIiPg0KQ01QOiA8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1teW1iLXNmYy1uc2gt YWxsb2NhdGlvbi10aW1lc3RhbXAvIiBjbGFzcz0iIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LW15bWItc2ZjLW5zaC1hbGxvY2F0aW9uLXRpbWVzdGFtcC88L2E+ICZs dDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1teW1iLXNm Yy1uc2gtYWxsb2NhdGlvbi10aW1lc3RhbXAvIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1teW1iLXNmYy1uc2gtYWxsb2NhdGlvbi10aW1lc3RhbXAvPC9h PiZndDs8YnIgY2xhc3M9IiI+DQpDTVA6IElzIGEgVGltZXN0YW1wIGluIE1ldGFkYXRhIGFuIE9B TSBlbGVtZW50PzxiciBjbGFzcz0iIj4NCkNNUDogQ29uc2lkZXIgdGhpcyBwcm9wb3NhbCA8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktc2ZjLXBt YW1tLyIgY2xhc3M9IiI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1t aXJza3ktc2ZjLXBtYW1tLzwvYT4gJmx0OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LW1pcnNreS1zZmMtcG1hbW0vIiBjbGFzcz0iIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktc2ZjLXBtYW1tLzwvYT4mZ3Q7PGJyIGNs YXNzPSIiPg0KQ01QOiBXaGVyZSB0aGUgYmFzZSBoZWFkZXIgYm9ycm93cyBhIGJpdCBmb3IgYW4g T0FNIGZ1bmN0aW9uLjxiciBjbGFzcz0iIj4NCkNNUDogTmVpdGhlciBvZiB0aG9zZSBoYXZlIGFu eSBpbXBhY3Qgb24gdGhlIE8tYml0LjxiciBjbGFzcz0iIj4NCipHcmVnIE1pcnNreSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgY2xhc3M9IiI+Z3JlZ2ltaXJza3lA Z21haWwuY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIg Y2xhc3M9IiI+bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0Oyo8YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5JIGFncmVlIHRoYXQsIGFz IHdlIGZpbmQgU0ZDIE5TSCBub3csIG5vIE9BTSBtZXRhZGF0YSBoYXMgYmVlbiBkZWZpbmVkLiBJ dCBhcHBlYXJzIHRvIG1lIHRoYXQgZGVwcmVjYXRpbmcgdGhlIE8gYml0IGRvZXMgbm90IGFmZmVj dCBhbnkgb2YgdGhlJm5ic3A7YWxyZWFkeSBkZWZpbmVkIG1lY2hhbmlzbXMgaW4gdGhlJm5ic3A7 U0ZDIE5TSC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpDTVA6IEl0IGFjdHVhbGx5IGRv ZXMsIHNlZSBteSBleGFtcGxlIGFib3ZlLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPkkgdGhpbmsgdGhhdCBpZiBhIG5ldywgZm9yIGV4YW1wbGUsIE1EIFR5 cGUgPSAyIFRMViB0aGF0Jm5ic3A7aXMgdXNlZCBmb3IgYW55IE9BTSBmdW5jdGlvbmFsaXR5IHRv IGJlIHByb3Bvc2VkIGluIHRoZSBmdXR1cmUsIGRlcHJlY2F0ZWQgdGhlIE8gYml0IHdvdWxkJm5i c3A7bm90IHByZXZlbnQgdXNpbmcgc3VjaCBOU0ggVExWLjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCkNNUDogSSBhZ3JlZSB3aXRoIHRoaXMg4oCUIGJlY2F1c2UgdGhlcmUgaXMgbm8gY29y cmVsYXRpb24gYmV0d2VlbiBNRCBUeXBlIGZpZWxkIGFuZCBPLWJpdCBhcyBkZWZpbmVkLjxiciBj bGFzcz0iIj4NCkJlc3QsPGJyIGNsYXNzPSIiPg0KQ2FybG9zLjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjIvMTMvMjIg5Y2I5b6MMTI6MzLjgIFHeWFuIE1p c2hyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbSIgY2xhc3M9IiI+ aGF5YWJ1c2Fnc21AZ21haWwuY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhheWFidXNhZ3Nt QGdtYWlsLmNvbSIgY2xhc3M9IiI+bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbTwvYT4mZ3Q7 Jmd0O+OBruODoeODvOODqzo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIaSBKb2VsPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhbSBpbiBhZ3JlZW1lbnQgYXMgd2VsbCB3aXRo IHdoYXQgeW91IGhhdmUgc3RhdGVkIHRoYXQgb25jZSB0aGUgTyBiaXQgaXMgZGVwcmVjYXRlZCB0 aGF0IE5TSCBtZXRhZGF0YSBjYW5ub3QgYmUgdXNlZCBmb3IgT0FNIGFuZCB0aGF0IHdlIHdvdWxk IGhhdmUgdG8gbm93IGZyb20gdGhhdCBwb2ludCBmb3J3YXJkIHJlbHkgb24gdGhlIG5leHQgcHJv dG9jb2wgZmllbGQgYXMgd2Ugd2lsbCBiZSBkb2luZyBmb3IgU0ZDIE11bHRpbGF5ZXIgYW5kIFNG Qw0KIElPQU0gZHJhZnRzIGFzIHdlbGwgYXMgd2lsbCBoYXZlIGJhY2t3YXJkcyBjb21wYXRpYmxl IHdpdGggYW55IGFscmVhZHkgZXhpc3RpbmcgZGVmaW5lZCBtZWNoYW5pc21zIGluIFNGQyBOU0gu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBkb27igJl0IHNlZSBhbnkgaXNzdWVzIG9y IGltcGFjdCB3aXRoIG1vdmluZyBmb3J3YXJkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CktpbmQgUmVnYXJkczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkd5YW48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiBTdW4sIEZlYiAxMywgMjAyMiBhdCAxMjowNCBQTSBHcmVn IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgY2xhc3M9 IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWly c2t5QGdtYWlsLmNvbSIgY2xhc3M9IiI+bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4m Z3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDtIaSBKb2VsLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO0kgYWdyZWUgdGhh dCwgYXMgd2UgZmluZCBTRkMgTlNIIG5vdywgbm8gT0FNIG1ldGFkYXRhIGhhcyBiZWVuPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ZGVmaW5lZC4gSXQgYXBwZWFycyB0byBtZSB0aGF0 IGRlcHJlY2F0aW5nIHRoZSBPIGJpdCBkb2VzIG5vdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwO2FmZmVjdCBhbnkgb2YgdGhlJm5ic3A7YWxyZWFkeSBkZWZpbmVkIG1lY2hhbmlzbXMg aW4gdGhlJm5ic3A7U0ZDIE5TSC4gSTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO3Ro aW5rIHRoYXQgaWYgYSBuZXcsIGZvciBleGFtcGxlLCBNRCBUeXBlID0gMiBUTFYgdGhhdCZuYnNw O2lzIHVzZWQgZm9yPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7YW55IE9BTSBmdW5j dGlvbmFsaXR5IHRvIGJlIHByb3Bvc2VkIGluIHRoZSBmdXR1cmUsIGRlcHJlY2F0ZWQgdGhlPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7TyBiaXQgd291bGQmbmJzcDtub3QgcHJldmVu dCB1c2luZyBzdWNoIE5TSCBUTFYuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7V2hh dCBkbyB5b3UgdGhpbms/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7UmVnYXJkcyw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtHcmVnPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7T24gU3VuLCBGZWIgMTMs IDIwMjIgYXQgNjo1NSBBTSBKb2VsIE0uIEhhbHBlcm48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDsmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIGNsYXNzPSIi PmptaEBqb2VsaGFscGVybi5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbSIgY2xhc3M9IiI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyZndDsg d3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlcmUgaXMgYW4gaW1wbGljYXRpb24gb2YgZGVwcmVjYXRp bmcgdGhlIE8tYml0IHRoYXQgSSB3b3VsZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2xpa2UgdG88YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtoZWFyIGZyb20gbW9yZSBXRyBwYXJ0aWNp cGFudHMgYWJvdXQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXMgZmFyIGFzIEkgY2FuIHRlbGwsIGlmIHdlIGRl cHJlY2F0ZSB0aGUgTy1iaXQgYW5kIHJlbHkgb248YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgbmV4dDxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Byb3RvY29sIGZpZWxkLCB3ZSBh cmUgc2F5aW5nIHRoYXQgaW4gcHJhY3RpY2UgKG5vdCBieSBydWxlKSBOU0g8YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDttZXRhZGF0YSBjYW4g bm90IGJlIHVzZWQgZm9yIE9BTS4mbmJzcDsgVGhhdCdzIGZpbmUgd2l0aCBtZSBhcyBsb25nPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YXMg d2U8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDthZ3JlZSBvbiB0aGF0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1lvdXJzLDxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0pvZWw8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtP biAyLzEzLzIwMjIgMjo1MiBBTSwgR3lhbiBNaXNocmEgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgSGkgSmltLCBK b2VsICZhbXA7IFNGQyBXRyw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBJIGFncmVlIHRoYXQgdGhlIFJGQyA4MzAwIGRlZmlu aXRpb24gb2YgTyBiaXQgaXMgaW5jb21wbGV0ZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FuZCBub3Q8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IGNsZWFyIGFzIHRvIGl0cyBp bnRlbmRlZCB1c2UuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZndDsgVGhhdCBpcyBhIHByb2JsZW0gdGhhdCBJIGFncmVlIG5lZWRz IHRvIGJlIHJlY3RpZmllZC48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBJIHVuZGVyc3RhbmQgdGhhdCB3ZSBuZWVkIHRvIGdl dCB0aGlzIHJlc29sdmVkIGJlZm9yZSB3ZSBjYW48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwcm9ncmVzczxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgTXVsdGlsYXllciBTRkMg T0FNIGRyYWZ0LWlldGYtc2ZjLW11bHRpLWxheWVyLW9hbS0xOCBhbmQgU0ZDPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SU9BTS48YnIgY2xh c3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0 OyBJIGFncmVlIHRoYXQgd2hhdCBtYWtlcyBzZW5zZSB0byBtZSBhcyBhIHBhdGggZm9yd2FyZCBp cyB0bzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO2RlcHJlY2F0ZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZndDsgdGhlIE8gYml0IGFuZCBub3QgdXNlIGluIFNGQyBNdWx0aWxheWVy IE9BTSBhbmQgU0ZDIElPQU0sIGFzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ym90aCBTRkM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IE11bHRpbGF5ZXIgT0FNIGFuZCBTRkMg SU9BTSBhcmUgaWRlbnRpZmllZCBieSB0aGUgcmVzcGVjdGl2ZTxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3ZhbHVlcyBmb3I8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IHRoZSBO U0ggTmV4dCBQcm90b2NvbCBmaWVsZCAodG8gYmUgYXNzaWduZWQgYnkgSUFOQSksIGFzPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7d2VsbCBh cyBzbyBmYXI8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmZ3Q7IG5vIE9BTS1zcGVjaWZpYyBtZXRhIGRhdGEgVExWIGhhcyBiZWVuIHlldCBk ZWZpbmVkLjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmZ3Q7IFNvIHdlIGhhdmUgSSBiZWxpZXZlIHNvbGlkIHNvbHV0aW9uIGFuZCBw YXRoIGZvcndhcmQgYW5kIEk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtzdXBwb3J0PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBkZXByZWNhdGluZyB0aGUgTyBiaXQuPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0Ozxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZn dDsgS2luZCBSZWdhcmRzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgR3lhbjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IE9uIFdlZCwgRmViIDIsIDIwMjIg YXQgNTo0MiBQTSBHcmVnIE1pcnNreTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21h aWwuY29tIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiBjbGFzcz0iIj5tYWlsdG86Z3JlZ2ltaXJza3lA Z21haWwuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21h aWwuY29tIiBjbGFzcz0iIj5tYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPjxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDs8YSBo cmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiBjbGFzcz0iIj5tYWlsdG86Z3JlZ2lt aXJza3lAZ21haWwuY29tPC9hPiZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7VGhhbmsgeW91LCBKaW0gYW5kIEpvZWwsIGZvciBndWlkaW5nIHRoZSBTRkMgT0FN IHdvcms8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDthbmQgcG9pbnRpbmc8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtvdXQgdGhlIGlzc3VlIHRo YXQgbXVzdCBiZSBhZGRyZXNzZWQuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0kndmUgcmV2 aWV3ZWQgb3VyIFNGQyBPQU0gZG9jdW1lbnRzIGFuZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2RyYWZ0LWlldGYtc2ZjLW5zaC10bHYuIEFz IEk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt1bmRlcnN0YW5kIHRoZXNlIGRvY3VtZW50cywgdGhl IEFjdGl2ZSBTRkMgT0FNIGFuZCBJT0FNIGFyZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2lkZW50 aWZpZWQgYnkgdGhlIHJlc3BlY3RpdmUgdmFsdWVzIGZvciB0aGUgTlNIIE5leHQ8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtQcm90b2NvbCBm aWVsZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyh0byBiZSBhc3NpZ25lZCBieSBJQU5BKS4gQXQg dGhlIHNhbWUgdGltZSwgc28gZmFyIG5vPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7T0FNLXNwZWNpZmljPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7bWV0YSBkYXRhIFRMViBoYXMgYmVlbiBkZWZpbmVkLiBUaHVzLCBpdCBhcHBlYXJzIHRoYXQ8 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtv bmUgd2F5PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9yd2FyZCBjb3VsZCBiZSB0byBub3QgaW52 b2x2ZSB0aGUgTyBiaXQgaW4gdGhlIGFjdGl2ZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NGQyBPQU0gb3I8YnIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDtJT0FNIGFsdG9nZXRoZXIuIEluIG90aGVyIHdvcmRzLCB0byBkZXByZWNhdGUgdGhlIE5T SCBPIGJpdC48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7SSBncmVhdGx5IGFwcHJlY2lhdGUg eW91ciBjb21tZW50cyBvbiB0aGUgcHJvcG9zYWwgdG88YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtkZXByZWNhdGUgdGhlPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7TlNIIE8gYml0LjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtSZWdhcmRz LDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0dyZWc8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 T24gV2VkLCBGZWIgMiwgMjAyMiBhdCAxMDozNiBBTSBKYW1lcyBHdWljaGFyZDxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3 ZWkuY29tIiBjbGFzcz0iIj5qYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208L2E+PGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Ozxh IGhyZWY9Im1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20iIGNsYXNzPSIiPm1h aWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWku Y29tIiBjbGFzcz0iIj5tYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPC9hPjxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZs dDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tIiBjbGFzcz0i Ij5tYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPC9hPiZndDsmZ3Q7Jmd0OyB3 cm90ZTo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtIaSBXRzpfX19f PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18gX188YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtIYXZpbmcgcmV2aWV3ZWQgYWxsIG9mIHRo ZSBPQU0gcmVsYXRlZCBkb2N1bWVudHMgaW48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvdXIgV0csIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Y2hhaXJzIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBhIGZldyBjb21t ZW50cyB0byBob3BlZnVsbHk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2dl bmVyYXRlIGRpc2N1c3Npb24gYW5kIGZvcndhcmQgcHJvZ3Jlc3Mgb2YgdGhpczxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3dvcms6X19fXzxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZn dDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MSkgVGhlIGNoYWlycyBoYXZlIHJldmlld2Vk IHRoZSBPIGJpdCBkZWZpbml0aW9uIGluPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UkZDIDgzMDAuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtUaGF0IGRlZmluaXRpb24gaXMgYXQgYmVzdCBvcGVuIHRvIGludGVycHJl dGF0aW9uPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7YW5kIHRoZXJlZm9yZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 aW5jb21wbGV0ZS4mbmJzcDsgRm9yIGV4YW1wbGUsIHRoZSBjbGVhciBpbnRlbnRpb24gaXM8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvbmx5 IHRvIG1hcms8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BhY2tldHMgd2hp Y2ggYXJlIGludGVuZGVkIGZvciBTRkMgT0FNIGF0IHRoZSBTRkM8YnIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzZXJ2aWNlPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsYXllci4mbmJzcDsgQnV0IHRoYXQgaXMgbm90IHdo YXQgdGhlIGN1cnJlbnQgdGV4dCBzYXlzLiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtUaGVyZSBpczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7YWxzbywgdW5mb3J0dW5hdGVseSwgYW1iaWd1aXR5IGFzIHRvIHdoYXQ8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjb25zdGl0dXRl cyBhbiBPQU08YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BhY2tldC4mbmJz cDsgU28gaXQgaXMgcmVhc29uYWJsZSBmb3IgZG9jdW1lbnRzIHRvIHVwZGF0ZTxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzgzMDAgdG88YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NsYXJpZnkgdGhlIGV4YWN0IGFwcGxp Y2FiaWxpdHkgYW5kIGFjdGlvbiBmb3IgdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ty1iaXQuX19fXzxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDs8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7MikgSG93ZXZlciwgcmVsYXRlZCB0byBwb2ludCAxKSwgd2UgY2FuJ3QgaGF2 ZSBtdWx0aXBsZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZG9jdW1lbnRz IHVwZGF0aW5nIHRoZSBkZWZpbml0aW9uIGRpZmZlcmVudGx5LiZuYnNwOyBBczxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N1Y2gsIHRoZTxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXV0aG9ycyBvZiB0aGUgU0ZDIGlP QU0gZHJhZnQgYW5kIHRoZSBTRkM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDttdWx0aS1sYXllci1vYW0gZHJhZnQ8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO25lZWQgdG8gY29tZSB0b2dldGhlciBhbmQgZmlndXJlIG91 dCB3aGF0IHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2NsYXJpZmljYXRpb24gaXM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2ZvciB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IGJpdC4gV2UgZG8gbm90IGJlbGlldmUg YXM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtjaGFpcnMgdGhhdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZWl0aGVy IG9mIHRoZXNlIGRvY3VtZW50cyBjYW4gbW92ZSBmb3J3YXJkIGZyb20gdGhlPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V0cgdW50aWw8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N1Y2ggY2xhcml0eSBoYXMgYmVlbiBy ZWFjaGVkLiBfX19fPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18g X188YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDszKSBSZWxhdGVkIHRv IHRoZSBTRkMgaU9BTSwgd2UgbmVlZCBhIGNsZWFyPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGVmaW5pdGlvbiBvZiBpT0FNLjxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlcmUgc2VlbSB0byBiZSBkaWZmZXJlbmNl cyBiZXR3ZWVuIHRoZSBkZWZpbml0aW9ucyBpbjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7cHVibGlzaGVkIFJGQ3MsIHRoZSB1c2FnZSAod2hpY2ggaXMgbm90IGE8YnIgY2xh c3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtkZWZpbml0 aW9uKSBpbiB0aGUgU0ZDPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFm dCwgYW5kIHRoZSB2YXJpb3VzIGlwcG0gZHJhZnRzLiZuYnNwOyBBbnkgc3VjaDxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2RlZmluaXRpb24g d2lsbDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmVlZCB0byBiZSB2ZXR0 ZWQgd2l0aCB0aGUgaXBwbSB3b3JraW5nIGdyb3VwLl9fX188YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtfXyBfXzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0FnYWluLCBpdCB3b3VsZCBiZSBnb29kIGlmIG1lbWJlcnMgb2YgdGhlIHdvcmtp bmc8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtncm91cCBiZXlvbmQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSB0 d28gYXV0aG9yIHRlYW1zIHNwb2tlIHVwIGFib3V0IHRoZWlyIHJlYWRpbmdzPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b2YgdGhlPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkb2N1bWVudHMsIGFuZCB0aGVpciB1bmRl cnN0YW5kaW5ncyBvZiB3aGF0IHdlIG5lZWQuX19fXzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7WW91cnMsX19fXzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0ppbSBhbmQgSm9lbF9fX188YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtfXyBfXzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0 OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18gX188YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 c2ZjIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgY2xhc3M9 IiI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgY2xh c3M9IiI+bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86c2ZjQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDs8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm YyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+ PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiBj bGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT4mZ3Q7 PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiIGNsYXNzPSIiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtzZmMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyA8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpzZmNAaWV0 Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0 bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjPC9hPiZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiIGNsYXNzPSIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDs8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyIgY2xhc3M9IiI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+Jmd0OyZndDs8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyAt LTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmZ3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vd3d3LnZlcml6b24uY29tLyIgY2xhc3M9IiI+ aHR0cDovL3d3dy52ZXJpem9uLmNvbS88L2E+ICZsdDs8YSBocmVmPSJodHRwOi8vd3d3LnZlcml6 b24uY29tLyIgY2xhc3M9IiI+aHR0cDovL3d3dy52ZXJpem9uLmNvbS88L2E+Jmd0OyZndDs8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7 PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jmd0OyAqR3lhbiBNaXNocmEqPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgL05ldHdvcmsgU29sdXRpb25zIEEvL3JjaGl0ZWN0 IC88YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jmd0OyAvPGEgaHJlZj0ibWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20iIGNs YXNzPSIiPkVtYWlsIGd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208L2E+PGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OzxhIGhyZWY9Im1h aWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tIiBjbGFzcz0iIj5tYWlsdG86Z3lhbi5zLm1p c2hyYUB2ZXJpem9uLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzpneWFuLnMubWlzaHJh QHZlcml6b24uY29tIiBjbGFzcz0iIj5tYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTwv YT48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbHQ7PGEgaHJlZj0ibWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20iIGNsYXNzPSIi Pm1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tPC9hPiZndDsmZ3Q7Ly88YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IC88YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7 PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jmd0OyAvTSAzMDEgNTAyLTEzNDc8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyAvPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDs8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQotLSA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0i aHR0cDovL3d3dy52ZXJpem9uLmNvbS8iIGNsYXNzPSIiPmh0dHA6Ly93d3cudmVyaXpvbi5jb20v PC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoqR3lhbiBNaXNocmEqPGJyIGNs YXNzPSIiPg0KL05ldHdvcmsgU29sdXRpb25zIEEvL3JjaGl0ZWN0IC88YnIgY2xhc3M9IiI+DQov PGEgaHJlZj0ibWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20iIGNsYXNzPSIiPkVtYWls IGd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86Z3lhbi5z Lm1pc2hyYUB2ZXJpem9uLmNvbSIgY2xhc3M9IiI+bWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpv bi5jb208L2E+Jmd0Oy8vPGJyIGNsYXNzPSIiPg0KLzxiciBjbGFzcz0iIj4NCi9NIDMwMSA1MDIt MTM0NzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi88YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi ciBjbGFzcz0iIj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDs8 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmM8L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpzZmMgbWFpbGluZyBsaXN0 PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgY2xhc3M9IiI+c2Zj QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_69B3DD8B1A6D4D07B41EA2958A117E33ciscocom_-- From nobody Mon Feb 14 06:10:15 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327CC3A0E28 for ; Mon, 14 Feb 2022 06:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.814 X-Spam-Level: X-Spam-Status: No, score=-7.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, 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 Si5B2jn0tCJe for ; Mon, 14 Feb 2022 06:10:08 -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 721BD3A0E27 for ; Mon, 14 Feb 2022 06:10:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Jy5hb6x9Hz6GbKX; Mon, 14 Feb 2022 06:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1644847807; bh=12z2WuqePSmxfZxZPTF/GF8dcb3ZtCQ6Hy/CKkl7Dg8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=GVxCEBNHw6OGyAQ4BjqyhbfztaAcvqpcpiERmaGLFkmdIIu7bBrseR0ZrGcHGCLGP /7iVvnOqwEfKRGL8zf/akynvpdFKMNU9MVgR/2tBA0b7ymkEEGLsBA5Ax0u/nVHzF6 ACR7JbIQP6USnAMDtujbVus4GLtmqZbUejtMI2o0= 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 4Jy5hb2vKpz6Gb3v; Mon, 14 Feb 2022 06:10:06 -0800 (PST) Message-ID: <1e625c8b-31d2-924e-8557-bfb043554267@joelhalpern.com> Date: Mon, 14 Feb 2022 09:10:05 -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 To: "Carlos Pignataro (cpignata)" Cc: "sfc@ietf.org" References: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.com> <69B3DD8B-1A6D-4D07-B41E-A2958A117E33@cisco.com> From: "Joel M. Halpern" In-Reply-To: <69B3DD8B-1A6D-4D07-B41E-A2958A117E33@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG - OAM Packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 14:10:14 -0000 Hmm. let me paraphrase to make sure I understood, and assuming I did, clarify my confusion. You seem to be saying that a way to do SFP OAM is to use something carried in IP carried in an NSH, with the O bit set. If I am reading this correctly, this means that you expect an SFF seeing a packet with the O bit is supposed to examine not only the carried protocol (indicated by the next protocol field in the NSH) but to examine the various fields of that protocol to decide if the inned content is OAM the SFF is supposed to pay attention to. That does not match my understanding of expected behavior. Particularly since that carried IP packet is likely not addressed to the SFF, and also will not be having its TTL or other fields checked. Again, it would be good to hear from other WG participants as to whether they understand expect behavior of an SFF to include this (based on 8300). Yours, Joel On 2/14/2022 8:02 AM, Carlos Pignataro (cpignata) wrote: > Joel, > > Happy to. > > No, that is not what I meant. I am not sure where (or why) you added the > word “external”, but that was key to showing a disconnect (I might not > have been clear and/or you might not have read correctly). > > Let me try different way: > > There is an I-D now, sfc-multi-layer-oam, that sends “SFC Active OAM" > packets with a new SFC next protocol for a newly created protocol. In > this case, the SFC next protocol is not expected to be used in user > packets, at least for now (or people have not thought about that > in hierarchical cases) > > Imagine now that BFD or ICMP want to be used as an SFC Active OAM > protocols, instead of the sfc-multi-layer-oam one. Those can be > encapsulated in IP (even with a 127/8 destination). Using the O-bit set > and SFC NP as IP is the RFC 8300 expected way. (I imagine creating a new > SFC next protocol for “BFD-in-IP-used-in-SFC” so as to avoid an SFC NP > expected on external packets would be an approach if there was no O-bit > defined) > > Best, > > Carlos. > >> 2/14/22 午前7:05、Joel M. Halpern > >のメール: >> >> Thank you for taking the time to provide a careful reply. >> >> It appears, from your description of ICMP packets that your >> understanding of 8300 is that in SFC an external ICMP packet will get >> the O bit set in the NSH header.  Presumably, base on this, the SFF or >> SF are supposed to look through and notice this content?   (Otherwise, >> why set the bit?)  This seems an undesirable and expensive >> implications which other readers have not drawn from the RFC 8300 >> text.  (It also requires the encapsulating node to do extra checking >> to discover this case.) >> >> Am I reading your expectation correctly? >> >> Yours, >> Joel >> >> On 2/13/2022 11:06 PM, Carlos Pignataro (cpignata) wrote: >>> Replying to this specific email in the thread, only because it is the >>> latest one at this point in time, but bundling comments from various >>> places on the thread. Please find some follow-up comments and >>> questions marked “CMP”, indicating the “From”, and organized >>> chronologically: >>> *James N Guichard >> >>> >> >>:* >>>> 1) The chairs have reviewed the O bit definition in RFC 8300.  That >>>> definition is at best open to interpretation and therefore >>>> incomplete.  For example, the clear intention is only to mark >>>> packets which are intended for SFC OAM at the SFC service layer. >>>> But that is not what the current text says.  There is also, >>>> unfortunately, ambiguity as to what constitutes an OAM packet.  So >>>> it is reasonable for documents to update 8300 to clarify the exact >>>> applicability and action for the O-bit. >>> CMP: It is unclear to me what exact issues the chairs are calling >>> out. There are two issues mentioned: >>> CMP: 1. "But that is not what the current text says.” —> what does >>> the text say precisely?  Can you point to the specific RFC 8300 text >>> that is believed to be incomplete, and a detailed use case that >>> showcases the potential issue? An extrapolated counter-example just >>> to make a point: the text does not  say what days of the week OAM >>> packets can be marked, yet there’s an expectation that they will work >>> Mondays and Saturdays all the same — even holidays. >>> CMP: 2. What specifically is the ambiguity with what an OAM packet >>> is? Please grep the RFC series for “oam packet”, it is not a new term. >>> CMP: Net-net, O-bit=1, OAM packet. >>>> 2) However, related to point 1), we can't have multiple documents >>>> updating the definition differently.  As such, the authors of the >>>> SFC iOAM draft and the SFC multi-layer-oam draft need to come >>>> together and figure out what the clarification is for the definition >>>> of that bit. We do not believe as chairs that either of these >>>> documents can move forward from the WG until such clarity has been >>>> reached. >>> CMP: If there is still believed to be an ambiguity or a clear >>> opportunity for improving the definition, I agree with consolidating >>> that update. I had suggested before that if such new text or real >>> clarification is agreed, a separate document that only makes that >>> O-bit clarification is the most clear and clean way to go. That doc >>> should be a one-pager or less. I’d be happy to contribute to that >>> minimal doc, if it is shown to be needed. >>> CMP: For completeness also, the "SFC multi-layer-oam” document has >>> many outstanding issues besides the O-bit. >>> *Greg Mirsky >>> >>* >>>> I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I >>>> understand these documents, the Active SFC OAM and IOAM are >>>> identified by the respective values for the NSH Next Protocol field >>>> (to be assigned by IANA). >>> CMP: There is a major issue with the sentence above. Active SFC OAM >>> (as a category), as per RFC 8300, needs to be identified by setting >>> the O-bit. No way around that based on RFC 8300. However, the text >>> "the Active SFC OAM” creates confusion since it refer to a specific >>> OAM protocol which has the same name as a the category as well. That >>> name collision is quite unfortunate in my opinion. >>>> At the same time, so far no OAM-specific meta data TLV has been >>>> defined. Thus, it appears that one way forward could be to not >>>> involve the O bit in the active SFC OAM or IOAM altogether. In other >>>> words, to deprecate the NSH O bit. >>> CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM >>> protocols. Those can be encapsulated in IP, in which the >>> Next-Protocol indicates IP — and (as per RFC 8300) the O-bit is set >>> to indicate an OAM packet. >>> CMP: The proposal of deprecating the O-bit breaks those SFC OAM >>> protocols already included in an RFC. >>> CMP: That proposal of deprecating the O-bit also breaks Section 4.1 >>> of IOAM. >>> CMP: This expired I-D yet implemented in open source uses the O-bit: >>> https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt >>> >>> >> > >>> *Gyan Mishra >>> >>* >>>> I agree that what makes sense to me as a path forward is to >>>> deprecate the O bit and not use in SFC Multilayer OAM and SFC IOAM, >>>> as both SFC Multilayer OAM and SFC IOAM are identified by the >>>> respective values for the NSH Next Protocol field (to be assigned by >>>> IANA), as well as so far no OAM-specific meta data TLV has been yet >>>> defined. >>> CMP: What is the “SFC Multilayer OAM”? >>> CMP: The O-bit (reading RFC 8300) does not indicate if there is OAM >>> Metadata. It indicates an OAM packet. >>> *"Joel M. Halpern" >>> >>* >>>> As far as I can tell, if we deprecate the O-bit and rely on the next >>>> protocol field, we are saying that in practice (not by rule) NSH >>>> metadata can not be used for OAM.  That's fine with me as long as we >>>> agree on that. >>> CMP: I do not fully follow this. Can you explain the relationship of >>> the O-bit with Metadata? >>> CMP: Here’s an example: RFC 8924 shows ICMP as Active OAM. The SFC >>> next protocol is IP, the IP next protocol is ICMP, the O-bit needs to >>> be set. >>> CMP: Consider the following document, independent submission and in >>> the RFC Publication queue already: >>> CMP: >>> https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/ >>> >>> >> > >>> CMP: Is a Timestamp in Metadata an OAM element? >>> CMP: Consider this proposal >>> https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/ >>> >>> >> > >>> CMP: Where the base header borrows a bit for an OAM function. >>> CMP: Neither of those have any impact on the O-bit. >>> *Greg Mirsky >>> >>* >>>> I agree that, as we find SFC NSH now, no OAM metadata has been >>>> defined. It appears to me that deprecating the O bit does not affect >>>> any of the already defined mechanisms in the SFC NSH. >>> CMP: It actually does, see my example above. >>>> I think that if a new, for example, MD Type = 2 TLV that is used for >>>> any OAM functionality to be proposed in the future, deprecated the O >>>> bit would not prevent using such NSH TLV. >>> CMP: I agree with this — because there is no correlation between MD >>> Type field and O-bit as defined. >>> Best, >>> Carlos. >>>> 2/13/22 午後12:32、Gyan Mishra >>> >>> >>のメール: >>>> >>>> Hi Joel >>>> >>>> I am in agreement as well with what you have stated that once the O >>>> bit is deprecated that NSH metadata cannot be used for OAM and that >>>> we would have to now from that point forward rely on the next >>>> protocol field as we will be doing for SFC Multilayer and SFC IOAM >>>> drafts as well as will have backwards compatible with any already >>>> existing defined mechanisms in SFC NSH. >>>> >>>> I don’t see any issues or impact with moving forward. >>>> >>>> Kind Regards >>>> >>>> Gyan >>>> >>>> On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky >>> >>> >> wrote: >>>> >>>>    Hi Joel, >>>>    I agree that, as we find SFC NSH now, no OAM metadata has been >>>>    defined. It appears to me that deprecating the O bit does not >>>>    affect any of the already defined mechanisms in the SFC NSH. I >>>>    think that if a new, for example, MD Type = 2 TLV that is used for >>>>    any OAM functionality to be proposed in the future, deprecated the >>>>    O bit would not prevent using such NSH TLV. >>>>    What do you think? >>>> >>>>    Regards, >>>>    Greg >>>> >>>>    On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern >>>>     >>>> >> wrote: >>>> >>>>        There is an implication of deprecating the O-bit that I would >>>>        like to >>>>        hear from more WG participants about. >>>> >>>>        As far as I can tell, if we deprecate the O-bit and rely on >>>>        the next >>>>        protocol field, we are saying that in practice (not by rule) NSH >>>>        metadata can not be used for OAM.  That's fine with me as long >>>>        as we >>>>        agree on that. >>>> >>>>        Yours, >>>>        Joel >>>> >>>>        On 2/13/2022 2:52 AM, Gyan Mishra wrote: >>>>        > >>>>        > Hi Jim, Joel & SFC WG, >>>>        > >>>>        > I agree that the RFC 8300 definition of O bit is incomplete >>>>        and not >>>>        > clear as to its intended use. >>>>        > >>>>        > That is a problem that I agree needs to be rectified. >>>>        > >>>>        > I understand that we need to get this resolved before we can >>>>        progress >>>>        > Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC >>>>        IOAM. >>>>        > >>>>        > I agree that what makes sense to me as a path forward is to >>>>        deprecate >>>>        > the O bit and not use in SFC Multilayer OAM and SFC IOAM, as >>>>        both SFC >>>>        > Multilayer OAM and SFC IOAM are identified by the respective >>>>        values for >>>>        > the NSH Next Protocol field (to be assigned by IANA), as >>>>        well as so far >>>>        > no OAM-specific meta data TLV has been yet defined. >>>>        > >>>>        > So we have I believe solid solution and path forward and I >>>>        support >>>>        > deprecating the O bit. >>>>        > >>>>        > Kind Regards >>>>        > >>>>        > Gyan >>>>        > >>>>        > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky >>>>         >>>> > >>>>        > >>>>        >>> >>> wrote: >>>>        > >>>>        >     Thank you, Jim and Joel, for guiding the SFC OAM work >>>>        and pointing >>>>        >     out the issue that must be addressed. >>>>        > >>>>        >     I've reviewed our SFC OAM documents and >>>>        draft-ietf-sfc-nsh-tlv. As I >>>>        >     understand these documents, the Active SFC OAM and IOAM are >>>>        >     identified by the respective values for the NSH Next >>>>        Protocol field >>>>        >     (to be assigned by IANA). At the same time, so far no >>>>        OAM-specific >>>>        >     meta data TLV has been defined. Thus, it appears that >>>>        one way >>>>        >     forward could be to not involve the O bit in the active >>>>        SFC OAM or >>>>        >     IOAM altogether. In other words, to deprecate the NSH O >>>> bit. >>>>        > >>>>        >     I greatly appreciate your comments on the proposal to >>>>        deprecate the >>>>        >     NSH O bit. >>>>        > >>>>        >     Regards, >>>>        >     Greg >>>>        > >>>>        >     On Wed, Feb 2, 2022 at 10:36 AM James Guichard >>>>        >     >>> >>>>        >>> > >>>>        >     >>> >>>>        >>> >>> wrote: >>>>        > >>>>        >         Hi WG:____ >>>>        > >>>>        >         __ __ >>>>        > >>>>        >         Having reviewed all of the OAM related documents in >>>>        our WG, the >>>>        >         chairs would like to provide a few comments to >>>> hopefully >>>>        >         generate discussion and forward progress of this >>>>        work:____ >>>>        > >>>>        >         __ __ >>>>        > >>>>        >         1) The chairs have reviewed the O bit definition in >>>>        RFC 8300. >>>>        >         That definition is at best open to interpretation >>>>        and therefore >>>>        >         incomplete.  For example, the clear intention is >>>>        only to mark >>>>        >         packets which are intended for SFC OAM at the SFC >>>>        service >>>>        >         layer.  But that is not what the current text says. >>>>         There is >>>>        >         also, unfortunately, ambiguity as to what >>>>        constitutes an OAM >>>>        >         packet.  So it is reasonable for documents to update >>>>        8300 to >>>>        >         clarify the exact applicability and action for the >>>>        O-bit.____ >>>>        > >>>>        >         __ __ >>>>        > >>>>        >         2) However, related to point 1), we can't have multiple >>>>        >         documents updating the definition differently.  As >>>>        such, the >>>>        >         authors of the SFC iOAM draft and the SFC >>>>        multi-layer-oam draft >>>>        >         need to come together and figure out what the >>>>        clarification is >>>>        >         for the definition of that bit. We do not believe as >>>>        chairs that >>>>        >         either of these documents can move forward from the >>>>        WG until >>>>        >         such clarity has been reached. ____ >>>>        > >>>>        >         __ __ >>>>        > >>>>        >         3) Related to the SFC iOAM, we need a clear >>>>        definition of iOAM. >>>>        >         There seem to be differences between the definitions in >>>>        >         published RFCs, the usage (which is not a >>>>        definition) in the SFC >>>>        >         draft, and the various ippm drafts.  Any such >>>>        definition will >>>>        >         need to be vetted with the ippm working group.____ >>>>        > >>>>        >         __ __ >>>>        > >>>>        >         Again, it would be good if members of the working >>>>        group beyond >>>>        >         the two author teams spoke up about their readings >>>>        of the >>>>        >         documents, and their understandings of what we >>>> need.____ >>>>        > >>>>        >         __ __ >>>>        > >>>>        >         Yours,____ >>>>        > >>>>        >         Jim and Joel____ >>>>        > >>>>        >         __ __ >>>>        > >>>>        >         __ __ >>>>        > >>>>        >         __ __ >>>>        > >>>>        >         _______________________________________________ >>>>        >         sfc mailing list >>>>        > sfc@ietf.org >>> > >>>>        >> >>>>        > https://www.ietf.org/mailman/listinfo/sfc >>>> >>>>        >>> > >>>>        >         >>> >>>>        >>> >> >>>>        > >>>>        >     _______________________________________________ >>>>        >     sfc mailing list >>>>        > sfc@ietf.org >>> > >>>>        >> >>>>        > https://www.ietf.org/mailman/listinfo/sfc >>>> >>>>        >>> > >>>>        >     >>> >>>>        >>> >> >>>>        > >>>>        > -- >>>>        > >>>>        > >>>> >> >>>>        > >>>>        > *Gyan Mishra* >>>>        > >>>>        > /Network Solutions A//rchitect / >>>>        > >>>>        > /Email gyan.s.mishra@verizon.com >>>> >>>>        >>> > >>>>        >>> >>>>        >>> >>// >>>>        > / >>>>        > >>>>        > /M 301 502-1347 >>>>        > >>>>        > / >>>>        > >>>>        > >>>> >>>> -- >>>> >>>> > >>>> >>>> *Gyan Mishra* >>>> /Network Solutions A//rchitect / >>>> /Email gyan.s.mishra@verizon.com >>>> >// >>>> / >>>> /M 301 502-1347 >>>> >>>> / >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>> > >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Feb 14 06:28:21 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C76F3A0EDF for ; Mon, 14 Feb 2022 06:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, T_REMOTE_IMAGE=0.01, 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 AON3d-TWOwnr for ; Mon, 14 Feb 2022 06:28:12 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2122.outbound.protection.outlook.com [40.107.92.122]) (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 896B73A0ED6 for ; Mon, 14 Feb 2022 06:28:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UUhQFOlDAcpOD4J16LsFi2M5tayXauak1ZhB+jBK4r+CLXrWB2AaH2/xSkVsLkyKenGaJ2L4L+ZAjK2c4GVN6rTd0fRy1dctFhoIfaVAvt3fEe0ksPsidr6adIRFvebD+1uiJc6s63D2TiIlC2+3KOBgPj9LVha5l5KDXpNcbmrSHJjcGtfCFyFHM5toyjQw+cN7XpxfVS+YlLc0u7ocJttiOiyAY8fuRDxyOWwKgTDxboyasBhqEN6veIznAyLoh9vPwd0GM+9T6SwwJPY+vZlZBoVxgvhExiXW6A1OaWxIMseJQX8WC7G6XcpezmesLlwji/3MKXvdHtIbK9mIag== 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=9QpbZyZhffoIUslwxPZU6u9adywCKUtkY1f1Zr9N/rE=; b=aX//YGBlARp9qbAj/xxYp+dg4jLhUu3OrBdJRvoxnK+dtbg0WlXibn0If5OSXtNfB5VpzuE/CgGSOrkunzW3lWvzTSzexCel44EBp81Po468uHLQ6+gDeBe4CPAxUKOaBUelr9O+nnYJ6W4FgOd1Jal/uZ4WTx4TeWRLeLUx8GgtLlKQwuFkZ0xTcBiAZrpvprjhIXPZxKfaGfsqze6qSfetyBTtqekWPHgVgYUp/aOPLoug2JCv51mkcXPSggDMrO6xkVLEv4edagz1V44WsbNscsHVN9dl3o2TPJ0YsOBS1l5Rci3Hx7FR4+pNS8ESYOwN8z79NJx8wqRBKorZOw== 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=9QpbZyZhffoIUslwxPZU6u9adywCKUtkY1f1Zr9N/rE=; b=jtefctN3jsh0UgWYPvaQyKipqlugr+bI4r+v8udQf3z82xpCYCSp+1SacqA0h3aCsbRQayAxLTxI8tRGCVtrv0NEYd8U0o0Hi2VbG8blUTclODt5okruzRQqndq2GjRRNqf1z/LEVyzUUm/I0IFZ1g3TbDC1nzxttlHBHL0IdBM= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by DM5PR13MB1195.namprd13.prod.outlook.com (2603:10b6:3:77::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.13; Mon, 14 Feb 2022 14:28:08 +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; Mon, 14 Feb 2022 14:28:08 +0000 From: James Guichard To: "Carlos Pignataro (cpignata)" , Gyan Mishra CC: Greg Mirsky , "sfc@ietf.org" Thread-Topic: [sfc] Progression of OAM work in the SFC WG Thread-Index: AdgYYtG+l/ju054uSCa0IEDodR5p4AAI1AYAAgogAwAADsqJgAAEeXQAAAD7PAAAFinEAAAVIwJw Date: Mon, 14 Feb 2022 14:28:07 +0000 Message-ID: References: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.com> In-Reply-To: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.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: c1c5d6c1-dfa2-487a-d101-08d9efc63891 x-ms-traffictypediagnostic: DM5PR13MB1195:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: a7VJY8rDn1rG9IOGp46REzdSmViUkeVbCWuQzJ/ZAwn0C0avt7MEV1JeEng5QksliURVayW8Zk6ijhtlzxp/PbI+c+VwvvZFWFP3g6RMfnQm78GY1z9W1I5C2OiGtpK5eKd2iTvA+1R8HKvsjaoBWkJEQ4XhGcqoWgiACO46HXvik4fa+DYvY1zZN7sUAalGneqbonVeqtoEOF9a7uw2HGbPxJvv7GMh8sXavgidawyjHvQhp8/DzNXOFakNg5c2X6vxAiqKwM85nwOg0IWjt+vaP6D6hr9DOLpzk8ekbqSOHo+9OC7ONvaZ+d+HqBKbPGoCEJypQl7lDCOtV/HwtFOKcUcvYM4hYqqoQ7m20Sjq3TGjFWLF8taqgnXA+vZFrGDILKjQwcUM1cf++Ae2S6MiO5wuF2dgGaFs7WFE+/CzbYIQwmo78dWC/ccaOz1Fv1MFWRLQ2/hI3bycIQUTlGRXFh3ot1Doyvzt/aHhkDlEbQZAKqqZLRnTcf8lt2XLkz5yjeSTMCV9D3bOQ3YY6+4Lvub3bJSQ22ymIvLTu77Rr92n/kXpcG0XGeSLRibCockpwPclG77LcXPXeG51m/oTPVEyeRynhJWL+KshejJV7SOutKz5sPXF120kYhmc2KBMmRu5c5YRhVlMnoenz1A/aowcxLOVcLzeRMSRXFaj9ijIbisamxkn8SuC+5vXQqWn07PWhtYcXRxj12vFrpM8+YpoVQuq3VpT3O9ICGjn7eetl6UqWoAIPjk1K04/bcPFtHkkGxmjo6PiGj0eC6phGFJnlPecf3L5rdNS6acOq2/IpPQZLDt/81bz17goraDgslaGtOIsD2uiH4zJWA== 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)(7696005)(86362001)(966005)(83380400001)(508600001)(4326008)(66446008)(316002)(110136005)(8676002)(66556008)(54906003)(64756008)(66476007)(66946007)(6506007)(30864003)(9686003)(53546011)(76116006)(52536014)(8936002)(9326002)(2906002)(38070700005)(71200400001)(5660300002)(122000001)(33656002)(55016003)(166002)(186003)(38100700002)(40140700001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?cXcwYzk4clgvY3pobGJ5eU5zMVpoMENSNXJ4dlJjdlg5cWJQR1BJS2JX?= =?iso-2022-jp?B?eVUxWTFHdmk3YnpnSTdwekFJSitPMVFiWUw0ZE1ZRUxyRWMvSFUxb1Bh?= =?iso-2022-jp?B?LzJsMzhrZVVzSWZaM1VmYVRmbDNFRXlJSjVWaEs3U0VBZ1VjWUtGNFF5?= =?iso-2022-jp?B?U3lQRGFSc1Y1QWRER1Z5blRtVCtOVEF6eDRyMzRmNVJhTEg0Tm8yQm1z?= =?iso-2022-jp?B?WnN5YXlwWlNjeXN5ODBRTms2d3VlSjFBSkJzdVd4WFFFUFBWcWswbHFs?= =?iso-2022-jp?B?VUFjd1lYN0ErK2RBcU41LzhzSGdDVFUxNG4yYkdnMVJEdDdiOXRFODBj?= =?iso-2022-jp?B?czB1UUM4eHRiSHFLSjQxQnN6WkpWYkVUeE1zNkM1MGxKRFJnWjNBZlR4?= =?iso-2022-jp?B?VUdGeHJVZXBrSHo5Q2dHeHZhcUNaN214eFY1RDRpVzVPdXNLRllESm9l?= =?iso-2022-jp?B?M0syU0twODFNU0dMQkphQysxNzhKSUZiVmJ2dTNsSFZtVmlEbDVkdmVI?= =?iso-2022-jp?B?eTFZdmFWMFpMUmFPbWY2NDhkRkNLS1ZmUk1zZ3hxN1ZBMlN3T1pEc1RD?= =?iso-2022-jp?B?eVhhUnByenRUcHNMbVg1Nk8rdkhWMXFWQ3pCNzg0VU1hTndYMFIyMkFu?= =?iso-2022-jp?B?NkxPTlVjYlFBZHJUcUtzT2xvMWNzdEMyWVNORTIzWTRvYUVBN0lJdmNr?= =?iso-2022-jp?B?T3UyUXBwS3lqQyszRW1zNGsyaTNPQWxPWGQyZ2lwVnJXZmVtM212ajZw?= =?iso-2022-jp?B?VURrNHJ2RlFYZ2twNjMyTGh1cXpVOTNqM2MyMEtxaTZPb1JvT003QXFB?= =?iso-2022-jp?B?dGcrSXBoVVlPVDFxSXBON1ZUdUVLb2FuQ09DbnMyaGVhb0V5WXhxWUdv?= =?iso-2022-jp?B?Yi9VUVhuc2dqYnJtaU1qOFJDTVRyb0FSU0xudTU2cW4zM0ZIUDMzcFpO?= =?iso-2022-jp?B?eC9WUmQyQlhCeTMwRCtuMDJyRWF3b1haclFhUXd2UDBTQ0dlUUNob1FZ?= =?iso-2022-jp?B?UHBCKzh6ZmRvRkhSeDg3YUsyRUFOcmJwbkc1ckJhbU9kSkhicWxjTEkv?= =?iso-2022-jp?B?N1hTWGtkOGdiWERNdmFPQW13MlZNaElhaDNROXhqanJkSXhDbFplYXh6?= =?iso-2022-jp?B?ZFlTVGl6Vlc2bE9KcXh0YVA2OUFBa3o2bEljVU1Eei9veERTTEJwMGxi?= =?iso-2022-jp?B?UzhvZnBReUJzZU9HU1lvajVnRlpCaUlCM3FBU3pVQkVvUE1iOEpJYzNN?= =?iso-2022-jp?B?MnFCbUdxU1ZPbCtTRWNUcTd1WTdPUDF0Wk4zNWVhckxrNytZZjFxVGFs?= =?iso-2022-jp?B?ZnhsZHM3WTcveTdsaWFPWTA4RThkaTIxandlYkNWNXhFN3RPSTF4bTVt?= =?iso-2022-jp?B?RVp5YkoyMEgxblRQeW1yTEg2NnUyYWdwSE5GYlRVSnpGMzJqSjNYdFc4?= =?iso-2022-jp?B?VGhhaDBZbUlaQjA1V3BxRDMyMTNsMG5zMkFGYUJlMFkxTDhLQmEySWoy?= =?iso-2022-jp?B?QVVHRTF0ZW94N2kwOXJkV2tmbGlzUEdMaGUrUkcvNWhDd0Q1Vmx5RC9t?= =?iso-2022-jp?B?ejZUcHYrNGpPUE1ablJobXVOZm9tUytON09hL1lTa1owSUFVbHpBamRq?= =?iso-2022-jp?B?STZSdUM1cUlmUVRiNmh2c2tlU04wVGp4c2t6bTlvU3FROHJmNEFVM1Ez?= =?iso-2022-jp?B?SEhQVDRoNk9pbElLVzczR3NGV3NTcjV0Mi9vYmVHL3U2UDdkczlkZUFG?= =?iso-2022-jp?B?elBpV09uSzRLVm53U2J3RFZrTXJlWTZ0N2tGelFsRk11L2Rqb3VIb1g5?= =?iso-2022-jp?B?aTVsYWp4UFQ0RjhJMDJqZDZSZy80SytOZkFDcnA3ajhHZi9ybmFlSFhK?= =?iso-2022-jp?B?OTZ3aGttbTRFZk4yNDhQd3k0a3gvcXk3a1ozZGlLVmx1dlBVWG5CS2gy?= =?iso-2022-jp?B?QkNWeFhXZCtwSWU4ancybVpqNURkSmNUeVpmcTVJb0ZDaEthZFBWNklC?= =?iso-2022-jp?B?WndCM0s1SHZhWnZBRWo2eHVIbXY4YXJvVDdkWGlxTlhrdWU5NjVKSDRJ?= =?iso-2022-jp?B?OUdXMVFoMVhMSjBtdlplSGo0M1o1VWJ5c1c0cHhyeUlUM3ZhTmQ3ODhZ?= =?iso-2022-jp?B?RXNET2V1eXNsMmREVzRMWVBZcWRrWkltYzQ4UG5ZRlVxMTV0Ulp2ZXkz?= =?iso-2022-jp?B?U2dDYXRVYmZ5bmJIajlnNGlVT0FaYmgxS1kyMUtvZGhiZ0ZVSjNGMTV6?= =?iso-2022-jp?B?WEVpM1N2VmdoOUFwaEcxZkwvaDdYL2dBMnZmOUJsUUF2MGkzSGNkYWRh?= =?iso-2022-jp?B?d05yNi9tbng5RnZvQTErZjlFRnR4ZkV6aGVibUpZckpVOGNkVzNVSzEr?= =?iso-2022-jp?B?bXpOVUNidEtBM1hqdlpsa24zYnJjNUw3d05ycGRSbTBsemN1SzVabmhJ?= =?iso-2022-jp?B?MGJWZm0xU09rUFZSVVp5WUVzYW5QVW94VkhjPQ==?= Content-Type: multipart/alternative; boundary="_000_MN2PR13MB420658D888711F1FC921556BD2339MN2PR13MB4206namp_" 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: c1c5d6c1-dfa2-487a-d101-08d9efc63891 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2022 14:28:07.9873 (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: DKCumrxO1Puhp9Uh8ki/Y/+6e7dvdAJElg85iYlcHR7l9KTs1ERK0i3jhuK+bij7rL80jRuqDIP2fWHEL7AMkw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR13MB1195 Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 14:28:19 -0000 --_000_MN2PR13MB420658D888711F1FC921556BD2339MN2PR13MB4206namp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Carlos, Some responses in-line =1B$B!D=1B(B From: sfc On Behalf Of Carlos Pignataro (cpignata) Sent: Sunday, February 13, 2022 11:07 PM To: Gyan Mishra Cc: Greg Mirsky ; sfc@ietf.org Subject: Re: [sfc] Progression of OAM work in the SFC WG Replying to this specific email in the thread, only because it is the lates= t one at this point in time, but bundling comments from various places on t= he thread. Please find some follow-up comments and questions marked =1B$B!H= =1B(BCMP=1B$B!I=1B(B, indicating the =1B$B!H=1B(BFrom=1B$B!I=1B(B, and orga= nized chronologically: James N Guichard >: 1) The chairs have reviewed the O bit definition in RFC 8300. That definit= ion is at best open to interpretation and therefore incomplete. For exampl= e, the clear intention is only to mark packets which are intended for SFC O= AM at the SFC service layer. But that is not what the current text says. = There is also, unfortunately, ambiguity as to what constitutes an OAM packe= t. So it is reasonable for documents to update 8300 to clarify the exact a= pplicability and action for the O-bit. CMP: It is unclear to me what exact issues the chairs are calling out. Ther= e are two issues mentioned: CMP: 1. "But that is not what the current text says.=1B$B!I=1B(B -> what do= es the text say precisely? Can you point to the specific RFC 8300 text tha= t is believed to be incomplete, and a detailed use case that showcases the = potential issue? An extrapolated counter-example just to make a point: the = text does not say what days of the week OAM packets can be marked, yet the= re=1B$B!G=1B(Bs an expectation that they will work Mondays and Saturdays al= l the same - even holidays. Jim> Currently RFC8300 says =1B$B!H=1B(BThe O bit MUST be set for OAM packe= ts and MUST NOT be set for non-OAM packets=1B$B!I=1B(B. The first issue is = does this mean the O bit should be set for ALL OAM packets regardless of wh= ether they belong to the NSH service plane? Or should it only be set for SF= C OAM packets? And what exactly is an SFC OAM packet as the earlier referen= ce to RFC6291 is just a generate set of guidelines for the use of the term = OAM. The second issue is that if that O bit is set then Greg=1B$B!G=1B(Bs d= ocument is in conflict with IOAM as both use the next protocol field and ev= en if the O bit is set it is meaningless as the protocol action is based so= lely on the setting of the next protocol field. So in this case can their s= olutions simply ignore what RFC 8300 says e.g. MUST set the O bit? Or if th= ey set the O bit to be conformant to what RFC 8300 says then do we need cle= arer rules stating what to do if the next protocol field is NOT an OAM next= protocol such as the context headers should then be examined? CMP: 2. What specifically is the ambiguity with what an OAM packet is? Plea= se grep the RFC series for =1B$B!H=1B(Boam packet=1B$B!I=1B(B, it is not a = new term. CMP: Net-net, O-bit=3D1, OAM packet. Jim> ambiguity is whether it is only SFC OAM packets that are being discuss= ed or ALL OAM packets nothing that some might be at the service layer and s= ome might not. Jim 2) However, related to point 1), we can't have multiple documents updating = the definition differently. As such, the authors of the SFC iOAM draft and= the SFC multi-layer-oam draft need to come together and figure out what th= e clarification is for the definition of that bit. We do not believe as cha= irs that either of these documents can move forward from the WG until such = clarity has been reached. CMP: If there is still believed to be an ambiguity or a clear opportunity f= or improving the definition, I agree with consolidating that update. I had = suggested before that if such new text or real clarification is agreed, a s= eparate document that only makes that O-bit clarification is the most clear= and clean way to go. That doc should be a one-pager or less. I=1B$B!G=1B(B= d be happy to contribute to that minimal doc, if it is shown to be needed. CMP: For completeness also, the "SFC multi-layer-oam=1B$B!I=1B(B document h= as many outstanding issues besides the O-bit. Greg Mirsky > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I unders= tand these documents, the Active SFC OAM and IOAM are identified by the res= pective values for the NSH Next Protocol field (to be assigned by IANA). CMP: There is a major issue with the sentence above. Active SFC OAM (as a c= ategory), as per RFC 8300, needs to be identified by setting the O-bit. No = way around that based on RFC 8300. However, the text "the Active SFC OAM=1B= $B!I=1B(B creates confusion since it refer to a specific OAM protocol which= has the same name as a the category as well. That name collision is quite = unfortunate in my opinion. At the same time, so far no OAM-specific meta data TLV has been defined. Th= us, it appears that one way forward could be to not involve the O bit in th= e active SFC OAM or IOAM altogether. In other words, to deprecate the NSH O= bit. CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM proto= cols. Those can be encapsulated in IP, in which the Next-Protocol indicates= IP - and (as per RFC 8300) the O-bit is set to indicate an OAM packet. CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols a= lready included in an RFC. CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM= . CMP: This expired I-D yet implemented in open source uses the O-bit: https:= //www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt Gyan Mishra > I agree that what makes sense to me as a path forward is to deprecate the O= bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC Multilayer= OAM and SFC IOAM are identified by the respective values for the NSH Next = Protocol field (to be assigned by IANA), as well as so far no OAM-specific = meta data TLV has been yet defined. CMP: What is the =1B$B!H=1B(BSFC Multilayer OAM=1B$B!I=1B(B? CMP: The O-bit (reading RFC 8300) does not indicate if there is OAM Metadat= a. It indicates an OAM packet. "Joel M. Halpern" > As far as I can tell, if we deprecate the O-bit and rely on the next protoc= ol field, we are saying that in practice (not by rule) NSH metadata can not= be used for OAM. That's fine with me as long as we agree on that. CMP: I do not fully follow this. Can you explain the relationship of the O-= bit with Metadata? CMP: Here=1B$B!G=1B(Bs an example: RFC 8924 shows ICMP as Active OAM. The S= FC next protocol is IP, the IP next protocol is ICMP, the O-bit needs to be= set. CMP: Consider the following document, independent submission and in the RFC= Publication queue already: CMP: https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timesta= mp/ CMP: Is a Timestamp in Metadata an OAM element? CMP: Consider this proposal https://datatracker.ietf.org/doc/draft-mirsky-s= fc-pmamm/ CMP: Where the base header borrows a bit for an OAM function. CMP: Neither of those have any impact on the O-bit. Greg Mirsky > I agree that, as we find SFC NSH now, no OAM metadata has been defined. It = appears to me that deprecating the O bit does not affect any of the already= defined mechanisms in the SFC NSH. CMP: It actually does, see my example above. I think that if a new, for example, MD Type =3D 2 TLV that is used for any = OAM functionality to be proposed in the future, deprecated the O bit would = not prevent using such NSH TLV. CMP: I agree with this - because there is no correlation between MD Type fi= eld and O-bit as defined. Best, Carlos. 2/13/22 =1B$B8a8e=1B(B12:32=1B$B!"=1B(BGyan Mishra >=1B$B$N%a!<%k=1B(B: Hi Joel I am in agreement as well with what you have stated that once the O bit is = deprecated that NSH metadata cannot be used for OAM and that we would have = to now from that point forward rely on the next protocol field as we will b= e doing for SFC Multilayer and SFC IOAM drafts as well as will have backwar= ds compatible with any already existing defined mechanisms in SFC NSH. I don=1B$B!G=1B(Bt see any issues or impact with moving forward. Kind Regards Gyan On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky > wrote: Hi Joel, I agree that, as we find SFC NSH now, no OAM metadata has been defined. It = appears to me that deprecating the O bit does not affect any of the already= defined mechanisms in the SFC NSH. I think that if a new, for example, MD = Type =3D 2 TLV that is used for any OAM functionality to be proposed in the= future, deprecated the O bit would not prevent using such NSH TLV. What do you think? Regards, Greg On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern > wrote: There is an implication of deprecating the O-bit that I would like to hear from more WG participants about. As far as I can tell, if we deprecate the O-bit and rely on the next protocol field, we are saying that in practice (not by rule) NSH metadata can not be used for OAM. That's fine with me as long as we agree on that. Yours, Joel On 2/13/2022 2:52 AM, Gyan Mishra wrote: > > Hi Jim, Joel & SFC WG, > > I agree that the RFC 8300 definition of O bit is incomplete and not > clear as to its intended use. > > That is a problem that I agree needs to be rectified. > > I understand that we need to get this resolved before we can progress > Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM. > > I agree that what makes sense to me as a path forward is to deprecate > the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC > Multilayer OAM and SFC IOAM are identified by the respective values for > the NSH Next Protocol field (to be assigned by IANA), as well as so far > no OAM-specific meta data TLV has been yet defined. > > So we have I believe solid solution and path forward and I support > deprecating the O bit. > > Kind Regards > > Gyan > > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky > >> wrote: > > Thank you, Jim and Joel, for guiding the SFC OAM work and pointing > out the issue that must be addressed. > > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I > understand these documents, the Active SFC OAM and IOAM are > identified by the respective values for the NSH Next Protocol field > (to be assigned by IANA). At the same time, so far no OAM-specific > meta data TLV has been defined. Thus, it appears that one way > forward could be to not involve the O bit in the active SFC OAM or > IOAM altogether. In other words, to deprecate the NSH O bit. > > I greatly appreciate your comments on the proposal to deprecate the > NSH O bit. > > Regards, > Greg > > On Wed, Feb 2, 2022 at 10:36 AM James Guichard > > >> wrote: > > Hi WG:____ > > __ __ > > Having reviewed all of the OAM related documents in our WG, the > chairs would like to provide a few comments to hopefully > generate discussion and forward progress of this work:____ > > __ __ > > 1) The chairs have reviewed the O bit definition in RFC 8300. > That definition is at best open to interpretation and therefore > incomplete. For example, the clear intention is only to mark > packets which are intended for SFC OAM at the SFC service > layer. But that is not what the current text says. There is > also, unfortunately, ambiguity as to what constitutes an OAM > packet. So it is reasonable for documents to update 8300 to > clarify the exact applicability and action for the O-bit.____ > > __ __ > > 2) However, related to point 1), we can't have multiple > documents updating the definition differently. As such, the > authors of the SFC iOAM draft and the SFC multi-layer-oam draft > need to come together and figure out what the clarification is > for the definition of that bit. We do not believe as chairs that > either of these documents can move forward from the WG until > such clarity has been reached. ____ > > __ __ > > 3) Related to the SFC iOAM, we need a clear definition of iOAM. > There seem to be differences between the definitions in > published RFCs, the usage (which is not a definition) in the SFC > draft, and the various ippm drafts. Any such definition will > need to be vetted with the ippm working group.____ > > __ __ > > Again, it would be good if members of the working group beyond > the two author teams spoke up about their readings of the > documents, and their understandings of what we need.____ > > __ __ > > Yours,____ > > Jim and Joel____ > > __ __ > > __ __ > > __ __ > > _______________________________________________ > sfc mailing list > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > > -- > > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /Email gyan.s.mishra@verizon.com >// > / > > /M 301 502-1347 > > / > > -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_MN2PR13MB420658D888711F1FC921556BD2339MN2PR13MB4206namp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Carlos,

 =

Some responses in-line = =1B$B!D=1B(B

 =

From: sfc <sfc-bounces@ietf.org&g= t; On Behalf Of Carlos Pignataro (cpignata)
Sent: Sunday, February 13, 2022 11:07 PM
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>; sfc@ietf.org
Subject: Re: [sfc] Progression of OAM work in the SFC WG<= /span>

 

Replying to this specific email in the thread, only = because it is the latest one at this point in time, but bundling comments f= rom various places on the thread. Please find some follow-up comments and q= uestions marked =1B$B!H=1B(BCMP=1B$B!I=1B(B, indicating the =1B$B!H=1B(BFrom=1B$B!I=1B(B, and organized chronologically:

 

James N Guichard <james.n.guichard@futurewei.com>:

 

1) The chairs have reviewed the O bit definition in= RFC 8300.  That definition is at best open to interpretation and ther= efore incomplete.  For example, the clear intention is only to mark packets which are intended for SFC OAM at the SFC service = layer.  But that is not what the current text says.  There is als= o, unfortunately, ambiguity as to what constitutes an OAM packet.  So = it is reasonable for documents to update 8300 to clarify the exact applicability and action for the O-bit.

 

CMP: It is unclear to me what exact issues the chair= s are calling out. There are two issues mentioned:

CMP: 1. "But that is not what the current text = says.=1B$B!I=1B(B —> what does the text say precisely?  Can y= ou point to the specific RFC 8300 text that is believed to be incomplete, a= nd a detailed use case that showcases the potential issue? An extrapolated counter-example just to make a point: the text does not  say what day= s of the week OAM packets can be marked, yet there=1B$B!G=1B(Bs an expectat= ion that they will work Mondays and Saturdays all the same — even hol= idays.

 

Jim> Currently RFC8300 says =1B$B!H=1B(BThe=
 O bit MUST be set for OAM packets and MUST NOT be set for non-OAM packets=
=1B$B!I=1B(B. The first issu=
e is does this mean the O bit should be set for ALL OAM packets regardless =
of whether they belong to the NSH service plane? Or should it only be set f=
or SFC OAM packets? And what exactly is an SFC OAM packet as the earlier re=
ference to RFC6291 is just a generate set of guidelines for the use of the =
term OAM. The second issue is that if that O bit is set then Greg=1B$B!G=1B=
(Bs document is in conflict with IOAM as both use the next protocol field a=
nd even if the O bit is set it is meaningless as the protocol action is bas=
ed solely on the setting of the next protocol field. So in this case can th=
eir solutions simply ignore what RFC 8300 says e.g. MUST set the O bit? Or =
if they set the O bit to be conformant to what RFC 8300 says then do we nee=
d clearer rules stating what to do if the next protocol field is NOT an OAM=
 next protocol such as the context headers should then be examined?

 

 

CMP: 2. What specifically is the ambiguity with what= an OAM packet is? Please grep the RFC series for =1B$B!H=1B(Boam packet=1B= $B!I=1B(B, it is not a new term. 

CMP: Net-net, O-bit=3D1, OAM packet. 

 

Jim> ambiguity is whether it is only SFC OAM pac= kets that are being discussed or ALL OAM packets nothing that some might be= at the service layer and some might not.

 

Jim

 

2) However, related to point 1), we can't have mult= iple documents updating the definition differently.  As such, the auth= ors of the SFC iOAM draft and the SFC multi-layer-oam draft need to come together and figure out what the clarification is for t= he definition of that bit. We do not believe as chairs that either of these= documents can move forward from the WG until such clarity has been reached= .

 

CMP: If there is still believed to be an ambiguity o= r a clear opportunity for improving the definition, I agree with consolidat= ing that update. I had suggested before that if such new text or real clari= fication is agreed, a separate document that only makes that O-bit clarification is the most clear and clean way t= o go. That doc should be a one-pager or less. I=1B$B!G=1B(Bd be happy to co= ntribute to that minimal doc, if it is shown to be needed.

 

CMP: For completeness also, the "SFC multi-laye= r-oam=1B$B!I=1B(B document has many outstanding issues besides the O-bit.

 

Greg Mirsky <gregimirsky@gmail.com>

 

I've reviewed our SFC OAM documents and draft-ietf-s= fc-nsh-tlv. As I understand these documents, the Active SFC OAM and IOAM ar= e identified by the respective values for the NSH Next Protocol field (to b= e assigned by IANA).

 

CMP: There is a major issue with the sentence above.= Active SFC OAM (as a category), as per RFC 8300, needs to be identified by= setting the O-bit. No way around that based on RFC 8300. However, the text= "the Active SFC OAM=1B$B!I=1B(B creates confusion since it refer to a specific OAM protocol which has the same name as a the= category as well. That name collision is quite unfortunate in my opinion.<= o:p>

 

At the same time, so far no OAM-specific meta data T= LV has been defined. Thus, it appears that one way forward could be to not = involve the O bit in the active SFC OAM or IOAM altogether. In other words,= to deprecate the NSH O bit.

 

CMP: RFC 8924 already includes ICMP and BFD as examp= le SFC Action OAM protocols. Those can be encapsulated in IP, in which the = Next-Protocol indicates IP — and (as per RFC 8300) the O-bit is set t= o indicate an OAM packet.

CMP: The proposal of deprecating the O-bit breaks th= ose SFC OAM protocols already included in an RFC.

CMP: That proposal of deprecating the O-bit also bre= aks Section 4.1 of IOAM.

CMP: This expired I-D yet implemented in open source= uses the O-bit: https://www.ietf.org/archive/id/dra= ft-penno-sfc-trace-03.txt 

 

 

Gyan Mishra <hayabusagsm@gmail.com>

 

I agree that what makes sense to me as a path forwar= d is to deprecate the O bit and not use in SFC Multilayer OAM and SFC IOAM,= as both SFC Multilayer OAM and SFC IOAM are identified by the re= spective values for the NSH Next Protocol field (to be assigned by IANA), as well as so far no OAM-specific meta data TLV = has been yet defined.

 

CMP: What is the =1B$B!H=1B(BSFC Multilayer OAM=1B$B= !I=1B(B?

CMP: The O-bit (reading RFC 8300) does not indicate = if there is OAM Metadata. It indicates an OAM packet.

 

 

"Joel M. Halpern" <jmh@joelhalpern.com>

 

As far as I can tell, if we deprecate the O-bit and = rely on the next protocol field, we are saying that in practice (not by rul= e) NSH metadata can not be used for OAM.  That's fine with me as long = as we agree on that.

 

CMP: I do not fully follow this. Can you explain the= relationship of the O-bit with Metadata?

CMP: Here=1B$B!G=1B(Bs an example: RFC 8924 shows IC= MP as Active OAM. The SFC next protocol is IP, the IP next protocol is ICMP= , the O-bit needs to be set. 

 

CMP: Consider the following document, independent su= bmission and in the RFC Publication queue already:

CMP: Is a Timestamp in Metadata an OAM element? = ;

 

CMP: Where the base header borrows a bit for an OAM = function.

 

CMP: Neither of those have any impact on the O-bit.&= nbsp;

 

 

Greg Mirsky <gregimirsky@gmail.com>

 

I agree that, as we find SFC NSH now, no OAM metadat= a has been defined. It appears to me that deprecating the O bit does not af= fect any of the already defined mechanisms in the SFC NSH.

 

CMP: It actually does, see my example above.



I think that if a new, for example, MD Type =3D 2 TL= V that is used for any OAM functionality to be proposed in the future,= deprecated the O bit would not prevent using such NSH TLV.=

 

CMP: I agree with this — because there is no c= orrelation between MD Type field and O-bit as defined.

 

Best,

 

Carlos.

 

 



2/13/22 =1B$B8a8e=1B(B12= :32=1B$B!"=1B(BGyan Mishra <hayabusagsm@gmail.com>= =1B$B$N%a!<%k=1B(B:

 

Hi Joel

 

I am in agreement as well with what you have stated = that once the O bit is deprecated that NSH metadata cannot be used for OAM = and that we would have to now from that point forward rely on the next prot= ocol field as we will be doing for SFC Multilayer and SFC IOAM drafts as well as will have backwards compatib= le with any already existing defined mechanisms in SFC NSH.  

 

I don=1B$B!G=1B(Bt see any issues or impact with mov= ing forward.

 

Kind Regards 

 

Gyan

 

On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky <gregimirsky@gmail.com> wrote:<= o:p>

Hi Joel,

I agree that, as we find SFC NSH now, no OAM metadat= a has been defined. It appears to me that deprecating the O bit does not af= fect any of the already defined mechanisms in the SFC NSH. I thin= k that if a new, for example, MD Type =3D 2 TLV that is used for any OAM functionality to be proposed in the future, = deprecated the O bit would not prevent using such NSH TLV.<= /p>

What do you think?

 

Regards,

Greg

 

On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:

There is an implication of deprecating the O-bit tha= t I would like to
hear from more WG participants about.

As far as I can tell, if we deprecate the O-bit and rely on the next
protocol field, we are saying that in practice (not by rule) NSH
metadata can not be used for OAM.  That's fine with me as long as we <= br> agree on that.

Yours,
Joel

On 2/13/2022 2:52 AM, Gyan Mishra wrote:
>
> Hi Jim, Joel & SFC WG,
>
> I agree that the RFC 8300 definition of O bit is incomplete and not > clear as to its intended use.
>
> That is a problem that I agree needs to be rectified.
>
> I understand that we need to get this resolved before we can progress =
> Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM.
>
> I agree that what makes sense to me as a path forward is to deprecate =
> the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC =
> Multilayer OAM and SFC IOAM are identified by the respective values fo= r
> the NSH Next Protocol field (to be assigned by IANA), as well as so fa= r
> no OAM-specific meta data TLV has been yet defined.
>
> So we have I believe solid solution and path forward and I support > deprecating the O bit.
>
> Kind Regards
>
> Gyan
>
> On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>     Thank you, Jim and Joel, for guiding the SFC OAM wo= rk and pointing
>     out the issue that must be addressed.
>
>     I've reviewed our SFC OAM documents and draft-ietf-= sfc-nsh-tlv. As I
>     understand these documents, the Active SFC OAM and = IOAM are
>     identified by the respective values for the NSH Nex= t Protocol field
>     (to be assigned by IANA). At the same time, so far = no OAM-specific
>     meta data TLV has been defined. Thus, it appears th= at one way
>     forward could be to not involve the O bit in the ac= tive SFC OAM or
>     IOAM altogether. In other words, to deprecate the N= SH O bit.
>
>     I greatly appreciate your comments on the proposal = to deprecate the
>     NSH O bit.
>
>     Regards,
>     Greg
>
>     On Wed, Feb 2, 2022 at 10:36 AM James Guichard
>     <james.n.guichard@futurewei.com
>     <mailto:james.n.guichard@futurewei.com>> wrot= e:
>
>         Hi WG:____
>
>         __ __
>
>         Having reviewed all of the OAM relate= d documents in our WG, the
>         chairs would like to provide a few co= mments to hopefully
>         generate discussion and forward progr= ess of this work:____
>
>         __ __
>
>         1) The chairs have reviewed the O bit= definition in RFC 8300.
>         That definition is at best open to in= terpretation and therefore
>         incomplete.  For example, the cl= ear intention is only to mark
>         packets which are intended for SFC OA= M at the SFC service
>         layer.  But that is not what the= current text says.  There is
>         also, unfortunately, ambiguity as to = what constitutes an OAM
>         packet.  So it is reasonable for= documents to update 8300 to
>         clarify the exact applicability and a= ction for the O-bit.____
>
>         __ __
>
>         2) However, related to point 1), we c= an't have multiple
>         documents updating the definition dif= ferently.  As such, the
>         authors of the SFC iOAM draft and the= SFC multi-layer-oam draft
>         need to come together and figure out = what the clarification is
>         for the definition of that bit. We do= not believe as chairs that
>         either of these documents can move fo= rward from the WG until
>         such clarity has been reached. ____ >
>         __ __
>
>         3) Related to the SFC iOAM, we need a= clear definition of iOAM.
>         There seem to be differences between = the definitions in
>         published RFCs, the usage (which is n= ot a definition) in the SFC
>         draft, and the various ippm drafts.&n= bsp; Any such definition will
>         need to be vetted with the ippm worki= ng group.____
>
>         __ __
>
>         Again, it would be good if members of= the working group beyond
>         the two author teams spoke up about t= heir readings of the
>         documents, and their understandings o= f what we need.____
>
>         __ __
>
>         Yours,____
>
>         Jim and Joel____
>
>         __ __
>
>         __ __
>
>         __ __
>
>         _____________________________________= __________
>         sfc mailing list
>         sfc@ietf.org <mailto:sfc@ietf.org>
>         https://www.ietf.org= /mailman/listinfo/sfc
>         <https://www.= ietf.org/mailman/listinfo/sfc>
>
>     _______________________________________________
>     sfc mailing list
>     s= fc@ietf.org <mailto:sfc@ietf.org>
>     https://www.ietf.org/mailman/l= istinfo/sfc
>     <https://www.ietf.org/mailm= an/listinfo/sfc>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /Email = gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>//
> /
>
> /M 301 502-1347
>
> /
>
>

--

Gyan Mishra

Network Solutions = Architect <= /p>

M 301 502-13= 47

 

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

 

--_000_MN2PR13MB420658D888711F1FC921556BD2339MN2PR13MB4206namp_-- From nobody Mon Feb 14 07:06:25 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C2C3A1007 for ; Mon, 14 Feb 2022 07:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.484 X-Spam-Level: X-Spam-Status: No, score=-9.484 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GcSlgwUn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dSCqTvyr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlcKceSCPwgL for ; Mon, 14 Feb 2022 07:06:14 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F05F3A1003 for ; Mon, 14 Feb 2022 07:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=92833; q=dns/txt; s=iport; t=1644851173; x=1646060773; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aVIW/CSc4LlLB9GA1q9toNlHGgjtbHWnyNrXh77SkuY=; b=GcSlgwUnPGt2sQAvUZ6c6atkblrfHE52HTxKoGkQvKJVLT1aEDSBhgFO x0jYxNnRnP3Ck15GTahf38DxatCOEdsPdUD92IaDBonZhzEEZvavLjnF2 M3dhiwNrH6cEVzS/X8cGvP7GTFoYfO2o6BttVqD1SM3kNuH4X0hJ9qPsZ w=; IronPort-PHdr: =?us-ascii?q?A9a23=3ArV+sTBIUVTG/rjgVgtmcuWEyDhhOgF28FgIW6?= =?us-ascii?q?59yjbVIf+zj+pn5J0XQ6L1ri0OBRoTU7f9Iyo+0+6DtUGAN+9CN5XYFdpEfW?= =?us-ascii?q?xoMk85DmQsmDYaMAlH6K/i/aSs8EYxCWVZp8mv9P1JSHZP1ZkbZpTu56jtBc?= =?us-ascii?q?ig=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AMSxCgKKlIpKya2HXFE+RN5clxSXFcZb7ZxGr2?= =?us-ascii?q?PjKsXjdYENShDEEnzdOUGuBOqrYN2r3eNEjboSy8koEv5OBy4VgTVYd+CA2R?= =?us-ascii?q?RqmiyZq6fd1j6vI0qj7wvTrFCqL1O1DLImQRCwIZiWE/E31aOC49SAUOZygH?= =?us-ascii?q?9IQNsaVYkideic8IMsRoUoLd98R2uaEs/Dga+++kYuaT/nkBbOQ82Uc3lT4R?= =?us-ascii?q?E60gEgHUPza4Fv0t7GlDBxBlAe2e3I9VPrzKUwtRkYUTLW4HsbiLwrC5Kuy8?= =?us-ascii?q?mWc9BA3B5b61L36aUYNBLXVOGBiiFIPBPPk2UcE93d0i/pgXBYfQR8/ZzGhl?= =?us-ascii?q?Mhwx9NEqZWYQgYyNaqKk+MYO/VdO34kY/UeqO+XfBBTtuTWlSUqaUDE2PtlJ?= =?us-ascii?q?EA7IYNe/fx4aUlB7/EXKTUMdAuAlsq5xbu6Tq9ngcFLBMniLYoVp2ppwircJ?= =?us-ascii?q?fkjSJHHBa7N4Ldw3j41i9sIG7DRessSaTN1YDzOfgFSIFoIBZN4l+Ct7kQT2?= =?us-ascii?q?RUwREm9v6E75S3YyxZ8leerO9vOcdvMTsJQ9nt0b1nupwzRaiz2/vTGodZdz?= =?us-ascii?q?k+Ruw=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AoWki/qoJfvFS8QoSI9GHhiIaV5uIL9V00z?= =?us-ascii?q?EX/kB9WHVpm5Oj9vxGzc506farslkssSkb6K+90KnpewK6yXcH2/huAV7CZn?= =?us-ascii?q?imhILMFuFfBOTZskbd8kHFh4tgPOJbAtRD4b7LfBhHZKTBkXOF+r8bqbHtms?= =?us-ascii?q?3F9ISurUuFDzsaFp2IhD0JbDpzZ3cGPDWucqBJbaZ0iPA3wwaISDAyVICWF3?= =?us-ascii?q?MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWna4j4uFxd0hZsy+2nMlAL0oo?= =?us-ascii?q?+5teug9xPa32jPq7xLhdrazMdZDsDksLlWFtyssHfsWG1SYczEgNkHmpDo1L?= =?us-ascii?q?/sqqiUn/4UBbU215oWRBDsnfKi4Xi67N9k0Q6S9bbRuwqSnSW+fkNhNyKE7r?= =?us-ascii?q?gpLicwLCEbzYxBOetwrhCknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTO?= =?us-ascii?q?IlGfNsRRx2xjInLH4sJlOx1GkcKpgiMCgc3ochTXqKK3TC+mV/yt2lWXo+Wh?= =?us-ascii?q?+AX0gZo8SQlzxbhmpwwUcUzNEW2i5ozuNyd7BUo+Dfdqh4nrBHScEbKap7Ge?= =?us-ascii?q?caWMOyTmjAWwjFPm6eKUnuUKsHJ3XOoZjq56hd3pDkRLUYiJ8p3JjRWlJRsm?= =?us-ascii?q?A/P0roFM2VxZVOtgvARW2sNA6dgf22J6IJ8oEUaICbRRFreWpe2vdI+c9vd/?= =?us-ascii?q?Ezc8zDT65rPw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAAAZHvlh/49dJa1XAxsBAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQGCBgYBAQELAYEgMSguB3daEyQxA4RGg0cDhFlghQ6?= =?us-ascii?q?DAgOBE4l9kBSBLhSBEQNPBQsBAQENAQEqAQkNBAEBgieCXgIXg0gCJTQJDgE?= =?us-ascii?q?CBAEBARIBAQUBAQECAQYEgQkThWgNhkIBAQEBAwEBEAgBCB0BASwEBwEPAgE?= =?us-ascii?q?GAgcKBAEBASABBgMCAgIfBgsUCQgCBA4FGweCXQQBAYIOVwMuAQ6Sc482AYE?= =?us-ascii?q?6AoofeoExgQGCCAEBBgQEgTYBE0GDAgMKC4I3CYEjFwGDDYQcAQGBHoVpJxy?= =?us-ascii?q?BSUSBFSccgWZKBzA+giFCAQECAReBEQESASAYCgwJCAmCURcggi6RLBoBFEY?= =?us-ascii?q?tFyYBAy8UDwEEARsCDSwgFjICEgMFNQseAigQkXQUCYJ3R4lOP4NBiXKQdD9?= =?us-ascii?q?DawqDRosBiC6GNYV5BS6DcowcWpcflkqCR4pIg06RRYQgAgQCBAUCDgEBBoF?= =?us-ascii?q?hPA1ccHAVOyoBgj4JCisTGQ+NfiKDcYUUhUp0AgEBATMCBgEKAQEDCYxvXQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208,217";a="726008885" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Feb 2022 15:06:10 +0000 Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 21EF69P7018236 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 14 Feb 2022 15:06:09 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 14 Feb 2022 09:06:09 -0600 Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 14 Feb 2022 09:06:09 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Mon, 14 Feb 2022 10:06:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PZngvigxHiqSDi4OyoReL0oRibqhhEA6Rh7LI4xEKdTL7fmUSXJcN8f9TL673ZzhoxdC/ezr7Jy90X92sZPpeFdmC6wJlqk+KgGfPTZbJZQy9nImwyPXiOdNpptJYOjSG3SKIyDYdV4lzf6batWq+gyyO9UryajeZn1u6KsVUPhD/Komxde6h86+/N+fYGIvQuxdp+Lif/5Ci80kuO8d1CTsUnt+Nil/KkjJ9yGJUWb1eFPb8LS4FuI1wxYAnao8/DmpPxkcydGRQ21iDvBxIix6vc/jwTPVCa6dYsUKM8UXgHSiTfTA5gRjz3ign4G6F+DYC2RbWGHBjfZJ+AOWYA== 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=aVIW/CSc4LlLB9GA1q9toNlHGgjtbHWnyNrXh77SkuY=; b=X7V3ruEjzeFBW6+UipHkdubAGqX0suPXbz7SrHMhJXCM64X714Bz4y5J6xADkuv/fqCQDyaAptv2ngsUVGLdmD9qMZ2f35JBdIacvTGf75iRS3pkVPlsu3d6W2asx2cCAZFai37VUOYZJTCnLU6R2E0UP0HRoPtvoK5jOVUkEuJ/MeEFcViRKWPOBfMTnqtYV5JABenTHlj83g984fa8Q+DXBuKNBjDjfoCjWFR3jXvcQj0AzeMB6uaIo8ELYxdYyztP0OnNp+sl/9lIioTgy2wa76jtmhA1KYUXfUtp4TLWxOdC4bK1BEt2QyTo+ldogJX3tQRfC2u7vsrSVXCzVw== 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=aVIW/CSc4LlLB9GA1q9toNlHGgjtbHWnyNrXh77SkuY=; b=dSCqTvyr8RQHZ1JzCismlFMhfqqpElaDn+xpJwJJsU+O3JkN0AwI0EkgxQTJ6g6wZNrsg+1WgVSsQV4fhJTkeGDA9C5CCd1jDyniWhsFShdWdBocEVPYXYMZYe+GoyXP/ria4nFRVx7BpoJ0+BRbJeoLSmdw9EKMftSjZ6XShV0= Received: from DS7PR11MB6039.namprd11.prod.outlook.com (2603:10b6:8:76::6) by BL0PR11MB2931.namprd11.prod.outlook.com (2603:10b6:208:7d::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11; Mon, 14 Feb 2022 15:06:06 +0000 Received: from DS7PR11MB6039.namprd11.prod.outlook.com ([fe80::e131:742a:954d:492c]) by DS7PR11MB6039.namprd11.prod.outlook.com ([fe80::e131:742a:954d:492c%6]) with mapi id 15.20.4975.012; Mon, 14 Feb 2022 15:06:06 +0000 From: "Carlos Pignataro (cpignata)" To: James N Guichard CC: Gyan Mishra , Greg Mirsky , "sfc@ietf.org" Thread-Topic: [sfc] Progression of OAM work in the SFC WG Thread-Index: AdgYYtG+l/ju054uSCa0IEDodR5p4AAI1AYAAgogAwAADsqJgAAEeXQAAAD7PAAAFinEAAAVIwJwAAHkVoA= Date: Mon, 14 Feb 2022 15:06:06 +0000 Message-ID: References: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.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.3693.60.0.1.1) 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: a16ee3ae-9eab-47f4-e4ba-08d9efcb86c6 x-ms-traffictypediagnostic: BL0PR11MB2931: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: KYHEDpN3M7UutO8HCwwxh1qKx9kWyGatW6WUOFIGPGaT5fB4lTF0g/wHt6i87jK8yuN+/PEbQbKOmdkj2kV+qZbsK9NNG59x3Rhs3SXe3/PpCSuWg17FkXIZ6fuumPxzWoparEMc/D/GNxflH/pwF5gVjSbKdq4pG+mJsY60F7LeZIf2z6BdY7Ifmx2Ff7a1CrJAtq41771EhE+mQyl8t+mWrkNBUjBHtAswbAECSE6juKKLffG3X8qItdbKbWX6TNST3vAQkybN5I1lFzdWMVwtnZUakAd2PI5N9QS3J4NoDOdFmZHPGBmEfL5NZbTtwTxpjTvVvX+ULdAZIuUyl77W2IyyuRholuz83fSbwkmXS14OqO7GqUYutyJ7zGFlNhJ3XFp/0tpOzD+Ng8msdRBExq6CeiAhG0k0AxA/1wHKRa0mys/Q9SGbZVBFObjxtHkF2mJIvr/numQ3gbNWXoEd2edK66U0DjVwMEqEpyzOLePOOCKb+79Tp1aL1GlzdymOO0qo/PyxT7816zlc7pch2DfNkZtZ/1AyW6Gx7uQE/Tvnw5e6S7wh/hNHYRgIi+wmzIj1vCORRgNFAqI/G69zL+KhJ9N1l1szHoCHauOvNp7KP6uKtxW6sNhqOws4kIKYHAlgv/+XlbdmW8/JmtHl3F01sDTI91GKX2rjlBxO8njakEhlAJsS2wgjBKZLIgI74sfGumYFnMh6BfCe9Bs28ZKJNqOKxFJk/08EYPmUsG2Zcal0HPoeSAnBjecxU7+v7BilYFUTgeU1gFu0MbPRJsIg8cjOJ6QXN09UAND0/qcKQxA6jRoP2OgAO04gZB99GEhoILEYEpl3A2n/KyNW6G0AOHgpPMwuZ+bJ5aU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS7PR11MB6039.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(166002)(6916009)(33656002)(36756003)(316002)(2616005)(26005)(186003)(54906003)(71200400001)(38100700002)(508600001)(6486002)(966005)(122000001)(53546011)(2906002)(8676002)(6506007)(6512007)(40140700001)(4326008)(86362001)(76116006)(91956017)(64756008)(66446008)(66476007)(66556008)(66946007)(38070700005)(8936002)(5660300002)(30864003)(83380400001)(45980500001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SnhVOTBnOExQUlVEU3RHRmY5WFpYMDFNZmM4aGpFbG1EZWhjUmliUTZSSzhP?= =?utf-8?B?K01JSUJrMEVkaWlYQ3NvdU9JYVlwMVlKYlMxejhGUXNjZ2VMQmNpMFlCbDVP?= =?utf-8?B?ZXBpUk9rY0hyY3NqdEh2ZVpJLzNwcitPQ3ZOT0luaUM1OWFzc3FZM21qY3NR?= =?utf-8?B?amZwREU4WGVjSDhSZ0lYS0FGWGJhcEptb2pmaUxwc2ZHK3d4MXIrVUtOSTQ2?= =?utf-8?B?b0F1YVlaMTk5L05ReDA0anhXMmxOVDBrM0o3MEpIeGY1MENObmZCZFFGMVd3?= =?utf-8?B?STBkWnhUdEJCZElzSU9OZ1VCRjNHYzdHS2pBWFJabDFialpudEVUR3BqR1Mx?= =?utf-8?B?L2RpY05QRTljdFFwOWZxMTNnL2V6NURMcEdSUVZsV2RVTmRCYXNFcTJIQXVz?= =?utf-8?B?djFTSmthWGJwQTlqSkl4c1IwWlJSOUp0ZTAvbnM1QW5ScXBqSkEwUEpKVmdh?= =?utf-8?B?VHlFN2lwNlROdmtRT3lua1hyNmIvRk1uSnlCNHplK0ZOdm1xcVkvTnNnaHhX?= =?utf-8?B?bXdiWklYc2FOakFxdjlVbWhPL1ZyM2FwUEZyOXNzUTlueEhQeUYzRjBvVTFp?= =?utf-8?B?MmRvMTVoTnhXSU01K3g5dnorUXBHbHFSVG1DV1NCdzlqUnVwZG9FSWxEWHkv?= =?utf-8?B?Mlg3MkUvNlFLU2hFV1N6YkE3ZVpOaUZTQlF6WVFOL3JQOFRsY282VmZyTDdw?= =?utf-8?B?TitWQ01HUGhrTVcyQWlXbFAweWIyWk91Y0FRdlp3cDRyQ1lyMS9VbUFGUTJi?= =?utf-8?B?Y1EyVDAwaUtYTFh3UVoxa2JqbGFkcllmMU4ydEpSVlVITnlJTkNNdU52SXdx?= =?utf-8?B?TnlDTGVGMWtMempaVmx2bDVqcnFFVGVOWW43Um5HMmdiWnIwU0xvSnNBd2Z3?= =?utf-8?B?S3EwZjJKTzUxdE5VSXhhQjM4R0REcHdpTDkxTk13SW1GQUJUU3MwT2FuTklu?= =?utf-8?B?YXZoUVFTb0FGeWZsamNoNmN3ckhrRlRGL2hicWh5Mkx2cUFzbU9sTkJaSWhy?= =?utf-8?B?V0FnVlE5MUVmdk4wMUxmYWJuMUxoWUNNckgzRDFsSEpEUVRybXA1a20rZVc2?= =?utf-8?B?N0hKaW5WYXdhK0VHRnZvVnpNWnprd3A4TnMwQVRvWlVqcldqeFJMS2J1bmVJ?= =?utf-8?B?dTRrdjFRNUVZSWFIMVVyQnlzOXBCZ0hpMG9rMmlqa0JnQW9UcGFHTU5MYmNm?= =?utf-8?B?MG9YbVlUcHROR3lEeEo3dzFabm55VnNCcmFuWURMVWxMcWVXR08xZ2FZbWww?= =?utf-8?B?ajArOVZKU3lRWStiSys2cHc2ZU9yWHRodHQ5RnpmWUpmYTkwVkc5dGxtSnhC?= =?utf-8?B?dkxvM2NidWZsMFFMbzBEd3BkSS81aHBlMEtocWxJSGVmZWFGcTZjT0ZWYzlK?= =?utf-8?B?emZkTW5iTUNkSXRNOVREUThMbStTSi9jMG1KMjZwLzdTY2diMktKeW9vVWdi?= =?utf-8?B?emkzZGllRG9RTzB1SmNaditIUCs2NHp5Z01iN3U5ZXQzdFhvTVhxZUNFUC9L?= =?utf-8?B?RFlyVjFtNVlKb2l5R1gxSmcyNktJWk41K01hZ2lDbXNnVUpCTUJnYjkyRWxP?= =?utf-8?B?TlFDT3dYUExpcDZOVk90U0ErTlhnVEhyNkJ2VGtNeVo1bUk3NGRaRVRkamY0?= =?utf-8?B?dUNoQXFPaU1TaFVCV3preW5MdlFpSmovK3F5aVBDZEhCdlFNeFppMFFCNEtM?= =?utf-8?B?bnJGZlF2dXN1RlRReWgxK24zR0lLcyt4N3g5TlluTDY1Nk83Q0ZzZURLUEdS?= =?utf-8?B?REczczZUWDJTNlFMbU9NSHE5M3FTcWtqcHhXWjBQOFErcFJjWDlxamo3NnpM?= =?utf-8?B?eTc4OEZOZWI2dmVNdk1Qd0NlZktURmVsb3NOdFgyQ01rODZNRjlNeFcwbFFU?= =?utf-8?B?ckYzc2g2UE9uQmhPa0VpMERqWG5KMGx0QkdZdTVPdDVRM1BJZTJHaEtyZ3pF?= =?utf-8?B?clNYVkVEdUdGVUtBMVdDTUxFTXRJRVRueVpSaGF1UGRTOWxQYkxpeXJwYVls?= =?utf-8?B?OWtDelNaeC9WbXRrd3pQSXFmUE9NSlVHbExEQ1oyay9tRjZvQ0FHYm5pd2Rm?= =?utf-8?B?aG1qOGplU0FUN3Bod1drMW1zb0VFL1BrbU92Y1FtS2VRR2lYd21UVkZ0d3A1?= =?utf-8?B?ei9abGVsSGNuRVdpa2FxN0JMd1laRnRnOXZMcCtyS1h1bjBVVGE5MHdkOUV2?= =?utf-8?Q?ds8vdr/yJu2a4K6zO45BBts=3D?= Content-Type: multipart/alternative; boundary="_000_D501B10D8AA64D679A57F799BE9CD517ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB6039.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a16ee3ae-9eab-47f4-e4ba-08d9efcb86c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2022 15:06:06.7123 (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: 31G8GntnGj21m8X+4FaQzA15AkNwgonTKGvNw1KzYw5zjRf9a9jJ9hBEd2Jwk7m71EKTLho4bnswhcYjVA0foQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2931 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 15:06:22 -0000 --_000_D501B10D8AA64D679A57F799BE9CD517ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIOKAlCBJ4oCZZCBleHBlY3QgU0ZDIE9BTSBsYXllciBwYWNrZXRzIG9ubHksIGFuZCB3 b3VsZCBhbHNvIGV4cGVjdCBhIG1vZGVsIHRoYXQgd29ya3MgZXF1YWxseSB3aXRoIG11bHRpbGF5 ZXItb2FtIGFwcHJvYWNoZXMgb3Igd2l0aCBleGlzdGluZyBPQU1zLg0KDQpUaGFua3MhDQoNCkNh cmxvcy4NCg0KMi8xNC8yMiDljYjliY05OjI444CBSmFtZXMgR3VpY2hhcmQgPGphbWVzLm4uZ3Vp Y2hhcmRAZnV0dXJld2VpLmNvbTxtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29t Pj7jga7jg6Hjg7zjg6s6DQoNCkhpIENhcmxvcywNCg0KU29tZSByZXNwb25zZXMgaW4tbGluZSDi gKYNCg0KRnJvbTogc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQpTZW50 OiBTdW5kYXksIEZlYnJ1YXJ5IDEzLCAyMDIyIDExOjA3IFBNDQpUbzogR3lhbiBNaXNocmEgPGhh eWFidXNhZ3NtQGdtYWlsLmNvbTxtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tPj4NCkNjOiBH cmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFp bC5jb20+Pjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W3NmY10gUHJvZ3Jlc3Npb24gb2YgT0FNIHdvcmsgaW4gdGhlIFNGQyBXRw0KDQpSZXBseWluZyB0 byB0aGlzIHNwZWNpZmljIGVtYWlsIGluIHRoZSB0aHJlYWQsIG9ubHkgYmVjYXVzZSBpdCBpcyB0 aGUgbGF0ZXN0IG9uZSBhdCB0aGlzIHBvaW50IGluIHRpbWUsIGJ1dCBidW5kbGluZyBjb21tZW50 cyBmcm9tIHZhcmlvdXMgcGxhY2VzIG9uIHRoZSB0aHJlYWQuIFBsZWFzZSBmaW5kIHNvbWUgZm9s bG93LXVwIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgbWFya2VkIOKAnENNUOKAnSwgaW5kaWNhdGlu ZyB0aGUg4oCcRnJvbeKAnSwgYW5kIG9yZ2FuaXplZCBjaHJvbm9sb2dpY2FsbHk6DQoNCkphbWVz IE4gR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTxtYWlsdG86amFtZXMu bi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPj46DQoNCjEpIFRoZSBjaGFpcnMgaGF2ZSByZXZpZXdl ZCB0aGUgTyBiaXQgZGVmaW5pdGlvbiBpbiBSRkMgODMwMC4gIFRoYXQgZGVmaW5pdGlvbiBpcyBh dCBiZXN0IG9wZW4gdG8gaW50ZXJwcmV0YXRpb24gYW5kIHRoZXJlZm9yZSBpbmNvbXBsZXRlLiAg Rm9yIGV4YW1wbGUsIHRoZSBjbGVhciBpbnRlbnRpb24gaXMgb25seSB0byBtYXJrIHBhY2tldHMg d2hpY2ggYXJlIGludGVuZGVkIGZvciBTRkMgT0FNIGF0IHRoZSBTRkMgc2VydmljZSBsYXllci4g IEJ1dCB0aGF0IGlzIG5vdCB3aGF0IHRoZSBjdXJyZW50IHRleHQgc2F5cy4gIFRoZXJlIGlzIGFs c28sIHVuZm9ydHVuYXRlbHksIGFtYmlndWl0eSBhcyB0byB3aGF0IGNvbnN0aXR1dGVzIGFuIE9B TSBwYWNrZXQuICBTbyBpdCBpcyByZWFzb25hYmxlIGZvciBkb2N1bWVudHMgdG8gdXBkYXRlIDgz MDAgdG8gY2xhcmlmeSB0aGUgZXhhY3QgYXBwbGljYWJpbGl0eSBhbmQgYWN0aW9uIGZvciB0aGUg Ty1iaXQuDQoNCkNNUDogSXQgaXMgdW5jbGVhciB0byBtZSB3aGF0IGV4YWN0IGlzc3VlcyB0aGUg Y2hhaXJzIGFyZSBjYWxsaW5nIG91dC4gVGhlcmUgYXJlIHR3byBpc3N1ZXMgbWVudGlvbmVkOg0K Q01QOiAxLiAiQnV0IHRoYXQgaXMgbm90IHdoYXQgdGhlIGN1cnJlbnQgdGV4dCBzYXlzLuKAnSDi gJQ+IHdoYXQgZG9lcyB0aGUgdGV4dCBzYXkgcHJlY2lzZWx5PyAgQ2FuIHlvdSBwb2ludCB0byB0 aGUgc3BlY2lmaWMgUkZDIDgzMDAgdGV4dCB0aGF0IGlzIGJlbGlldmVkIHRvIGJlIGluY29tcGxl dGUsIGFuZCBhIGRldGFpbGVkIHVzZSBjYXNlIHRoYXQgc2hvd2Nhc2VzIHRoZSBwb3RlbnRpYWwg aXNzdWU/IEFuIGV4dHJhcG9sYXRlZCBjb3VudGVyLWV4YW1wbGUganVzdCB0byBtYWtlIGEgcG9p bnQ6IHRoZSB0ZXh0IGRvZXMgbm90ICBzYXkgd2hhdCBkYXlzIG9mIHRoZSB3ZWVrIE9BTSBwYWNr ZXRzIGNhbiBiZSBtYXJrZWQsIHlldCB0aGVyZeKAmXMgYW4gZXhwZWN0YXRpb24gdGhhdCB0aGV5 IHdpbGwgd29yayBNb25kYXlzIGFuZCBTYXR1cmRheXMgYWxsIHRoZSBzYW1lIOKAlCBldmVuIGhv bGlkYXlzLg0KDQoNCkppbT4gQ3VycmVudGx5IFJGQzgzMDAgc2F5cyDigJxUaGUgTyBiaXQgTVVT VCBiZSBzZXQgZm9yIE9BTSBwYWNrZXRzIGFuZCBNVVNUIE5PVCBiZSBzZXQgZm9yIG5vbi1PQU0g cGFja2V0c+KAnS4gVGhlIGZpcnN0IGlzc3VlIGlzIGRvZXMgdGhpcyBtZWFuIHRoZSBPIGJpdCBz aG91bGQgYmUgc2V0IGZvciBBTEwgT0FNIHBhY2tldHMgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRo ZXkgYmVsb25nIHRvIHRoZSBOU0ggc2VydmljZSBwbGFuZT8gT3Igc2hvdWxkIGl0IG9ubHkgYmUg c2V0IGZvciBTRkMgT0FNIHBhY2tldHM/IEFuZCB3aGF0IGV4YWN0bHkgaXMgYW4gU0ZDIE9BTSBw YWNrZXQgYXMgdGhlIGVhcmxpZXIgcmVmZXJlbmNlIHRvIFJGQzYyOTEgaXMganVzdCBhIGdlbmVy YXRlIHNldCBvZiBndWlkZWxpbmVzIGZvciB0aGUgdXNlIG9mIHRoZSB0ZXJtIE9BTS4gVGhlIHNl Y29uZCBpc3N1ZSBpcyB0aGF0IGlmIHRoYXQgTyBiaXQgaXMgc2V0IHRoZW4gR3JlZ+KAmXMgZG9j dW1lbnQgaXMgaW4gY29uZmxpY3Qgd2l0aCBJT0FNIGFzIGJvdGggdXNlIHRoZSBuZXh0IHByb3Rv Y29sIGZpZWxkIGFuZCBldmVuIGlmIHRoZSBPIGJpdCBpcyBzZXQgaXQgaXMgbWVhbmluZ2xlc3Mg YXMgdGhlIHByb3RvY29sIGFjdGlvbiBpcyBiYXNlZCBzb2xlbHkgb24gdGhlIHNldHRpbmcgb2Yg dGhlIG5leHQgcHJvdG9jb2wgZmllbGQuIFNvIGluIHRoaXMgY2FzZSBjYW4gdGhlaXIgc29sdXRp b25zIHNpbXBseSBpZ25vcmUgd2hhdCBSRkMgODMwMCBzYXlzIGUuZy4gTVVTVCBzZXQgdGhlIE8g Yml0PyBPciBpZiB0aGV5IHNldCB0aGUgTyBiaXQgdG8gYmUgY29uZm9ybWFudCB0byB3aGF0IFJG QyA4MzAwIHNheXMgdGhlbiBkbyB3ZSBuZWVkIGNsZWFyZXIgcnVsZXMgc3RhdGluZyB3aGF0IHRv IGRvIGlmIHRoZSBuZXh0IHByb3RvY29sIGZpZWxkIGlzIE5PVCBhbiBPQU0gbmV4dCBwcm90b2Nv bCBzdWNoIGFzIHRoZSBjb250ZXh0IGhlYWRlcnMgc2hvdWxkIHRoZW4gYmUgZXhhbWluZWQ/DQoN Cg0KDQpDTVA6IDIuIFdoYXQgc3BlY2lmaWNhbGx5IGlzIHRoZSBhbWJpZ3VpdHkgd2l0aCB3aGF0 IGFuIE9BTSBwYWNrZXQgaXM/IFBsZWFzZSBncmVwIHRoZSBSRkMgc2VyaWVzIGZvciDigJxvYW0g cGFja2V04oCdLCBpdCBpcyBub3QgYSBuZXcgdGVybS4NCkNNUDogTmV0LW5ldCwgTy1iaXQ9MSwg T0FNIHBhY2tldC4NCg0KSmltPiBhbWJpZ3VpdHkgaXMgd2hldGhlciBpdCBpcyBvbmx5IFNGQyBP QU0gcGFja2V0cyB0aGF0IGFyZSBiZWluZyBkaXNjdXNzZWQgb3IgQUxMIE9BTSBwYWNrZXRzIG5v dGhpbmcgdGhhdCBzb21lIG1pZ2h0IGJlIGF0IHRoZSBzZXJ2aWNlIGxheWVyIGFuZCBzb21lIG1p Z2h0IG5vdC4NCg0KSmltDQoNCjIpIEhvd2V2ZXIsIHJlbGF0ZWQgdG8gcG9pbnQgMSksIHdlIGNh bid0IGhhdmUgbXVsdGlwbGUgZG9jdW1lbnRzIHVwZGF0aW5nIHRoZSBkZWZpbml0aW9uIGRpZmZl cmVudGx5LiAgQXMgc3VjaCwgdGhlIGF1dGhvcnMgb2YgdGhlIFNGQyBpT0FNIGRyYWZ0IGFuZCB0 aGUgU0ZDIG11bHRpLWxheWVyLW9hbSBkcmFmdCBuZWVkIHRvIGNvbWUgdG9nZXRoZXIgYW5kIGZp Z3VyZSBvdXQgd2hhdCB0aGUgY2xhcmlmaWNhdGlvbiBpcyBmb3IgdGhlIGRlZmluaXRpb24gb2Yg dGhhdCBiaXQuIFdlIGRvIG5vdCBiZWxpZXZlIGFzIGNoYWlycyB0aGF0IGVpdGhlciBvZiB0aGVz ZSBkb2N1bWVudHMgY2FuIG1vdmUgZm9yd2FyZCBmcm9tIHRoZSBXRyB1bnRpbCBzdWNoIGNsYXJp dHkgaGFzIGJlZW4gcmVhY2hlZC4NCg0KQ01QOiBJZiB0aGVyZSBpcyBzdGlsbCBiZWxpZXZlZCB0 byBiZSBhbiBhbWJpZ3VpdHkgb3IgYSBjbGVhciBvcHBvcnR1bml0eSBmb3IgaW1wcm92aW5nIHRo ZSBkZWZpbml0aW9uLCBJIGFncmVlIHdpdGggY29uc29saWRhdGluZyB0aGF0IHVwZGF0ZS4gSSBo YWQgc3VnZ2VzdGVkIGJlZm9yZSB0aGF0IGlmIHN1Y2ggbmV3IHRleHQgb3IgcmVhbCBjbGFyaWZp Y2F0aW9uIGlzIGFncmVlZCwgYSBzZXBhcmF0ZSBkb2N1bWVudCB0aGF0IG9ubHkgbWFrZXMgdGhh dCBPLWJpdCBjbGFyaWZpY2F0aW9uIGlzIHRoZSBtb3N0IGNsZWFyIGFuZCBjbGVhbiB3YXkgdG8g Z28uIFRoYXQgZG9jIHNob3VsZCBiZSBhIG9uZS1wYWdlciBvciBsZXNzLiBJ4oCZZCBiZSBoYXBw eSB0byBjb250cmlidXRlIHRvIHRoYXQgbWluaW1hbCBkb2MsIGlmIGl0IGlzIHNob3duIHRvIGJl IG5lZWRlZC4NCg0KQ01QOiBGb3IgY29tcGxldGVuZXNzIGFsc28sIHRoZSAiU0ZDIG11bHRpLWxh eWVyLW9hbeKAnSBkb2N1bWVudCBoYXMgbWFueSBvdXRzdGFuZGluZyBpc3N1ZXMgYmVzaWRlcyB0 aGUgTy1iaXQuDQoNCkdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdy ZWdpbWlyc2t5QGdtYWlsLmNvbT4+DQoNCkkndmUgcmV2aWV3ZWQgb3VyIFNGQyBPQU0gZG9jdW1l bnRzIGFuZCBkcmFmdC1pZXRmLXNmYy1uc2gtdGx2LiBBcyBJIHVuZGVyc3RhbmQgdGhlc2UgZG9j dW1lbnRzLCB0aGUgQWN0aXZlIFNGQyBPQU0gYW5kIElPQU0gYXJlIGlkZW50aWZpZWQgYnkgdGhl IHJlc3BlY3RpdmUgdmFsdWVzIGZvciB0aGUgTlNIIE5leHQgUHJvdG9jb2wgZmllbGQgKHRvIGJl IGFzc2lnbmVkIGJ5IElBTkEpLg0KDQpDTVA6IFRoZXJlIGlzIGEgbWFqb3IgaXNzdWUgd2l0aCB0 aGUgc2VudGVuY2UgYWJvdmUuIEFjdGl2ZSBTRkMgT0FNIChhcyBhIGNhdGVnb3J5KSwgYXMgcGVy IFJGQyA4MzAwLCBuZWVkcyB0byBiZSBpZGVudGlmaWVkIGJ5IHNldHRpbmcgdGhlIE8tYml0LiBO byB3YXkgYXJvdW5kIHRoYXQgYmFzZWQgb24gUkZDIDgzMDAuIEhvd2V2ZXIsIHRoZSB0ZXh0ICJ0 aGUgQWN0aXZlIFNGQyBPQU3igJ0gY3JlYXRlcyBjb25mdXNpb24gc2luY2UgaXQgcmVmZXIgdG8g YSBzcGVjaWZpYyBPQU0gcHJvdG9jb2wgd2hpY2ggaGFzIHRoZSBzYW1lIG5hbWUgYXMgYSB0aGUg Y2F0ZWdvcnkgYXMgd2VsbC4gVGhhdCBuYW1lIGNvbGxpc2lvbiBpcyBxdWl0ZSB1bmZvcnR1bmF0 ZSBpbiBteSBvcGluaW9uLg0KDQpBdCB0aGUgc2FtZSB0aW1lLCBzbyBmYXIgbm8gT0FNLXNwZWNp ZmljIG1ldGEgZGF0YSBUTFYgaGFzIGJlZW4gZGVmaW5lZC4gVGh1cywgaXQgYXBwZWFycyB0aGF0 IG9uZSB3YXkgZm9yd2FyZCBjb3VsZCBiZSB0byBub3QgaW52b2x2ZSB0aGUgTyBiaXQgaW4gdGhl IGFjdGl2ZSBTRkMgT0FNIG9yIElPQU0gYWx0b2dldGhlci4gSW4gb3RoZXIgd29yZHMsIHRvIGRl cHJlY2F0ZSB0aGUgTlNIIE8gYml0Lg0KDQpDTVA6IFJGQyA4OTI0IGFscmVhZHkgaW5jbHVkZXMg SUNNUCBhbmQgQkZEIGFzIGV4YW1wbGUgU0ZDIEFjdGlvbiBPQU0gcHJvdG9jb2xzLiBUaG9zZSBj YW4gYmUgZW5jYXBzdWxhdGVkIGluIElQLCBpbiB3aGljaCB0aGUgTmV4dC1Qcm90b2NvbCBpbmRp Y2F0ZXMgSVAg4oCUIGFuZCAoYXMgcGVyIFJGQyA4MzAwKSB0aGUgTy1iaXQgaXMgc2V0IHRvIGlu ZGljYXRlIGFuIE9BTSBwYWNrZXQuDQpDTVA6IFRoZSBwcm9wb3NhbCBvZiBkZXByZWNhdGluZyB0 aGUgTy1iaXQgYnJlYWtzIHRob3NlIFNGQyBPQU0gcHJvdG9jb2xzIGFscmVhZHkgaW5jbHVkZWQg aW4gYW4gUkZDLg0KQ01QOiBUaGF0IHByb3Bvc2FsIG9mIGRlcHJlY2F0aW5nIHRoZSBPLWJpdCBh bHNvIGJyZWFrcyBTZWN0aW9uIDQuMSBvZiBJT0FNLg0KQ01QOiBUaGlzIGV4cGlyZWQgSS1EIHll dCBpbXBsZW1lbnRlZCBpbiBvcGVuIHNvdXJjZSB1c2VzIHRoZSBPLWJpdDogaHR0cHM6Ly93d3cu aWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1wZW5uby1zZmMtdHJhY2UtMDMudHh0PGh0dHBzOi8v bmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy Rnd3dy5pZXRmLm9yZyUyRmFyY2hpdmUlMkZpZCUyRmRyYWZ0LXBlbm5vLXNmYy10cmFjZS0wMy50 eHQmZGF0YT0wNCU3QzAxJTdDamFtZXMubi5ndWljaGFyZCU0MGZ1dHVyZXdlaS5jb20lN0M5ZGIy YWIwYTkzODI0NjEzOTdmOTA4ZDllZjZmN2ZmNSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1 OTFmZWRjJTdDMSU3QzElN0M2Mzc4MDQwODQ0ODExOTYyNjQlN0NVbmtub3duJTdDVFdGcGJHWnNi M2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxD SlhWQ0k2TW4wJTNEJTdDMzAwMCZzZGF0YT16JTJCa0ZnRHFIMjRweVk0N3dIMEpPSmdlbzJtYUxs Q2dmRlNwM01aNUt6WmMlM0QmcmVzZXJ2ZWQ9MD4NCg0KDQpHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fn c21AZ21haWwuY29tPG1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20+Pg0KDQpJIGFncmVlIHRo YXQgd2hhdCBtYWtlcyBzZW5zZSB0byBtZSBhcyBhIHBhdGggZm9yd2FyZCBpcyB0byBkZXByZWNh dGUgdGhlIE8gYml0IGFuZCBub3QgdXNlIGluIFNGQyBNdWx0aWxheWVyIE9BTSBhbmQgU0ZDIElP QU0sIGFzIGJvdGggU0ZDIE11bHRpbGF5ZXIgT0FNIGFuZCBTRkMgSU9BTSBhcmUgaWRlbnRpZmll ZCBieSB0aGUgcmVzcGVjdGl2ZSB2YWx1ZXMgZm9yIHRoZSBOU0ggTmV4dCBQcm90b2NvbCBmaWVs ZCAodG8gYmUgYXNzaWduZWQgYnkgSUFOQSksIGFzIHdlbGwgYXMgc28gZmFyIG5vIE9BTS1zcGVj aWZpYyBtZXRhIGRhdGEgVExWIGhhcyBiZWVuIHlldCBkZWZpbmVkLg0KDQpDTVA6IFdoYXQgaXMg dGhlIOKAnFNGQyBNdWx0aWxheWVyIE9BTeKAnT8NCkNNUDogVGhlIE8tYml0IChyZWFkaW5nIFJG QyA4MzAwKSBkb2VzIG5vdCBpbmRpY2F0ZSBpZiB0aGVyZSBpcyBPQU0gTWV0YWRhdGEuIEl0IGlu ZGljYXRlcyBhbiBPQU0gcGFja2V0Lg0KDQoNCiJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhh bHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCg0KQXMgZmFyIGFzIEkgY2Fu IHRlbGwsIGlmIHdlIGRlcHJlY2F0ZSB0aGUgTy1iaXQgYW5kIHJlbHkgb24gdGhlIG5leHQgcHJv dG9jb2wgZmllbGQsIHdlIGFyZSBzYXlpbmcgdGhhdCBpbiBwcmFjdGljZSAobm90IGJ5IHJ1bGUp IE5TSCBtZXRhZGF0YSBjYW4gbm90IGJlIHVzZWQgZm9yIE9BTS4gIFRoYXQncyBmaW5lIHdpdGgg bWUgYXMgbG9uZyBhcyB3ZSBhZ3JlZSBvbiB0aGF0Lg0KDQpDTVA6IEkgZG8gbm90IGZ1bGx5IGZv bGxvdyB0aGlzLiBDYW4geW91IGV4cGxhaW4gdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGUgTy1iaXQg d2l0aCBNZXRhZGF0YT8NCkNNUDogSGVyZeKAmXMgYW4gZXhhbXBsZTogUkZDIDg5MjQgc2hvd3Mg SUNNUCBhcyBBY3RpdmUgT0FNLiBUaGUgU0ZDIG5leHQgcHJvdG9jb2wgaXMgSVAsIHRoZSBJUCBu ZXh0IHByb3RvY29sIGlzIElDTVAsIHRoZSBPLWJpdCBuZWVkcyB0byBiZSBzZXQuDQoNCkNNUDog Q29uc2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudCwgaW5kZXBlbmRlbnQgc3VibWlzc2lvbiBh bmQgaW4gdGhlIFJGQyBQdWJsaWNhdGlvbiBxdWV1ZSBhbHJlYWR5Og0KQ01QOiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1teW1iLXNmYy1uc2gtYWxsb2NhdGlvbi10aW1l c3RhbXAvPGh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtbXltYi1z ZmMtbnNoLWFsbG9jYXRpb24tdGltZXN0YW1wJTJGJmRhdGE9MDQlN0MwMSU3Q2phbWVzLm4uZ3Vp Y2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDOWRiMmFiMGE5MzgyNDYxMzk3ZjkwOGQ5ZWY2ZjdmZjUl N0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3ODA0MDg0NDgx MTk2MjY0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlq b2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9QjAl MkZRUFFUYlFydVRLenFYZmluNlpmRVl5YXVBMktaaHEwbThZS1NMdExFJTNEJnJlc2VydmVkPTA+ DQpDTVA6IElzIGEgVGltZXN0YW1wIGluIE1ldGFkYXRhIGFuIE9BTSBlbGVtZW50Pw0KDQpDTVA6 IENvbnNpZGVyIHRoaXMgcHJvcG9zYWwgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbWlyc2t5LXNmYy1wbWFtbS88aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZk b2MlMkZkcmFmdC1taXJza3ktc2ZjLXBtYW1tJTJGJmRhdGE9MDQlN0MwMSU3Q2phbWVzLm4uZ3Vp Y2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDOWRiMmFiMGE5MzgyNDYxMzk3ZjkwOGQ5ZWY2ZjdmZjUl N0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3ODA0MDg0NDgx MTk2MjY0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlq b2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9Smlp a0dnWEczNSUyRlc1MThkaXN1SXhBdmFXYTVGdXF2a0tjRyUyRmF5ZzZSNDglM0QmcmVzZXJ2ZWQ9 MD4NCkNNUDogV2hlcmUgdGhlIGJhc2UgaGVhZGVyIGJvcnJvd3MgYSBiaXQgZm9yIGFuIE9BTSBm dW5jdGlvbi4NCg0KQ01QOiBOZWl0aGVyIG9mIHRob3NlIGhhdmUgYW55IGltcGFjdCBvbiB0aGUg Ty1iaXQuDQoNCg0KR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3Jl Z2ltaXJza3lAZ21haWwuY29tPj4NCg0KSSBhZ3JlZSB0aGF0LCBhcyB3ZSBmaW5kIFNGQyBOU0gg bm93LCBubyBPQU0gbWV0YWRhdGEgaGFzIGJlZW4gZGVmaW5lZC4gSXQgYXBwZWFycyB0byBtZSB0 aGF0IGRlcHJlY2F0aW5nIHRoZSBPIGJpdCBkb2VzIG5vdCBhZmZlY3QgYW55IG9mIHRoZSBhbHJl YWR5IGRlZmluZWQgbWVjaGFuaXNtcyBpbiB0aGUgU0ZDIE5TSC4NCg0KQ01QOiBJdCBhY3R1YWxs eSBkb2VzLCBzZWUgbXkgZXhhbXBsZSBhYm92ZS4NCg0KDQpJIHRoaW5rIHRoYXQgaWYgYSBuZXcs IGZvciBleGFtcGxlLCBNRCBUeXBlID0gMiBUTFYgdGhhdCBpcyB1c2VkIGZvciBhbnkgT0FNIGZ1 bmN0aW9uYWxpdHkgdG8gYmUgcHJvcG9zZWQgaW4gdGhlIGZ1dHVyZSwgZGVwcmVjYXRlZCB0aGUg TyBiaXQgd291bGQgbm90IHByZXZlbnQgdXNpbmcgc3VjaCBOU0ggVExWLg0KDQpDTVA6IEkgYWdy ZWUgd2l0aCB0aGlzIOKAlCBiZWNhdXNlIHRoZXJlIGlzIG5vIGNvcnJlbGF0aW9uIGJldHdlZW4g TUQgVHlwZSBmaWVsZCBhbmQgTy1iaXQgYXMgZGVmaW5lZC4NCg0KQmVzdCwNCg0KQ2FybG9zLg0K DQoNCg0KDQoyLzEzLzIyIOWNiOW+jDEyOjMy44CBR3lhbiBNaXNocmEgPGhheWFidXNhZ3NtQGdt YWlsLmNvbTxtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tPj7jga7jg6Hjg7zjg6s6DQoNCkhp IEpvZWwNCg0KSSBhbSBpbiBhZ3JlZW1lbnQgYXMgd2VsbCB3aXRoIHdoYXQgeW91IGhhdmUgc3Rh dGVkIHRoYXQgb25jZSB0aGUgTyBiaXQgaXMgZGVwcmVjYXRlZCB0aGF0IE5TSCBtZXRhZGF0YSBj YW5ub3QgYmUgdXNlZCBmb3IgT0FNIGFuZCB0aGF0IHdlIHdvdWxkIGhhdmUgdG8gbm93IGZyb20g dGhhdCBwb2ludCBmb3J3YXJkIHJlbHkgb24gdGhlIG5leHQgcHJvdG9jb2wgZmllbGQgYXMgd2Ug d2lsbCBiZSBkb2luZyBmb3IgU0ZDIE11bHRpbGF5ZXIgYW5kIFNGQyBJT0FNIGRyYWZ0cyBhcyB3 ZWxsIGFzIHdpbGwgaGF2ZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGFueSBhbHJlYWR5IGV4 aXN0aW5nIGRlZmluZWQgbWVjaGFuaXNtcyBpbiBTRkMgTlNILg0KDQpJIGRvbuKAmXQgc2VlIGFu eSBpc3N1ZXMgb3IgaW1wYWN0IHdpdGggbW92aW5nIGZvcndhcmQuDQoNCktpbmQgUmVnYXJkcw0K DQpHeWFuDQoNCk9uIFN1biwgRmViIDEzLCAyMDIyIGF0IDEyOjA0IFBNIEdyZWcgTWlyc2t5IDxn cmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+IHdyb3Rl Og0KSGkgSm9lbCwNCkkgYWdyZWUgdGhhdCwgYXMgd2UgZmluZCBTRkMgTlNIIG5vdywgbm8gT0FN IG1ldGFkYXRhIGhhcyBiZWVuIGRlZmluZWQuIEl0IGFwcGVhcnMgdG8gbWUgdGhhdCBkZXByZWNh dGluZyB0aGUgTyBiaXQgZG9lcyBub3QgYWZmZWN0IGFueSBvZiB0aGUgYWxyZWFkeSBkZWZpbmVk IG1lY2hhbmlzbXMgaW4gdGhlIFNGQyBOU0guIEkgdGhpbmsgdGhhdCBpZiBhIG5ldywgZm9yIGV4 YW1wbGUsIE1EIFR5cGUgPSAyIFRMViB0aGF0IGlzIHVzZWQgZm9yIGFueSBPQU0gZnVuY3Rpb25h bGl0eSB0byBiZSBwcm9wb3NlZCBpbiB0aGUgZnV0dXJlLCBkZXByZWNhdGVkIHRoZSBPIGJpdCB3 b3VsZCBub3QgcHJldmVudCB1c2luZyBzdWNoIE5TSCBUTFYuDQpXaGF0IGRvIHlvdSB0aGluaz8N Cg0KUmVnYXJkcywNCkdyZWcNCg0KT24gU3VuLCBGZWIgMTMsIDIwMjIgYXQgNjo1NSBBTSBKb2Vs IE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20+PiB3cm90ZToNClRoZXJlIGlzIGFuIGltcGxpY2F0aW9uIG9mIGRlcHJlY2F0aW5nIHRoZSBP LWJpdCB0aGF0IEkgd291bGQgbGlrZSB0bw0KaGVhciBmcm9tIG1vcmUgV0cgcGFydGljaXBhbnRz IGFib3V0Lg0KDQpBcyBmYXIgYXMgSSBjYW4gdGVsbCwgaWYgd2UgZGVwcmVjYXRlIHRoZSBPLWJp dCBhbmQgcmVseSBvbiB0aGUgbmV4dA0KcHJvdG9jb2wgZmllbGQsIHdlIGFyZSBzYXlpbmcgdGhh dCBpbiBwcmFjdGljZSAobm90IGJ5IHJ1bGUpIE5TSA0KbWV0YWRhdGEgY2FuIG5vdCBiZSB1c2Vk IGZvciBPQU0uICBUaGF0J3MgZmluZSB3aXRoIG1lIGFzIGxvbmcgYXMgd2UNCmFncmVlIG9uIHRo YXQuDQoNCllvdXJzLA0KSm9lbA0KDQpPbiAyLzEzLzIwMjIgMjo1MiBBTSwgR3lhbiBNaXNocmEg d3JvdGU6DQo+DQo+IEhpIEppbSwgSm9lbCAmIFNGQyBXRywNCj4NCj4gSSBhZ3JlZSB0aGF0IHRo ZSBSRkMgODMwMCBkZWZpbml0aW9uIG9mIE8gYml0IGlzIGluY29tcGxldGUgYW5kIG5vdA0KPiBj bGVhciBhcyB0byBpdHMgaW50ZW5kZWQgdXNlLg0KPg0KPiBUaGF0IGlzIGEgcHJvYmxlbSB0aGF0 IEkgYWdyZWUgbmVlZHMgdG8gYmUgcmVjdGlmaWVkLg0KPg0KPiBJIHVuZGVyc3RhbmQgdGhhdCB3 ZSBuZWVkIHRvIGdldCB0aGlzIHJlc29sdmVkIGJlZm9yZSB3ZSBjYW4gcHJvZ3Jlc3MNCj4gTXVs dGlsYXllciBTRkMgT0FNIGRyYWZ0LWlldGYtc2ZjLW11bHRpLWxheWVyLW9hbS0xOCBhbmQgU0ZD IElPQU0uDQo+DQo+IEkgYWdyZWUgdGhhdCB3aGF0IG1ha2VzIHNlbnNlIHRvIG1lIGFzIGEgcGF0 aCBmb3J3YXJkIGlzIHRvIGRlcHJlY2F0ZQ0KPiB0aGUgTyBiaXQgYW5kIG5vdCB1c2UgaW4gU0ZD IE11bHRpbGF5ZXIgT0FNIGFuZCBTRkMgSU9BTSwgYXMgYm90aCBTRkMNCj4gTXVsdGlsYXllciBP QU0gYW5kIFNGQyBJT0FNIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSByZXNwZWN0aXZlIHZhbHVlcyBm b3INCj4gdGhlIE5TSCBOZXh0IFByb3RvY29sIGZpZWxkICh0byBiZSBhc3NpZ25lZCBieSBJQU5B KSwgYXMgd2VsbCBhcyBzbyBmYXINCj4gbm8gT0FNLXNwZWNpZmljIG1ldGEgZGF0YSBUTFYgaGFz IGJlZW4geWV0IGRlZmluZWQuDQo+DQo+IFNvIHdlIGhhdmUgSSBiZWxpZXZlIHNvbGlkIHNvbHV0 aW9uIGFuZCBwYXRoIGZvcndhcmQgYW5kIEkgc3VwcG9ydA0KPiBkZXByZWNhdGluZyB0aGUgTyBi aXQuDQo+DQo+IEtpbmQgUmVnYXJkcw0KPg0KPiBHeWFuDQo+DQo+IE9uIFdlZCwgRmViIDIsIDIw MjIgYXQgNTo0MiBQTSBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpn cmVnaW1pcnNreUBnbWFpbC5jb20+DQo+IDxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1h aWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+Pj4gd3JvdGU6DQo+DQo+ICAgICBUaGFuayB5b3Us IEppbSBhbmQgSm9lbCwgZm9yIGd1aWRpbmcgdGhlIFNGQyBPQU0gd29yayBhbmQgcG9pbnRpbmcN Cj4gICAgIG91dCB0aGUgaXNzdWUgdGhhdCBtdXN0IGJlIGFkZHJlc3NlZC4NCj4NCj4gICAgIEkn dmUgcmV2aWV3ZWQgb3VyIFNGQyBPQU0gZG9jdW1lbnRzIGFuZCBkcmFmdC1pZXRmLXNmYy1uc2gt dGx2LiBBcyBJDQo+ICAgICB1bmRlcnN0YW5kIHRoZXNlIGRvY3VtZW50cywgdGhlIEFjdGl2ZSBT RkMgT0FNIGFuZCBJT0FNIGFyZQ0KPiAgICAgaWRlbnRpZmllZCBieSB0aGUgcmVzcGVjdGl2ZSB2 YWx1ZXMgZm9yIHRoZSBOU0ggTmV4dCBQcm90b2NvbCBmaWVsZA0KPiAgICAgKHRvIGJlIGFzc2ln bmVkIGJ5IElBTkEpLiBBdCB0aGUgc2FtZSB0aW1lLCBzbyBmYXIgbm8gT0FNLXNwZWNpZmljDQo+ ICAgICBtZXRhIGRhdGEgVExWIGhhcyBiZWVuIGRlZmluZWQuIFRodXMsIGl0IGFwcGVhcnMgdGhh dCBvbmUgd2F5DQo+ICAgICBmb3J3YXJkIGNvdWxkIGJlIHRvIG5vdCBpbnZvbHZlIHRoZSBPIGJp dCBpbiB0aGUgYWN0aXZlIFNGQyBPQU0gb3INCj4gICAgIElPQU0gYWx0b2dldGhlci4gSW4gb3Ro ZXIgd29yZHMsIHRvIGRlcHJlY2F0ZSB0aGUgTlNIIE8gYml0Lg0KPg0KPiAgICAgSSBncmVhdGx5 IGFwcHJlY2lhdGUgeW91ciBjb21tZW50cyBvbiB0aGUgcHJvcG9zYWwgdG8gZGVwcmVjYXRlIHRo ZQ0KPiAgICAgTlNIIE8gYml0Lg0KPg0KPiAgICAgUmVnYXJkcywNCj4gICAgIEdyZWcNCj4NCj4g ICAgIE9uIFdlZCwgRmViIDIsIDIwMjIgYXQgMTA6MzYgQU0gSmFtZXMgR3VpY2hhcmQNCj4gICAg IDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRA ZnV0dXJld2VpLmNvbT4NCj4gICAgIDxtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWku Y29tPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+Pj4gd3JvdGU6DQo+DQo+ ICAgICAgICAgSGkgV0c6X19fXw0KPg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgSGF2 aW5nIHJldmlld2VkIGFsbCBvZiB0aGUgT0FNIHJlbGF0ZWQgZG9jdW1lbnRzIGluIG91ciBXRywg dGhlDQo+ICAgICAgICAgY2hhaXJzIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBhIGZldyBjb21tZW50 cyB0byBob3BlZnVsbHkNCj4gICAgICAgICBnZW5lcmF0ZSBkaXNjdXNzaW9uIGFuZCBmb3J3YXJk IHByb2dyZXNzIG9mIHRoaXMgd29yazpfX19fDQo+DQo+ICAgICAgICAgX18gX18NCj4NCj4gICAg ICAgICAxKSBUaGUgY2hhaXJzIGhhdmUgcmV2aWV3ZWQgdGhlIE8gYml0IGRlZmluaXRpb24gaW4g UkZDIDgzMDAuDQo+ICAgICAgICAgVGhhdCBkZWZpbml0aW9uIGlzIGF0IGJlc3Qgb3BlbiB0byBp bnRlcnByZXRhdGlvbiBhbmQgdGhlcmVmb3JlDQo+ICAgICAgICAgaW5jb21wbGV0ZS4gIEZvciBl eGFtcGxlLCB0aGUgY2xlYXIgaW50ZW50aW9uIGlzIG9ubHkgdG8gbWFyaw0KPiAgICAgICAgIHBh Y2tldHMgd2hpY2ggYXJlIGludGVuZGVkIGZvciBTRkMgT0FNIGF0IHRoZSBTRkMgc2VydmljZQ0K PiAgICAgICAgIGxheWVyLiAgQnV0IHRoYXQgaXMgbm90IHdoYXQgdGhlIGN1cnJlbnQgdGV4dCBz YXlzLiAgVGhlcmUgaXMNCj4gICAgICAgICBhbHNvLCB1bmZvcnR1bmF0ZWx5LCBhbWJpZ3VpdHkg YXMgdG8gd2hhdCBjb25zdGl0dXRlcyBhbiBPQU0NCj4gICAgICAgICBwYWNrZXQuICBTbyBpdCBp cyByZWFzb25hYmxlIGZvciBkb2N1bWVudHMgdG8gdXBkYXRlIDgzMDAgdG8NCj4gICAgICAgICBj bGFyaWZ5IHRoZSBleGFjdCBhcHBsaWNhYmlsaXR5IGFuZCBhY3Rpb24gZm9yIHRoZSBPLWJpdC5f X19fDQo+DQo+ICAgICAgICAgX18gX18NCj4NCj4gICAgICAgICAyKSBIb3dldmVyLCByZWxhdGVk IHRvIHBvaW50IDEpLCB3ZSBjYW4ndCBoYXZlIG11bHRpcGxlDQo+ICAgICAgICAgZG9jdW1lbnRz IHVwZGF0aW5nIHRoZSBkZWZpbml0aW9uIGRpZmZlcmVudGx5LiAgQXMgc3VjaCwgdGhlDQo+ICAg ICAgICAgYXV0aG9ycyBvZiB0aGUgU0ZDIGlPQU0gZHJhZnQgYW5kIHRoZSBTRkMgbXVsdGktbGF5 ZXItb2FtIGRyYWZ0DQo+ICAgICAgICAgbmVlZCB0byBjb21lIHRvZ2V0aGVyIGFuZCBmaWd1cmUg b3V0IHdoYXQgdGhlIGNsYXJpZmljYXRpb24gaXMNCj4gICAgICAgICBmb3IgdGhlIGRlZmluaXRp b24gb2YgdGhhdCBiaXQuIFdlIGRvIG5vdCBiZWxpZXZlIGFzIGNoYWlycyB0aGF0DQo+ICAgICAg ICAgZWl0aGVyIG9mIHRoZXNlIGRvY3VtZW50cyBjYW4gbW92ZSBmb3J3YXJkIGZyb20gdGhlIFdH IHVudGlsDQo+ICAgICAgICAgc3VjaCBjbGFyaXR5IGhhcyBiZWVuIHJlYWNoZWQuIF9fX18NCj4N Cj4gICAgICAgICBfXyBfXw0KPg0KPiAgICAgICAgIDMpIFJlbGF0ZWQgdG8gdGhlIFNGQyBpT0FN LCB3ZSBuZWVkIGEgY2xlYXIgZGVmaW5pdGlvbiBvZiBpT0FNLg0KPiAgICAgICAgIFRoZXJlIHNl ZW0gdG8gYmUgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgZGVmaW5pdGlvbnMgaW4NCj4gICAgICAg ICBwdWJsaXNoZWQgUkZDcywgdGhlIHVzYWdlICh3aGljaCBpcyBub3QgYSBkZWZpbml0aW9uKSBp biB0aGUgU0ZDDQo+ICAgICAgICAgZHJhZnQsIGFuZCB0aGUgdmFyaW91cyBpcHBtIGRyYWZ0cy4g IEFueSBzdWNoIGRlZmluaXRpb24gd2lsbA0KPiAgICAgICAgIG5lZWQgdG8gYmUgdmV0dGVkIHdp dGggdGhlIGlwcG0gd29ya2luZyBncm91cC5fX19fDQo+DQo+ICAgICAgICAgX18gX18NCj4NCj4g ICAgICAgICBBZ2FpbiwgaXQgd291bGQgYmUgZ29vZCBpZiBtZW1iZXJzIG9mIHRoZSB3b3JraW5n IGdyb3VwIGJleW9uZA0KPiAgICAgICAgIHRoZSB0d28gYXV0aG9yIHRlYW1zIHNwb2tlIHVwIGFi b3V0IHRoZWlyIHJlYWRpbmdzIG9mIHRoZQ0KPiAgICAgICAgIGRvY3VtZW50cywgYW5kIHRoZWly IHVuZGVyc3RhbmRpbmdzIG9mIHdoYXQgd2UgbmVlZC5fX19fDQo+DQo+ICAgICAgICAgX18gX18N Cj4NCj4gICAgICAgICBZb3VycyxfX19fDQo+DQo+ICAgICAgICAgSmltIGFuZCBKb2VsX19fXw0K Pg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgX18gX18NCj4NCj4gICAgICAgICBfXyBf Xw0KPg0KPiAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ICAgICAgICAgc2ZjIG1haWxpbmcgbGlzdA0KPiAgICAgICAgIHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPiA8bWFpbHRvOnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPj4NCj4gICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYzxodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzZmMmZGF0 YT0wNCU3QzAxJTdDamFtZXMubi5ndWljaGFyZCU0MGZ1dHVyZXdlaS5jb20lN0M5ZGIyYWIwYTkz ODI0NjEzOTdmOTA4ZDllZjZmN2ZmNSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRj JTdDMSU3QzElN0M2Mzc4MDQwODQ0ODExOTYyNjQlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlK V0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2 TW4wJTNEJTdDMzAwMCZzZGF0YT1SMTIwclBNYVliYlJMT3Y1akdBJTJCaUFKb3RMcTRCTzhmYWhn MzQ1Mm4yUFUlM0QmcmVzZXJ2ZWQ9MD4NCj4gICAgICAgICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmM8aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGc2ZjJmRhdGE9MDQlN0MwMSU3Q2phbWVzLm4uZ3VpY2hhcmQlNDBmdXR1cmV3ZWku Y29tJTdDOWRiMmFiMGE5MzgyNDYxMzk3ZjkwOGQ5ZWY2ZjdmZjUlN0MwZmVlOGZmMmEzYjI0MDE4 OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3ODA0MDg0NDgxMzUyNTE0JTdDVW5rbm93biU3 Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2 SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9JTJGa290RXdvZGdPY3d3cFBnck5J SXlaJTJCWTV0QzNiSWllZ0tBanp2byUyQnBLSSUzRCZyZXNlcnZlZD0wPj4NCj4NCj4gICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICBzZmMg bWFpbGluZyBsaXN0DQo+ICAgICBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gPG1h aWx0bzpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+ICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxodHRwczovL25hbTExLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzZmMmZGF0YT0wNCU3QzAxJTdDamFtZXMubi5ndWljaGFyZCU0 MGZ1dHVyZXdlaS5jb20lN0M5ZGIyYWIwYTkzODI0NjEzOTdmOTA4ZDllZjZmN2ZmNSU3QzBmZWU4 ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3QzElN0M2Mzc4MDQwODQ0ODEzNTI1MTQl N0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVN eklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZzZGF0YT0lMkZrb3RFd29k Z09jd3dwUGdyTklJeVolMkJZNXRDM2JJaWVnS0FqenZvJTJCcEtJJTNEJnJlc2VydmVkPTA+DQo+ ICAgICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8aHR0cHM6Ly9u YW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG d3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2ZjJmRhdGE9MDQlN0MwMSU3Q2ph bWVzLm4uZ3VpY2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDOWRiMmFiMGE5MzgyNDYxMzk3ZjkwOGQ5 ZWY2ZjdmZjUlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3 ODA0MDg0NDgxMzUyNTE0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdN REFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAm c2RhdGE9JTJGa290RXdvZGdPY3d3cFBnck5JSXlaJTJCWTV0QzNiSWllZ0tBanp2byUyQnBLSSUz RCZyZXNlcnZlZD0wPj4NCj4NCj4gLS0NCj4NCj4gPGh0dHA6Ly93d3cudmVyaXpvbi5jb20vPGh0 dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNB JTJGJTJGd3d3LnZlcml6b24uY29tJTJGJmRhdGE9MDQlN0MwMSU3Q2phbWVzLm4uZ3VpY2hhcmQl NDBmdXR1cmV3ZWkuY29tJTdDOWRiMmFiMGE5MzgyNDYxMzk3ZjkwOGQ5ZWY2ZjdmZjUlN0MwZmVl OGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3ODA0MDg0NDgxMzUyNTE0 JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1 TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9T05qZmczR1pK NWF0cjF4OEJSNzkyWHpPJTJGOXBvempOMkdHSkJBJTJGNWpLOHclM0QmcmVzZXJ2ZWQ9MD4+DQo+ DQo+ICpHeWFuIE1pc2hyYSoNCj4NCj4gL05ldHdvcmsgU29sdXRpb25zIEEvL3JjaGl0ZWN0IC8N Cj4NCj4gL0VtYWlsIGd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208bWFpbHRvOmd5YW4ucy5taXNo cmFAdmVyaXpvbi5jb20+IDxtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTxtYWlsdG86 Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbT4+Ly8NCj4gLw0KPg0KPiAvTSAzMDEgNTAyLTEzNDcN Cj4NCj4gLw0KPg0KPg0KLS0NCltodHRwOi8vc3M3LnZ6dy5jb20vaXMvaW1hZ2UvVmVyaXpvbldp cmVsZXNzL3Z6LWxvZ28tZW1haWxdPGh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGd3d3LnZlcml6b24uY29tJTJGJmRhdGE9MDQl N0MwMSU3Q2phbWVzLm4uZ3VpY2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDOWRiMmFiMGE5MzgyNDYx Mzk3ZjkwOGQ5ZWY2ZjdmZjUlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzEl N0MxJTdDNjM3ODA0MDg0NDgxMzUyNTE0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9p TUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUz RCU3QzMwMDAmc2RhdGE9T05qZmczR1pKNWF0cjF4OEJSNzkyWHpPJTJGOXBvempOMkdHSkJBJTJG NWpLOHclM0QmcmVzZXJ2ZWQ9MD4NCkd5YW4gTWlzaHJhDQpOZXR3b3JrIFNvbHV0aW9ucyBBcmNo aXRlY3QNCkVtYWlsIGd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208bWFpbHRvOmd5YW4ucy5taXNo cmFAdmVyaXpvbi5jb20+DQpNIDMwMSA1MDItMTM0Nw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KDQoNCg== --_000_D501B10D8AA64D679A57F799BE9CD517ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5AA1132A2ED4B9488BA2DC3B97A7287A@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYW5rcyDigJQgSeKAmWQgZXhwZWN0IFNGQyBP QU0gbGF5ZXIgcGFja2V0cyBvbmx5LCBhbmQgd291bGQgYWxzbyBleHBlY3QgYSBtb2RlbCB0aGF0 IHdvcmtzIGVxdWFsbHkgd2l0aCBtdWx0aWxheWVyLW9hbSBhcHByb2FjaGVzIG9yIHdpdGggZXhp c3RpbmcgT0FNcy4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPlRoYW5rcyE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkNhcmxvcy48YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4yLzE0LzIy IOWNiOWJjTk6MjjjgIFKYW1lcyBHdWljaGFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbWVzLm4u Z3VpY2hhcmRAZnV0dXJld2VpLmNvbSIgY2xhc3M9IiI+amFtZXMubi5ndWljaGFyZEBmdXR1cmV3 ZWkuY29tPC9hPiZndDvjga7jg6Hjg7zjg6s6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVy Y2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogU2ltU3VuOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5IaSBDYXJsb3MsPG86cCBjbGFz cz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPlNvbWUgcmVzcG9uc2VzIGluLWxpbmUg4oCmPG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC13aWR0 aDogMXB0OyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMjI1LCAyMjUsIDIyNSk7IHBhZGRpbmc6IDNw dCAwaW4gMGluOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+c2ZjDQogJmx0OzxhIGhyZWY9Im1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29y YXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs8 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9 IiI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj5DYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSk8YnIgY2xhc3M9IiI+DQo8YiBj bGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+U3VuZGF5LCBGZWJydWFyeSAxMywgMjAyMiAxMTowNyBQTTxiciBjbGFzcz0iIj4N CjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+R3lhbiBNaXNocmEgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXlhYnVzYWdzbUBn bWFpbC5jb20iIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 IiBjbGFzcz0iIj5oYXlhYnVzYWdzbUBnbWFpbC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+R3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFp bC5jb20iIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBj bGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0Ozs8c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNz PSIiPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0Ojwv Yj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtz ZmNdIFByb2dyZXNzaW9uIG9mIE9BTSB3b3JrIGluIHRoZSBTRkMgV0c8bzpwIGNsYXNzPSIiPjwv bzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj5SZXBseWluZyB0byB0 aGlzIHNwZWNpZmljIGVtYWlsIGluIHRoZSB0aHJlYWQsIG9ubHkgYmVjYXVzZSBpdCBpcyB0aGUg bGF0ZXN0IG9uZSBhdCB0aGlzIHBvaW50IGluIHRpbWUsIGJ1dCBidW5kbGluZyBjb21tZW50cyBm cm9tIHZhcmlvdXMgcGxhY2VzIG9uIHRoZSB0aHJlYWQuIFBsZWFzZSBmaW5kIHNvbWUgZm9sbG93 LXVwDQogY29tbWVudHMgYW5kIHF1ZXN0aW9ucyBtYXJrZWQg4oCcQ01Q4oCdLCBpbmRpY2F0aW5n IHRoZSDigJxGcm9t4oCdLCBhbmQgb3JnYW5pemVkIGNocm9ub2xvZ2ljYWxseTo8c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0i Ij48YiBjbGFzcz0iIj5KYW1lcyBOIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMu bi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29t PC9hPiZndDs6PC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1 cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47 IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjEpIFRoZSBjaGFpcnMgaGF2ZSByZXZpZXdlZCB0 aGUgTyBiaXQgZGVmaW5pdGlvbiBpbiBSRkMgODMwMC4mbmJzcDsgVGhhdCBkZWZpbml0aW9uIGlz IGF0IGJlc3Qgb3BlbiB0byBpbnRlcnByZXRhdGlvbg0KIGFuZCB0aGVyZWZvcmUgaW5jb21wbGV0 ZS4mbmJzcDsgRm9yIGV4YW1wbGUsIHRoZSBjbGVhciBpbnRlbnRpb24gaXMgb25seSB0byBtYXJr IHBhY2tldHMgd2hpY2ggYXJlIGludGVuZGVkIGZvciBTRkMgT0FNIGF0IHRoZSBTRkMgc2Vydmlj ZSBsYXllci4mbmJzcDsgQnV0IHRoYXQgaXMgbm90IHdoYXQgdGhlIGN1cnJlbnQgdGV4dCBzYXlz LiZuYnNwOyBUaGVyZSBpcyBhbHNvLCB1bmZvcnR1bmF0ZWx5LCBhbWJpZ3VpdHkgYXMgdG8gd2hh dCBjb25zdGl0dXRlcyBhbiBPQU0NCiBwYWNrZXQuJm5ic3A7IFNvIGl0IGlzIHJlYXNvbmFibGUg Zm9yIGRvY3VtZW50cyB0byB1cGRhdGUgODMwMCB0byBjbGFyaWZ5IHRoZSBleGFjdCBhcHBsaWNh YmlsaXR5IGFuZCBhY3Rpb24gZm9yIHRoZSBPLWJpdC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBj bGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPkNNUDogSXQgaXMgdW5jbGVhciB0byBtZSB3aGF0IGV4 YWN0IGlzc3VlcyB0aGUgY2hhaXJzIGFyZSBjYWxsaW5nIG91dC4gVGhlcmUgYXJlIHR3byBpc3N1 ZXMgbWVudGlvbmVkOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogU2ltU3VuOyIgY2xhc3M9IiI+Q01QOiAxLiAmcXVvdDtCdXQgdGhhdCBpcyBub3Qgd2hh dCB0aGUgY3VycmVudCB0ZXh0IHNheXMu4oCdIOKAlCZndDsgd2hhdCBkb2VzIHRoZSB0ZXh0IHNh eSBwcmVjaXNlbHk/ICZuYnNwO0NhbiB5b3UgcG9pbnQgdG8gdGhlIHNwZWNpZmljIFJGQyA4MzAw IHRleHQgdGhhdCBpcyBiZWxpZXZlZCB0byBiZSBpbmNvbXBsZXRlLCBhbmQgYSBkZXRhaWxlZA0K IHVzZSBjYXNlIHRoYXQgc2hvd2Nhc2VzIHRoZSBwb3RlbnRpYWwgaXNzdWU/IEFuIGV4dHJhcG9s YXRlZCBjb3VudGVyLWV4YW1wbGUganVzdCB0byBtYWtlIGEgcG9pbnQ6IHRoZSB0ZXh0IGRvZXMg bm90ICZuYnNwO3NheSB3aGF0IGRheXMgb2YgdGhlIHdlZWsgT0FNIHBhY2tldHMgY2FuIGJlIG1h cmtlZCwgeWV0IHRoZXJl4oCZcyBhbiBleHBlY3RhdGlvbiB0aGF0IHRoZXkgd2lsbCB3b3JrIE1v bmRheXMgYW5kIFNhdHVyZGF5cyBhbGwgdGhlIHNhbWUg4oCUIGV2ZW4NCiBob2xpZGF5cy48bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8cHJlIHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENvbnNv bGFzOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5KaW0mZ3Q7IEN1cnJlbnRseSBSRkM4MzAw IHNheXMg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7IiBjbGFzcz0iIj5UaGUgTyBiaXQgTVVTVCBiZSBzZXQgZm9yIE9BTSBwYWNrZXRz IGFuZCBNVVNUIE5PVCBiZSBzZXQgZm9yIG5vbi1PQU0gcGFja2V0c+KAnS4gPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+VGhlIGZpcnN0IGlzc3VlIGlzIGRvZXMgdGhpcyBtZWFuIHRoZSBPIGJpdCBz aG91bGQgYmUgc2V0IGZvciBBTEwgT0FNIHBhY2tldHMgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRo ZXkgYmVsb25nIHRvIHRoZSBOU0ggc2VydmljZSBwbGFuZT8gT3Igc2hvdWxkIGl0IG9ubHkgYmUg c2V0IGZvciBTRkMgT0FNIHBhY2tldHM/IEFuZCB3aGF0IGV4YWN0bHkgaXMgYW4gU0ZDIE9BTSBw YWNrZXQgYXMgdGhlIGVhcmxpZXIgcmVmZXJlbmNlIHRvIFJGQzYyOTEgaXMganVzdCBhIGdlbmVy YXRlIHNldCBvZiBndWlkZWxpbmVzIGZvciB0aGUgdXNlIG9mIHRoZSB0ZXJtIE9BTS4gVGhlIHNl Y29uZCBpc3N1ZSBpcyB0aGF0IGlmIHRoYXQgTyBiaXQgaXMgc2V0IHRoZW4gR3JlZ+KAmXMgZG9j dW1lbnQgaXMgaW4gY29uZmxpY3Qgd2l0aCBJT0FNIGFzIGJvdGggdXNlIHRoZSBuZXh0IHByb3Rv Y29sIGZpZWxkIGFuZCBldmVuIGlmIHRoZSBPIGJpdCBpcyBzZXQgaXQgaXMgbWVhbmluZ2xlc3Mg YXMgdGhlIHByb3RvY29sIGFjdGlvbiBpcyBiYXNlZCBzb2xlbHkgb24gdGhlIHNldHRpbmcgb2Yg dGhlIG5leHQgcHJvdG9jb2wgZmllbGQuIFNvIGluIHRoaXMgY2FzZSBjYW4gdGhlaXIgc29sdXRp b25zIHNpbXBseSBpZ25vcmUgd2hhdCBSRkMgODMwMCBzYXlzIGUuZy4gTVVTVCBzZXQgdGhlIE8g Yml0PyBPciBpZiB0aGV5IHNldCB0aGUgTyBiaXQgdG8gYmUgY29uZm9ybWFudCB0byB3aGF0IFJG QyA4MzAwIHNheXMgdGhlbiBkbyB3ZSBuZWVkIGNsZWFyZXIgcnVsZXMgc3RhdGluZyB3aGF0IHRv IGRvIGlmIHRoZSBuZXh0IHByb3RvY29sIGZpZWxkIGlzIE5PVCBhbiBPQU0gbmV4dCBwcm90b2Nv bCBzdWNoIGFzIHRoZSBjb250ZXh0IGhlYWRlcnMgc2hvdWxkIHRoZW4gYmUgZXhhbWluZWQ/IDxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj5DTVA6IDIu IFdoYXQgc3BlY2lmaWNhbGx5IGlzIHRoZSBhbWJpZ3VpdHkgd2l0aCB3aGF0IGFuIE9BTSBwYWNr ZXQgaXM/IFBsZWFzZSBncmVwIHRoZSBSRkMgc2VyaWVzIGZvciDigJxvYW0gcGFja2V04oCdLCBp dCBpcyBub3QgYSBuZXcgdGVybS4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPkNNUDogTmV0LW5ldCwgTy1iaXQ9 MSwgT0FNIHBhY2tldC4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5KaW0mZ3Q7IGFtYmlndWl0 eSBpcyB3aGV0aGVyIGl0IGlzIG9ubHkgU0ZDIE9BTSBwYWNrZXRzIHRoYXQgYXJlIGJlaW5nIGRp c2N1c3NlZCBvciBBTEwgT0FNIHBhY2tldHMgbm90aGluZyB0aGF0DQogc29tZSBtaWdodCBiZSBh dCB0aGUgc2VydmljZSBsYXllciBhbmQgc29tZSBtaWdodCBub3QuPG86cCBjbGFzcz0iIj48L286 cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPkppbTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog U2ltU3VuOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4yKSBIb3dldmVyLCByZWxhdGVkIHRv IHBvaW50IDEpLCB3ZSBjYW4ndCBoYXZlIG11bHRpcGxlIGRvY3VtZW50cyB1cGRhdGluZyB0aGUg ZGVmaW5pdGlvbiBkaWZmZXJlbnRseS4mbmJzcDsgQXMgc3VjaCwNCiB0aGUgYXV0aG9ycyBvZiB0 aGUgU0ZDIGlPQU0gZHJhZnQgYW5kIHRoZSBTRkMgbXVsdGktbGF5ZXItb2FtIGRyYWZ0IG5lZWQg dG8gY29tZSB0b2dldGhlciBhbmQgZmlndXJlIG91dCB3aGF0IHRoZSBjbGFyaWZpY2F0aW9uIGlz IGZvciB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IGJpdC4gV2UgZG8gbm90IGJlbGlldmUgYXMgY2hh aXJzIHRoYXQgZWl0aGVyIG9mIHRoZXNlIGRvY3VtZW50cyBjYW4gbW92ZSBmb3J3YXJkIGZyb20g dGhlIFdHIHVudGlsDQogc3VjaCBjbGFyaXR5IGhhcyBiZWVuIHJlYWNoZWQuPG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPkNNUDogSWYgdGhl cmUgaXMgc3RpbGwgYmVsaWV2ZWQgdG8gYmUgYW4gYW1iaWd1aXR5IG9yIGEgY2xlYXIgb3Bwb3J0 dW5pdHkgZm9yIGltcHJvdmluZyB0aGUgZGVmaW5pdGlvbiwgSSBhZ3JlZSB3aXRoIGNvbnNvbGlk YXRpbmcgdGhhdCB1cGRhdGUuIEkgaGFkIHN1Z2dlc3RlZCBiZWZvcmUgdGhhdCBpZiBzdWNoIG5l dw0KIHRleHQgb3IgcmVhbCBjbGFyaWZpY2F0aW9uIGlzIGFncmVlZCwgYSBzZXBhcmF0ZSBkb2N1 bWVudCB0aGF0IG9ubHkgbWFrZXMgdGhhdCBPLWJpdCBjbGFyaWZpY2F0aW9uIGlzIHRoZSBtb3N0 IGNsZWFyIGFuZCBjbGVhbiB3YXkgdG8gZ28uIFRoYXQgZG9jIHNob3VsZCBiZSBhIG9uZS1wYWdl ciBvciBsZXNzLiBJ4oCZZCBiZSBoYXBweSB0byBjb250cmlidXRlIHRvIHRoYXQgbWluaW1hbCBk b2MsIGlmIGl0IGlzIHNob3duIHRvIGJlIG5lZWRlZC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+ Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9 IiI+Q01QOiBGb3IgY29tcGxldGVuZXNzIGFsc28sIHRoZSAmcXVvdDtTRkMgbXVsdGktbGF5ZXIt b2Ft4oCdIGRvY3VtZW50IGhhcyBtYW55IG91dHN0YW5kaW5nIGlzc3VlcyBiZXNpZGVzIHRoZSBP LWJpdC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNp bVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+R3JlZyBNaXJza3kg Jmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHN0eWxlPSJjb2xvcjog Ymx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5ncmVnaW1pcnNreUBn bWFpbC5jb208L2E+Jmd0OzwvYj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0i Ij5JJ3ZlIHJldmlld2VkIG91ciBTRkMgT0FNIGRvY3VtZW50cyBhbmQgZHJhZnQtaWV0Zi1zZmMt bnNoLXRsdi4gQXMgSSB1bmRlcnN0YW5kIHRoZXNlIGRvY3VtZW50cywgdGhlIEFjdGl2ZSBTRkMg T0FNIGFuZCBJT0FNIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSByZXNwZWN0aXZlIHZhbHVlcyBmb3Ig dGhlIE5TSCBOZXh0IFByb3RvY29sDQogZmllbGQgKHRvIGJlIGFzc2lnbmVkIGJ5IElBTkEpLjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNp bVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+Q01QOiBUaGVyZSBpcyBhIG1ham9yIGlz c3VlIHdpdGggdGhlIHNlbnRlbmNlIGFib3ZlLiBBY3RpdmUgU0ZDIE9BTSAoYXMgYSBjYXRlZ29y eSksIGFzIHBlciBSRkMgODMwMCwgbmVlZHMgdG8gYmUgaWRlbnRpZmllZCBieSBzZXR0aW5nIHRo ZSBPLWJpdC4gTm8gd2F5IGFyb3VuZCB0aGF0IGJhc2VkIG9uIFJGQyA4MzAwLg0KIEhvd2V2ZXIs IHRoZSB0ZXh0ICZxdW90O3RoZSBBY3RpdmUgU0ZDIE9BTeKAnSBjcmVhdGVzIGNvbmZ1c2lvbiBz aW5jZSBpdCByZWZlciB0byBhIHNwZWNpZmljIE9BTSBwcm90b2NvbCB3aGljaCBoYXMgdGhlIHNh bWUgbmFtZSBhcyBhIHRoZSBjYXRlZ29yeSBhcyB3ZWxsLiBUaGF0IG5hbWUgY29sbGlzaW9uIGlz IHF1aXRlIHVuZm9ydHVuYXRlIGluIG15IG9waW5pb24uPG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIi PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj5B dCB0aGUgc2FtZSB0aW1lLCBzbyBmYXIgbm8gT0FNLXNwZWNpZmljIG1ldGEgZGF0YSBUTFYgaGFz IGJlZW4gZGVmaW5lZC4gVGh1cywgaXQgYXBwZWFycyB0aGF0IG9uZSB3YXkgZm9yd2FyZCBjb3Vs ZCBiZSB0byBub3QgaW52b2x2ZSB0aGUgTyBiaXQgaW4gdGhlIGFjdGl2ZSBTRkMgT0FNIG9yIElP QU0gYWx0b2dldGhlci4NCiBJbiBvdGhlciB3b3JkcywgdG8gZGVwcmVjYXRlIHRoZSBOU0ggTyBi aXQuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6IFNpbVN1bjsiIGNsYXNzPSIiPkNNUDogUkZDIDg5MjQgYWxyZWFkeSBpbmNsdWRlcyBJQ01Q IGFuZCBCRkQgYXMgZXhhbXBsZSBTRkMgQWN0aW9uIE9BTSBwcm90b2NvbHMuIFRob3NlIGNhbiBi ZSBlbmNhcHN1bGF0ZWQgaW4gSVAsIGluIHdoaWNoIHRoZSBOZXh0LVByb3RvY29sIGluZGljYXRl cyBJUCDigJQgYW5kIChhcyBwZXIgUkZDIDgzMDApIHRoZSBPLWJpdA0KIGlzIHNldCB0byBpbmRp Y2F0ZSBhbiBPQU0gcGFja2V0LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+Q01QOiBUaGUgcHJvcG9zYWwgb2YgZGVwcmVj YXRpbmcgdGhlIE8tYml0IGJyZWFrcyB0aG9zZSBTRkMgT0FNIHByb3RvY29scyBhbHJlYWR5IGlu Y2x1ZGVkIGluIGFuIFJGQy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPkNNUDogVGhhdCBwcm9wb3NhbCBvZiBkZXByZWNh dGluZyB0aGUgTy1iaXQgYWxzbyBicmVha3MgU2VjdGlvbiA0LjEgb2YgSU9BTS48bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIi PkNNUDogVGhpcyBleHBpcmVkIEktRCB5ZXQgaW1wbGVtZW50ZWQgaW4gb3BlbiBzb3VyY2UgdXNl cyB0aGUgTy1iaXQ6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGYXJjaGl2 ZSUyRmlkJTJGZHJhZnQtcGVubm8tc2ZjLXRyYWNlLTAzLnR4dCZhbXA7ZGF0YT0wNCU3QzAxJTdD amFtZXMubi5ndWljaGFyZCU0MGZ1dHVyZXdlaS5jb20lN0M5ZGIyYWIwYTkzODI0NjEzOTdmOTA4 ZDllZjZmN2ZmNSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3QzElN0M2 Mzc4MDQwODQ0ODExOTYyNjQlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpB d01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAw MCZhbXA7c2RhdGE9eiUyQmtGZ0RxSDI0cHlZNDd3SDBKT0pnZW8ybWFMbENnZkZTcDNNWjVLelpj JTNEJmFtcDtyZXNlcnZlZD0wIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFm dC1wZW5uby1zZmMtdHJhY2UtMDMudHh0PC9hPiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFz cz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkd5YW4gTWlzaHJhICZsdDs8YSBocmVm PSJtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aGF5YWJ1c2Fnc21AZ21haWwuY29tPC9h PiZndDs8L2I+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiBTaW1TdW47IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsg bWFyZ2luLWJvdHRvbTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNs YXNzPSIiPkkgYWdyZWUgdGhhdCB3aGF0IG1ha2VzIHNlbnNlIHRvIG1lIGFzIGEgcGF0aCBmb3J3 YXJkIGlzIHRvIGRlcHJlY2F0ZSB0aGUgTyBiaXQgYW5kIG5vdCB1c2UgaW4gU0ZDIE11bHRpbGF5 ZXIgT0FNIGFuZCBTRkMgSU9BTSwgYXMgYm90aCBTRkMgTXVsdGlsYXllciZuYnNwO09BTSBhbmQg U0ZDJm5ic3A7SU9BTSBhcmUgaWRlbnRpZmllZCBieQ0KIHRoZSByZXNwZWN0aXZlIHZhbHVlcyBm b3IgdGhlIE5TSCBOZXh0IFByb3RvY29sIGZpZWxkICh0byBiZSBhc3NpZ25lZCBieSBJQU5BKSwg YXMgd2VsbCBhcyBzbyBmYXIgbm8gT0FNLXNwZWNpZmljIG1ldGEgZGF0YSBUTFYgaGFzIGJlZW4g eWV0IGRlZmluZWQuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xh c3M9IiI+Q01QOiBXaGF0IGlzIHRoZSDigJxTRkMgTXVsdGlsYXllciBPQU3igJ0/PG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0i Ij5DTVA6IFRoZSBPLWJpdCAocmVhZGluZyBSRkMgODMwMCkgZG9lcyBub3QgaW5kaWNhdGUgaWYg dGhlcmUgaXMgT0FNIE1ldGFkYXRhLiBJdCBpbmRpY2F0ZXMgYW4gT0FNIHBhY2tldC48bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNz PSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj48YiBjbGFzcz0iIj4mcXVvdDtK b2VsIE0uIEhhbHBlcm4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 IFNpbVN1bjsiIGNsYXNzPSIiPkFzIGZhciBhcyBJIGNhbiB0ZWxsLCBpZiB3ZSBkZXByZWNhdGUg dGhlIE8tYml0IGFuZCByZWx5IG9uIHRoZSBuZXh0IHByb3RvY29sIGZpZWxkLCB3ZSBhcmUgc2F5 aW5nIHRoYXQgaW4gcHJhY3RpY2UgKG5vdCBieSBydWxlKSBOU0ggbWV0YWRhdGEgY2FuIG5vdCBi ZSB1c2VkIGZvciBPQU0uICZuYnNwO1RoYXQncyBmaW5lIHdpdGgNCiBtZSBhcyBsb25nIGFzIHdl IGFncmVlIG9uIHRoYXQuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj5DTVA6IEkg ZG8gbm90IGZ1bGx5IGZvbGxvdyB0aGlzLiBDYW4geW91IGV4cGxhaW4gdGhlIHJlbGF0aW9uc2hp cCBvZiB0aGUgTy1iaXQgd2l0aCBNZXRhZGF0YT88bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPkNNUDogSGVyZeKAmXMgYW4g ZXhhbXBsZTogUkZDIDg5MjQgc2hvd3MgSUNNUCBhcyBBY3RpdmUgT0FNLiBUaGUgU0ZDIG5leHQg cHJvdG9jb2wgaXMgSVAsIHRoZSBJUCBuZXh0IHByb3RvY29sIGlzIElDTVAsIHRoZSBPLWJpdCBu ZWVkcyB0byBiZSBzZXQuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPkNNUDogQ29u c2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudCwgaW5kZXBlbmRlbnQgc3VibWlzc2lvbiBhbmQg aW4gdGhlIFJGQyBQdWJsaWNhdGlvbiBxdWV1ZSBhbHJlYWR5OjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+Q01QOiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtbXlt Yi1zZmMtbnNoLWFsbG9jYXRpb24tdGltZXN0YW1wJTJGJmFtcDtkYXRhPTA0JTdDMDElN0NqYW1l cy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5MDhkOWVm NmY3ZmY1JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgw NDA4NDQ4MTE5NjI2NCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURB aUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFt cDtzZGF0YT1CMCUyRlFQUVRiUXJ1VEt6cVhmaW42WmZFWXlhdUEyS1pocTBtOFlLU0x0TEUlM0Qm YW1wO3Jlc2VydmVkPTAiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7IiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1t eW1iLXNmYy1uc2gtYWxsb2NhdGlvbi10aW1lc3RhbXAvPC9hPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+Q01QOiBJcyBh IFRpbWVzdGFtcCBpbiBNZXRhZGF0YSBhbiBPQU0gZWxlbWVudD8mbmJzcDs8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxv OnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2lt U3VuOyIgY2xhc3M9IiI+Q01QOiBDb25zaWRlciB0aGlzIHByb3Bvc2FsJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1taXJza3ktc2ZjLXBt YW1tJTJGJmFtcDtkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNv bSU3QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5MDhkOWVmNmY3ZmY1JTdDMGZlZThmZjJhM2IyNDAxODlj NzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNDA4NDQ4MTE5NjI2NCU3Q1Vua25vd24lN0NU V0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklr MWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1KaWlrR2dYRzM1JTJGVzUxOGRp c3VJeEF2YVdhNUZ1cXZrS2NHJTJGYXlnNlI0OCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgc3R5bGU9ImNv bG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1pcnNreS1zZmMtcG1hbW0vPC9hPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xh c3M9IiI+Q01QOiBXaGVyZSB0aGUgYmFzZSBoZWFkZXIgYm9ycm93cyBhIGJpdCBmb3IgYW4gT0FN IGZ1bmN0aW9uLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj5DTVA6IE5laXRoZXIgb2YgdGhv c2UgaGF2ZSBhbnkgaW1wYWN0IG9uIHRoZSBPLWJpdC4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIg Y2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5HcmVnIE1pcnNreSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgc3R5bGU9ImNvbG9yOiBibHVlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNv bTwvYT4mZ3Q7PC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1 cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPkkgYWdy ZWUgdGhhdCwgYXMgd2UgZmluZCBTRkMgTlNIIG5vdywgbm8gT0FNIG1ldGFkYXRhIGhhcyBiZWVu IGRlZmluZWQuIEl0IGFwcGVhcnMgdG8gbWUgdGhhdCBkZXByZWNhdGluZyB0aGUgTyBiaXQgZG9l cyBub3QgYWZmZWN0IGFueSBvZiB0aGUmbmJzcDthbHJlYWR5IGRlZmluZWQgbWVjaGFuaXNtcyBp biB0aGUmbmJzcDtTRkMgTlNILjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+Q01Q OiBJdCBhY3R1YWxseSBkb2VzLCBzZWUgbXkgZXhhbXBsZSBhYm92ZS48bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNs YXNzPSIiPkkgdGhpbmsgdGhhdCBpZiBhIG5ldywgZm9yIGV4YW1wbGUsIE1EIFR5cGUgPSAyIFRM ViB0aGF0Jm5ic3A7aXMgdXNlZCBmb3IgYW55IE9BTSBmdW5jdGlvbmFsaXR5IHRvIGJlIHByb3Bv c2VkIGluIHRoZSBmdXR1cmUsIGRlcHJlY2F0ZWQgdGhlIE8gYml0IHdvdWxkJm5ic3A7bm90IHBy ZXZlbnQgdXNpbmcgc3VjaCBOU0ggVExWLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47 IiBjbGFzcz0iIj5DTVA6IEkgYWdyZWUgd2l0aCB0aGlzIOKAlCBiZWNhdXNlIHRoZXJlIGlzIG5v IGNvcnJlbGF0aW9uIGJldHdlZW4gTUQgVHlwZSBmaWVsZCBhbmQgTy1iaXQgYXMgZGVmaW5lZC48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsi IGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+QmVzdCw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+ Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9 IiI+Q2FybG9zLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNw OzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+Mi8xMy8yMjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJaSC1D TiIgY2xhc3M9IiI+5Y2I5b6MPC9zcGFuPjEyOjMyPHNwYW4gbGFuZz0iWkgtQ04iIGNsYXNzPSIi PuOAgTwvc3Bhbj5HeWFuIE1pc2hyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhheWFidXNhZ3NtQGdt YWlsLmNvbSIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsi IGNsYXNzPSIiPmhheWFidXNhZ3NtQGdtYWlsLmNvbTwvYT4mZ3Q7PHNwYW4gbGFuZz0iWkgtQ04i IGNsYXNzPSIiPuOBruODoeODvOODqzwvc3Bhbj46PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj5IaSBKb2Vs PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47 IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPkkgYW0gaW4gYWdyZWVtZW50IGFzIHdlbGwgd2l0 aCB3aGF0IHlvdSBoYXZlIHN0YXRlZCB0aGF0IG9uY2UgdGhlIE8gYml0IGlzIGRlcHJlY2F0ZWQg dGhhdCBOU0ggbWV0YWRhdGEgY2Fubm90IGJlIHVzZWQgZm9yIE9BTSBhbmQgdGhhdCB3ZSB3b3Vs ZCBoYXZlIHRvIG5vdyBmcm9tIHRoYXQgcG9pbnQgZm9yd2FyZCByZWx5DQogb24gdGhlIG5leHQg cHJvdG9jb2wgZmllbGQgYXMgd2Ugd2lsbCBiZSBkb2luZyBmb3IgU0ZDIE11bHRpbGF5ZXIgYW5k IFNGQyBJT0FNIGRyYWZ0cyBhcyB3ZWxsIGFzIHdpbGwgaGF2ZSBiYWNrd2FyZHMgY29tcGF0aWJs ZSB3aXRoIGFueSBhbHJlYWR5IGV4aXN0aW5nIGRlZmluZWQgbWVjaGFuaXNtcyBpbiBTRkMgTlNI LiAmbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 IFNpbVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+SSBkb27igJl0IHNlZSBhbnkgaXNz dWVzIG9yIGltcGFjdCB3aXRoIG1vdmluZyBmb3J3YXJkLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFz cz0iIj5LaW5kIFJlZ2FyZHMmbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+R3lhbjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIg Y2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPk9uIFN1biwgRmViIDEzLCAyMDIyIGF0 IDEyOjA0IFBNIEdyZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21h aWwuY29tIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg Y2xhc3M9IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1zdHlsZTog bm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHQ7IGJvcmRlci1sZWZ0 LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmc6IDBpbiAwaW4gMGluIDZwdDsgbWFy Z2luLWxlZnQ6IDQuOHB0OyBtYXJnaW4tcmlnaHQ6IDBpbjsiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+SGkgSm9lbCw8c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+SSBhZ3JlZSB0aGF0LCBh cyB3ZSBmaW5kIFNGQyBOU0ggbm93LCBubyBPQU0gbWV0YWRhdGEgaGFzIGJlZW4gZGVmaW5lZC4g SXQgYXBwZWFycyB0byBtZSB0aGF0IGRlcHJlY2F0aW5nIHRoZSBPIGJpdCBkb2VzIG5vdCBhZmZl Y3QgYW55IG9mIHRoZSZuYnNwO2FscmVhZHkgZGVmaW5lZCBtZWNoYW5pc21zIGluIHRoZSZuYnNw O1NGQyBOU0guDQogSSB0aGluayB0aGF0IGlmIGEgbmV3LCBmb3IgZXhhbXBsZSwgTUQgVHlwZSA9 IDIgVExWIHRoYXQmbmJzcDtpcyB1c2VkIGZvciBhbnkgT0FNIGZ1bmN0aW9uYWxpdHkgdG8gYmUg cHJvcG9zZWQgaW4gdGhlIGZ1dHVyZSwgZGVwcmVjYXRlZCB0aGUgTyBiaXQgd291bGQmbmJzcDtu b3QgcHJldmVudCB1c2luZyBzdWNoIE5TSCBUTFYuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj5XaGF0IGRvIHlvdSB0aGlu az88bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1 bjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+UmVnYXJkcyw8bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPkdyZWc8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiBTaW1TdW47IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyIgY2xhc3M9IiI+T24gU3VuLCBG ZWIgMTMsIDIwMjIgYXQgNjo1NSBBTSBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmptaEBqb2VsaGFscGVybi5j b208L2E+Jmd0Ow0KIHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3Jk ZXItbGVmdC13aWR0aDogMXB0OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQp OyBwYWRkaW5nOiAwaW4gMGluIDBpbiA2cHQ7IG1hcmdpbi1sZWZ0OiA0LjhwdDsgbWFyZ2luLXJp Z2h0OiAwaW47IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj5UaGVyZSBpcyBhbiBpbXBsaWNh dGlvbiBvZiBkZXByZWNhdGluZyB0aGUgTy1iaXQgdGhhdCBJIHdvdWxkIGxpa2UgdG88c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0K aGVhciBmcm9tIG1vcmUgV0cgcGFydGljaXBhbnRzIGFib3V0LjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkFzIGZhciBhcyBJIGNhbiB0ZWxsLCBpZiB3ZSBkZXByZWNhdGUgdGhlIE8tYml0 IGFuZCByZWx5IG9uIHRoZSBuZXh0PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnByb3RvY29sIGZpZWxkLCB3ZSBhcmUgc2F5aW5n IHRoYXQgaW4gcHJhY3RpY2UgKG5vdCBieSBydWxlKSBOU0g8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KbWV0YWRhdGEgY2FuIG5v dCBiZSB1c2VkIGZvciBPQU0uJm5ic3A7IFRoYXQncyBmaW5lIHdpdGggbWUgYXMgbG9uZyBhcyB3 ZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xh c3M9IiI+DQphZ3JlZSBvbiB0aGF0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCllvdXJz LDxiciBjbGFzcz0iIj4NCkpvZWw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiAyLzEz LzIwMjIgMjo1MiBBTSwgR3lhbiBNaXNocmEgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+ DQomZ3Q7IEhpIEppbSwgSm9lbCAmYW1wOyBTRkMgV0csPGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+ DQomZ3Q7IEkgYWdyZWUgdGhhdCB0aGUgUkZDIDgzMDAgZGVmaW5pdGlvbiBvZiBPIGJpdCBpcyBp bmNvbXBsZXRlIGFuZCBub3Q8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0OyBjbGVhciBhcyB0byBpdHMgaW50ZW5kZWQgdXNl LjxiciBjbGFzcz0iIj4NCiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0OyBUaGF0IGlzIGEgcHJvYmxlbSB0aGF0IEkg YWdyZWUgbmVlZHMgdG8gYmUgcmVjdGlmaWVkLjxiciBjbGFzcz0iIj4NCiZndDs8c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0 OyBJIHVuZGVyc3RhbmQgdGhhdCB3ZSBuZWVkIHRvIGdldCB0aGlzIHJlc29sdmVkIGJlZm9yZSB3 ZSBjYW4gcHJvZ3Jlc3M8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0OyBNdWx0aWxheWVyIFNGQyBPQU0gZHJhZnQtaWV0Zi1z ZmMtbXVsdGktbGF5ZXItb2FtLTE4IGFuZCBTRkMgSU9BTS48YnIgY2xhc3M9IiI+DQomZ3Q7PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0i Ij4NCiZndDsgSSBhZ3JlZSB0aGF0IHdoYXQgbWFrZXMgc2Vuc2UgdG8gbWUgYXMgYSBwYXRoIGZv cndhcmQgaXMgdG8gZGVwcmVjYXRlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZndDsgdGhlIE8gYml0IGFuZCBub3QgdXNlIGlu IFNGQyBNdWx0aWxheWVyIE9BTSBhbmQgU0ZDIElPQU0sIGFzIGJvdGggU0ZDPHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZndDsg TXVsdGlsYXllciBPQU0gYW5kIFNGQyBJT0FNIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSByZXNwZWN0 aXZlIHZhbHVlcyBmb3I8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0OyB0aGUgTlNIIE5leHQgUHJvdG9jb2wgZmllbGQgKHRv IGJlIGFzc2lnbmVkIGJ5IElBTkEpLCBhcyB3ZWxsIGFzIHNvIGZhcjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7IG5vIE9B TS1zcGVjaWZpYyBtZXRhIGRhdGEgVExWIGhhcyBiZWVuIHlldCBkZWZpbmVkLjxiciBjbGFzcz0i Ij4NCiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyIGNsYXNzPSIiPg0KJmd0OyBTbyB3ZSBoYXZlIEkgYmVsaWV2ZSBzb2xpZCBzb2x1dGlvbiBh bmQgcGF0aCBmb3J3YXJkIGFuZCBJIHN1cHBvcnQ8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0OyBkZXByZWNhdGluZyB0aGUg TyBiaXQuPGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7IEtpbmQgUmVnYXJkczxiciBjbGFz cz0iIj4NCiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyIGNsYXNzPSIiPg0KJmd0OyBHeWFuPGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7 IE9uIFdlZCwgRmViIDIsIDIwMjIgYXQgNTo0MiBQTSBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xv cjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5ncmVnaW1pcnNr eUBnbWFpbC5jb208L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86Z3Jl Z2ltaXJza3lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNv bTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwO1RoYW5rIHlvdSwgSmltIGFuZCBKb2VsLCBmb3IgZ3VpZGluZyB0aGUgU0ZD IE9BTSB3b3JrIGFuZCBwb2ludGluZzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwO291dCB0aGUgaXNzdWUgdGhhdCBtdXN0IGJlIGFkZHJlc3NlZC48YnIgY2xhc3M9IiI+DQom Z3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBj bGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0kndmUgcmV2aWV3ZWQgb3VyIFNGQyBP QU0gZG9jdW1lbnRzIGFuZCBkcmFmdC1pZXRmLXNmYy1uc2gtdGx2LiBBcyBJPGJyIGNsYXNzPSIi Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dW5kZXJzdGFuZCB0aGVzZSBkb2N1bWVudHMsIHRo ZSBBY3RpdmUgU0ZDIE9BTSBhbmQgSU9BTSBhcmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDtpZGVudGlmaWVkIGJ5IHRoZSByZXNwZWN0aXZlIHZhbHVlcyBmb3IgdGhlIE5T SCBOZXh0IFByb3RvY29sIGZpZWxkPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7KHRvIGJlIGFzc2lnbmVkIGJ5IElBTkEpLiBBdCB0aGUgc2FtZSB0aW1lLCBzbyBmYXIgbm8g T0FNLXNwZWNpZmljPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7bWV0YSBk YXRhIFRMViBoYXMgYmVlbiBkZWZpbmVkLiBUaHVzLCBpdCBhcHBlYXJzIHRoYXQgb25lIHdheTxi ciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2ZvcndhcmQgY291bGQgYmUgdG8g bm90IGludm9sdmUgdGhlIE8gYml0IGluIHRoZSBhY3RpdmUgU0ZDIE9BTSBvcjxiciBjbGFzcz0i Ij4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0lPQU0gYWx0b2dldGhlci4gSW4gb3RoZXIgd29y ZHMsIHRvIGRlcHJlY2F0ZSB0aGUgTlNIIE8gYml0LjxiciBjbGFzcz0iIj4NCiZndDs8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7SSBncmVhdGx5IGFwcHJlY2lhdGUgeW91ciBjb21tZW50 cyBvbiB0aGUgcHJvcG9zYWwgdG8gZGVwcmVjYXRlIHRoZTxiciBjbGFzcz0iIj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwO05TSCBPIGJpdC48YnIgY2xhc3M9IiI+DQomZ3Q7PHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO1JlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7R3JlZzxiciBjbGFzcz0iIj4NCiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7T24gV2VkLCBGZWIgMiwgMjAyMiBhdCAxMDozNiBBTSBKYW1lcyBHdWljaGFyZDxiciBj bGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86amFt ZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9y OiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmphbWVzLm4uZ3Vp Y2hhcmRAZnV0dXJld2VpLmNvbTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdl aS5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPC9h PiZndDsmZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtIaSBXRzpfX19fPGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyIGNsYXNzPSIi Pg0KJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0hhdmlu ZyByZXZpZXdlZCBhbGwgb2YgdGhlIE9BTSByZWxhdGVkIGRvY3VtZW50cyBpbiBvdXIgV0csIHRo ZTxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2hh aXJzIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBhIGZldyBjb21tZW50cyB0byBob3BlZnVsbHk8YnIg Y2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2dlbmVyYXRl IGRpc2N1c3Npb24gYW5kIGZvcndhcmQgcHJvZ3Jlc3Mgb2YgdGhpcyB3b3JrOl9fX188YnIgY2xh c3M9IiI+DQomZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 X18gX188YnIgY2xhc3M9IiI+DQomZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7MSkgVGhlIGNoYWlycyBoYXZlIHJldmlld2VkIHRoZSBPIGJpdCBkZWZpbml0 aW9uIGluIFJGQyA4MzAwLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1RoYXQgZGVmaW5pdGlvbiBpcyBhdCBiZXN0IG9wZW4gdG8gaW50ZXJwcmV0YXRpb24gYW5k IHRoZXJlZm9yZTxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7aW5jb21wbGV0ZS4mbmJzcDsgRm9yIGV4YW1wbGUsIHRoZSBjbGVhciBpbnRlbnRpb24g aXMgb25seSB0byBtYXJrPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtwYWNrZXRzIHdoaWNoIGFyZSBpbnRlbmRlZCBmb3IgU0ZDIE9BTSBhdCB0aGUg U0ZDIHNlcnZpY2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2xheWVyLiZuYnNwOyBCdXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgY3VycmVudCB0ZXh0 IHNheXMuJm5ic3A7IFRoZXJlIGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDthbHNvLCB1bmZvcnR1bmF0ZWx5LCBhbWJpZ3VpdHkgYXMgdG8gd2hh dCBjb25zdGl0dXRlcyBhbiBPQU08YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3BhY2tldC4mbmJzcDsgU28gaXQgaXMgcmVhc29uYWJsZSBmb3IgZG9j dW1lbnRzIHRvIHVwZGF0ZSA4MzAwIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtjbGFyaWZ5IHRoZSBleGFjdCBhcHBsaWNhYmlsaXR5IGFuZCBh Y3Rpb24gZm9yIHRoZSBPLWJpdC5fX19fPGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyIGNsYXNzPSIiPg0KJmd0Ozxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9 IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzIpIEhvd2V2ZXIsIHJl bGF0ZWQgdG8gcG9pbnQgMSksIHdlIGNhbid0IGhhdmUgbXVsdGlwbGU8YnIgY2xhc3M9IiI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RvY3VtZW50cyB1cGRhdGluZyB0 aGUgZGVmaW5pdGlvbiBkaWZmZXJlbnRseS4mbmJzcDsgQXMgc3VjaCwgdGhlPGJyIGNsYXNzPSIi Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthdXRob3JzIG9mIHRoZSBT RkMgaU9BTSBkcmFmdCBhbmQgdGhlIFNGQyBtdWx0aS1sYXllci1vYW0gZHJhZnQ8YnIgY2xhc3M9 IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO25lZWQgdG8gY29tZSB0 b2dldGhlciBhbmQgZmlndXJlIG91dCB3aGF0IHRoZSBjbGFyaWZpY2F0aW9uIGlzPGJyIGNsYXNz PSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmb3IgdGhlIGRlZmlu aXRpb24gb2YgdGhhdCBiaXQuIFdlIGRvIG5vdCBiZWxpZXZlIGFzIGNoYWlycyB0aGF0PGJyIGNs YXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtlaXRoZXIgb2Yg dGhlc2UgZG9jdW1lbnRzIGNhbiBtb3ZlIGZvcndhcmQgZnJvbSB0aGUgV0cgdW50aWw8YnIgY2xh c3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N1Y2ggY2xhcml0 eSBoYXMgYmVlbiByZWFjaGVkLiBfX19fPGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyIGNsYXNzPSIiPg0KJmd0Ozxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9 IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzMpIFJlbGF0ZWQgdG8g dGhlIFNGQyBpT0FNLCB3ZSBuZWVkIGEgY2xlYXIgZGVmaW5pdGlvbiBvZiBpT0FNLjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZXJlIHNlZW0gdG8gYmUgZGlm ZmVyZW5jZXMgYmV0d2VlbiB0aGUgZGVmaW5pdGlvbnMgaW48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3B1Ymxpc2hlZCBSRkNzLCB0aGUgdXNhZ2Ug KHdoaWNoIGlzIG5vdCBhIGRlZmluaXRpb24pIGluIHRoZSBTRkM8YnIgY2xhc3M9IiI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LCBhbmQgdGhlIHZhcmlvdXMg aXBwbSBkcmFmdHMuJm5ic3A7IEFueSBzdWNoIGRlZmluaXRpb24gd2lsbDxiciBjbGFzcz0iIj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmVlZCB0byBiZSB2ZXR0ZWQg d2l0aCB0aGUgaXBwbSB3b3JraW5nIGdyb3VwLl9fX188YnIgY2xhc3M9IiI+DQomZ3Q7PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18gX188YnIgY2xhc3M9IiI+ DQomZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi ciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QWdhaW4s IGl0IHdvdWxkIGJlIGdvb2QgaWYgbWVtYmVycyBvZiB0aGUgd29ya2luZyBncm91cCBiZXlvbmQ8 YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSB0 d28gYXV0aG9yIHRlYW1zIHNwb2tlIHVwIGFib3V0IHRoZWlyIHJlYWRpbmdzIG9mIHRoZTxiciBj bGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZG9jdW1lbnRz LCBhbmQgdGhlaXIgdW5kZXJzdGFuZGluZ3Mgb2Ygd2hhdCB3ZSBuZWVkLl9fX188YnIgY2xhc3M9 IiI+DQomZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18g X188YnIgY2xhc3M9IiI+DQomZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7WW91cnMsX19fXzxiciBjbGFzcz0iIj4NCiZndDs8c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKaW0gYW5kIEpvZWxfX19fPGJyIGNsYXNzPSIiPg0K Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIg Y2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJy IGNsYXNzPSIiPg0KJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO19fIF9fPGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtzZmMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsiIGNsYXNzPSIiPnNmY0BpZXRmLm9yZzwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsiIGNsYXNzPSIiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczov L25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzZmMmYW1wO2RhdGE9MDQlN0Mw MSU3Q2phbWVzLm4uZ3VpY2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDOWRiMmFiMGE5MzgyNDYxMzk3 ZjkwOGQ5ZWY2ZjdmZjUlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0Mx JTdDNjM3ODA0MDg0NDgxMTk2MjY0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0 d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3 QzMwMDAmYW1wO3NkYXRhPVIxMjByUE1hWWJiUkxPdjVqR0ElMkJpQUpvdExxNEJPOGZhaGczNDUy bjJQVSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1 ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL25hbTExLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5v cmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzZmMmYW1wO2RhdGE9MDQlN0MwMSU3Q2phbWVzLm4u Z3VpY2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDOWRiMmFiMGE5MzgyNDYxMzk3ZjkwOGQ5ZWY2Zjdm ZjUlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3ODA0MDg0 NDgxMzUyNTE0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENK UUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3Nk YXRhPSUyRmtvdEV3b2RnT2N3d3BQZ3JOSUl5WiUyQlk1dEMzYklpZWdLQWp6dm8lMkJwS0klM0Qm YW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmM8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDs8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtzZmMgbWFpbGlu ZyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFp bHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8L2E+PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjog Ymx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8 L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNmYyZhbXA7ZGF0YT0w NCU3QzAxJTdDamFtZXMubi5ndWljaGFyZCU0MGZ1dHVyZXdlaS5jb20lN0M5ZGIyYWIwYTkzODI0 NjEzOTdmOTA4ZDllZjZmN2ZmNSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdD MSU3QzElN0M2Mzc4MDQwODQ0ODEzNTI1MTQlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lq b2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4w JTNEJTdDMzAwMCZhbXA7c2RhdGE9JTJGa290RXdvZGdPY3d3cFBnck5JSXlaJTJCWTV0QzNiSWll Z0tBanp2byUyQnBLSSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJj b2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9uYW0xMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGc2ZjJmFtcDtkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNo YXJkJTQwZnV0dXJld2VpLmNvbSU3QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5MDhkOWVmNmY3ZmY1JTdD MGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNDA4NDQ4MTM1 MjUxNCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9p VjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT0l MkZrb3RFd29kZ09jd3dwUGdyTklJeVolMkJZNXRDM2JJaWVnS0FqenZvJTJCcEtJJTNEJmFtcDty ZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29y YXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjPC9hPiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZndDsgLS08c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIi Pg0KJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnIgY2xhc3M9IiI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL25hbTExLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnd3dy52ZXJpem9uLmNvbSUy RiZhbXA7ZGF0YT0wNCU3QzAxJTdDamFtZXMubi5ndWljaGFyZCU0MGZ1dHVyZXdlaS5jb20lN0M5 ZGIyYWIwYTkzODI0NjEzOTdmOTA4ZDllZjZmN2ZmNSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2Ex ZDU1OTFmZWRjJTdDMSU3QzElN0M2Mzc4MDQwODQ0ODEzNTI1MTQlN0NVbmtub3duJTdDVFdGcGJH WnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3 aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9T05qZmczR1pKNWF0cjF4OEJSNzkyWHpP JTJGOXBvempOMkdHSkJBJTJGNWpLOHclM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5r IiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9 IiI+aHR0cDovL3d3dy52ZXJpem9uLmNvbS88L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDs8c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIi Pg0KJmd0OyAqR3lhbiBNaXNocmEqPGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7IC9OZXR3 b3JrIFNvbHV0aW9ucyBBLy9yY2hpdGVjdCAvPGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7 IC9FbWFpbDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5neWFuLnMubWlzaHJhQHZlcml6b24uY29tPC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpneWFuLnMu bWlzaHJhQHZlcml6b24uY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmd5YW4ucy5taXNocmFAdmVyaXpv bi5jb208L2E+Jmd0Oy8vPGJyIGNsYXNzPSIiPg0KJmd0OyAvPGJyIGNsYXNzPSIiPg0KJmd0Ozxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9 IiI+DQomZ3Q7IC9NIDMwMSA1MDItMTM0NzxiciBjbGFzcz0iIj4NCiZndDs8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KJmd0OyAv PGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQomZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1T dW47IiBjbGFzcz0iIj4tLTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vbmFtMTEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGd3d3LnZlcml6b24uY29t JTJGJmFtcDtkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3 QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5MDhkOWVmNmY3ZmY1JTdDMGZlZThmZjJhM2IyNDAxODljNzUz YTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNDA4NDQ4MTM1MjUxNCU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhh V3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1PTmpmZzNHWko1YXRyMXg4QlI3OTJY ek8lMkY5cG96ak4yR0dKQkElMkY1aks4dyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxh bmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxNywgODUsIDIwNCk7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsiIGNsYXNzPSIiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iODEiIGhlaWdodD0iMTgi IGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cDovL3NzNy52encuY29tL2lzL2ltYWdlL1Zlcml6 b25XaXJlbGVzcy92ei1sb2dvLWVtYWlsIiBzdHlsZT0id2lkdGg6IDAuODQzN2luOyBoZWlnaHQ6 IDAuMTg3NWluOyIgY2xhc3M9IiI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigz NCwgMzQsIDM0KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj48YiBjbGFzcz0iIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+R3lhbiBNaXNocmE8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiBTaW1TdW47IiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEdlb3JnaWEsIHNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyIgY2xhc3M9IiI+TmV0 d29yayBTb2x1dGlvbnMgQXJjaGl0ZWN0Jm5ic3A7PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29s b3I6IHJnYigzNCwgMzQsIDM0KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPjxpIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBHZW9yZ2lhLCBz ZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsiIGNsYXNzPSIiPkVtYWlsPHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpneWFu LnMubWlzaHJhQHZlcml6b24uY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmd5YW4ucy5taXNocmFAdmVy aXpvbi5jb208L2E+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzNCwgMzQsIDM0 KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBp biAxMnB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxpIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogR2VvcmdpYSwgc2VyaWY7IiBjbGFzcz0iIj5N IDMwMSA1MDItMTM0Nzwvc3Bhbj48L2k+PG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZu YnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiIGNsYXNzPSIiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0Kc2Zj IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci IHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5zZmNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYzwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D501B10D8AA64D679A57F799BE9CD517ciscocom_-- From nobody Mon Feb 14 10:09:16 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211753A08C7 for ; Mon, 14 Feb 2022 10:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.087 X-Spam-Level: X-Spam-Status: No, score=-7.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxtFYEDyELhC for ; Mon, 14 Feb 2022 10:09:08 -0800 (PST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7C63A08C8 for ; Mon, 14 Feb 2022 10:09:08 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id lw4so8369943ejb.12 for ; Mon, 14 Feb 2022 10:09:08 -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=Fb8NNvpyS8SIy/cHgEeew6FAoxVse+zQfWmwhHt2H/I=; b=btOr+Dq2YWBt2v++/EzLVij4GeEySmrdsifk2U1OaESk42wDGvxoBMsTFthBHCAs4o yw/k+Gzvbd50/D55fCyGZwLywUeuXcHQrdhw+1bk/iYTiYHznqtJg9+1BKVrf7Gl+0+f mo8+JGJ3eB0LA92tJ/6MC4fVgXkR5pDuolJ8ICqjo4HWDV/8NpsuKHBf56niF/va0GGq dQZds5IzG0Tgp9HRq53z0Ir1XMh9/r3IhVDcT0tOU7eb0bZZ68nsYtn0tFkLzAwQAVP9 cjiJnLPYTGYWo+39Pgvpb07uKLP9kuBczGBCshxSJfeUetudlRw6EmUPPCUgXpmYHEbl 8C8Q== 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=Fb8NNvpyS8SIy/cHgEeew6FAoxVse+zQfWmwhHt2H/I=; b=0Rt4eZGhkWA4losW4lWCY4ZwaaUdcFuuaEo1IDSPyYGY9qlB5IJ2GSZ1VA+C2dvOku P4VK9z7MNc9+kheQNbeQJGv6ZZvZlrvhkzqqWdJCBR95wafZl7qNeoOFqsW7I2LNNCaD TRi4dk170DcLFMWckyInxuxADnhpAbO/upTbJm1iWL9hD8g3tT8Bv14EeTN9zaicPw+t KEfbJIJbiIBP5zxomq6hWnvOUVa6jyNT0dfscyH5Yev/MCfuAgZDKLWgt11feE/TP1FV pCuEqiGel8cWdNHZWJMaZIk/Z4wcvheDajdoH7S2tgWa//7W0J4icaB98Zp3hnscpzcs IJag== X-Gm-Message-State: AOAM532fuGX2fGDCi1Tl/i2tFBy2jbErJ52ed69XdKH6MFfJ2kC2k4wd 68lMIIS3OKGf5e2GH4ldP2tdK3YB7PYdV4wwWjtyKjQM X-Google-Smtp-Source: ABdhPJyAJ4q3b+0+N+WI/MB9MXiNZ/3tKX0NJlQLckvX8+pPsRsgq8MsAW61fcovg52wG5/+iMBvqr8xGlUhS9aImA4= X-Received: by 2002:a17:907:7da4:: with SMTP id oz36mr655451ejc.59.1644862146221; Mon, 14 Feb 2022 10:09:06 -0800 (PST) MIME-Version: 1.0 References: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.com> In-Reply-To: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.com> From: Greg Mirsky Date: Mon, 14 Feb 2022 10:08:54 -0800 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: Gyan Mishra , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ee20df05d7fe4f24" Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 18:09:14 -0000 --000000000000ee20df05d7fe4f24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Carlos, top-posting your questions addressed to my proposal to deprecate the O-bit. Please find my answers and notes in-lined under the GIM>> tag below. CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM protocols. Those can be encapsulated in IP, in which the Next-Protocol indicates IP =E2=80=94 and (as per RFC 8300) the O-bit is set to indicate a= n OAM packet. GIM>> I cannot find in RFC 8924 the explanation of the encapsulation of the BFD Control message. Should we assume that IPv4/IPv6 is assumed? If that is the case, which IP address is to be used as the destination IP address? And one more, What special processing is ensured by setting the O bit? CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols already included in an RFC. GIM>> Could you please clarify in which part the removal of the O bit breaks, for example, ICMP or BFD? CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM= . GIM>> Could you please clarify to which IOAM document you are referring? CMP: This expired I-D yet implemented in open source uses the O-bit: https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt GIM>> I recall that the WG discussed and agreed to significantly modify the NSH format. That possibly had affected some existing implementations. Regards, Greg On Sun, Feb 13, 2022 at 8:06 PM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Replying to this specific email in the thread, only because it is the > latest one at this point in time, but bundling comments from various plac= es > on the thread. Please find some follow-up comments and questions marked > =E2=80=9CCMP=E2=80=9D, indicating the =E2=80=9CFrom=E2=80=9D, and organiz= ed chronologically: > > *James N Guichard >:* > > 1) The chairs have reviewed the O bit definition in RFC 8300. That > definition is at best open to interpretation and therefore incomplete. F= or > example, the clear intention is only to mark packets which are intended f= or > SFC OAM at the SFC service layer. But that is not what the current text > says. There is also, unfortunately, ambiguity as to what constitutes an > OAM packet. So it is reasonable for documents to update 8300 to clarify > the exact applicability and action for the O-bit. > > > CMP: It is unclear to me what exact issues the chairs are calling out. > There are two issues mentioned: > CMP: 1. "But that is not what the current text says.=E2=80=9D =E2=80=94> = what does the > text say precisely? Can you point to the specific RFC 8300 text that is > believed to be incomplete, and a detailed use case that showcases the > potential issue? An extrapolated counter-example just to make a point: th= e > text does not say what days of the week OAM packets can be marked, yet > there=E2=80=99s an expectation that they will work Mondays and Saturdays = all the > same =E2=80=94 even holidays. > CMP: 2. What specifically is the ambiguity with what an OAM packet is? > Please grep the RFC series for =E2=80=9Coam packet=E2=80=9D, it is not a = new term. > CMP: Net-net, O-bit=3D1, OAM packet. > > 2) However, related to point 1), we can't have multiple documents updatin= g > the definition differently. As such, the authors of the SFC iOAM draft a= nd > the SFC multi-layer-oam draft need to come together and figure out what t= he > clarification is for the definition of that bit. We do not believe as > chairs that either of these documents can move forward from the WG until > such clarity has been reached. > > > CMP: If there is still believed to be an ambiguity or a clear opportunity > for improving the definition, I agree with consolidating that update. I h= ad > suggested before that if such new text or real clarification is agreed, a > separate document that only makes that O-bit clarification is the most > clear and clean way to go. That doc should be a one-pager or less. I=E2= =80=99d be > happy to contribute to that minimal doc, if it is shown to be needed. > > CMP: For completeness also, the "SFC multi-layer-oam=E2=80=9D document ha= s many > outstanding issues besides the O-bit. > > *Greg Mirsky >* > > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I > understand these documents, the Active SFC OAM and IOAM are identified by > the respective values for the NSH Next Protocol field (to be assigned by > IANA). > > > CMP: There is a major issue with the sentence above. Active SFC OAM (as a > category), as per RFC 8300, needs to be identified by setting the O-bit. = No > way around that based on RFC 8300. However, the text "the Active SFC OAM= =E2=80=9D > creates confusion since it refer to a specific OAM protocol which has the > same name as a the category as well. That name collision is quite > unfortunate in my opinion. > > At the same time, so far no OAM-specific meta data TLV has been defined. > Thus, it appears that one way forward could be to not involve the O bit i= n > the active SFC OAM or IOAM altogether. In other words, to deprecate the N= SH > O bit. > > > CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM > protocols. Those can be encapsulated in IP, in which the Next-Protocol > indicates IP =E2=80=94 and (as per RFC 8300) the O-bit is set to indicate= an OAM > packet. > CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols > already included in an RFC. > CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of > IOAM. > CMP: This expired I-D yet implemented in open source uses the O-bit: > https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt > > > *Gyan Mishra >* > > I agree that what makes sense to me as a path forward is to deprecate the > O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC > Multilayer OAM and SFC IOAM are identified by the respective values for t= he > NSH Next Protocol field (to be assigned by IANA), as well as so far no > OAM-specific meta data TLV has been yet defined. > > > CMP: What is the =E2=80=9CSFC Multilayer OAM=E2=80=9D? > CMP: The O-bit (reading RFC 8300) does not indicate if there is OAM > Metadata. It indicates an OAM packet. > > > *"Joel M. Halpern" >* > > As far as I can tell, if we deprecate the O-bit and rely on the next > protocol field, we are saying that in practice (not by rule) NSH metadata > can not be used for OAM. That's fine with me as long as we agree on that= . > > > CMP: I do not fully follow this. Can you explain the relationship of the > O-bit with Metadata? > CMP: Here=E2=80=99s an example: RFC 8924 shows ICMP as Active OAM. The SF= C next > protocol is IP, the IP next protocol is ICMP, the O-bit needs to be set. > > CMP: Consider the following document, independent submission and in the > RFC Publication queue already: > CMP: > https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/ > CMP: Is a Timestamp in Metadata an OAM element? > > CMP: Consider this proposal > https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/ > CMP: Where the base header borrows a bit for an OAM function. > > CMP: Neither of those have any impact on the O-bit. > > > *Greg Mirsky >* > > I agree that, as we find SFC NSH now, no OAM metadata has been defined. I= t > appears to me that deprecating the O bit does not affect any of the alrea= dy > defined mechanisms in the SFC NSH. > > > CMP: It actually does, see my example above. > > I think that if a new, for example, MD Type =3D 2 TLV that is used for an= y > OAM functionality to be proposed in the future, deprecated the O bit > would not prevent using such NSH TLV. > > > CMP: I agree with this =E2=80=94 because there is no correlation between = MD Type > field and O-bit as defined. > > Best, > > Carlos. > > > > 2/13/22 =E5=8D=88=E5=BE=8C12:32=E3=80=81Gyan Mishra =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > Hi Joel > > I am in agreement as well with what you have stated that once the O bit i= s > deprecated that NSH metadata cannot be used for OAM and that we would hav= e > to now from that point forward rely on the next protocol field as we will > be doing for SFC Multilayer and SFC IOAM drafts as well as will have > backwards compatible with any already existing defined mechanisms in SFC > NSH. > > I don=E2=80=99t see any issues or impact with moving forward. > > Kind Regards > > Gyan > > On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky > wrote: > >> Hi Joel, >> I agree that, as we find SFC NSH now, no OAM metadata has been defined. >> It appears to me that deprecating the O bit does not affect any of >> the already defined mechanisms in the SFC NSH. I think that if a new, fo= r >> example, MD Type =3D 2 TLV that is used for any OAM functionality to be >> proposed in the future, deprecated the O bit would not prevent using suc= h >> NSH TLV. >> What do you think? >> >> Regards, >> Greg >> >> On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern >> wrote: >> >>> There is an implication of deprecating the O-bit that I would like to >>> hear from more WG participants about. >>> >>> As far as I can tell, if we deprecate the O-bit and rely on the next >>> protocol field, we are saying that in practice (not by rule) NSH >>> metadata can not be used for OAM. That's fine with me as long as we >>> agree on that. >>> >>> Yours, >>> Joel >>> >>> On 2/13/2022 2:52 AM, Gyan Mishra wrote: >>> > >>> > Hi Jim, Joel & SFC WG, >>> > >>> > I agree that the RFC 8300 definition of O bit is incomplete and not >>> > clear as to its intended use. >>> > >>> > That is a problem that I agree needs to be rectified. >>> > >>> > I understand that we need to get this resolved before we can progress >>> > Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM. >>> > >>> > I agree that what makes sense to me as a path forward is to deprecate >>> > the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC >>> > Multilayer OAM and SFC IOAM are identified by the respective values >>> for >>> > the NSH Next Protocol field (to be assigned by IANA), as well as so >>> far >>> > no OAM-specific meta data TLV has been yet defined. >>> > >>> > So we have I believe solid solution and path forward and I support >>> > deprecating the O bit. >>> > >>> > Kind Regards >>> > >>> > Gyan >>> > >>> > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky >> > > wrote: >>> > >>> > Thank you, Jim and Joel, for guiding the SFC OAM work and pointin= g >>> > out the issue that must be addressed. >>> > >>> > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. A= s >>> I >>> > understand these documents, the Active SFC OAM and IOAM are >>> > identified by the respective values for the NSH Next Protocol fie= ld >>> > (to be assigned by IANA). At the same time, so far no OAM-specifi= c >>> > meta data TLV has been defined. Thus, it appears that one way >>> > forward could be to not involve the O bit in the active SFC OAM o= r >>> > IOAM altogether. In other words, to deprecate the NSH O bit. >>> > >>> > I greatly appreciate your comments on the proposal to deprecate t= he >>> > NSH O bit. >>> > >>> > Regards, >>> > Greg >>> > >>> > On Wed, Feb 2, 2022 at 10:36 AM James Guichard >>> > >> > > wrote: >>> > >>> > Hi WG:____ >>> > >>> > __ __ >>> > >>> > Having reviewed all of the OAM related documents in our WG, t= he >>> > chairs would like to provide a few comments to hopefully >>> > generate discussion and forward progress of this work:____ >>> > >>> > __ __ >>> > >>> > 1) The chairs have reviewed the O bit definition in RFC 8300. >>> > That definition is at best open to interpretation and therefo= re >>> > incomplete. For example, the clear intention is only to mark >>> > packets which are intended for SFC OAM at the SFC service >>> > layer. But that is not what the current text says. There is >>> > also, unfortunately, ambiguity as to what constitutes an OAM >>> > packet. So it is reasonable for documents to update 8300 to >>> > clarify the exact applicability and action for the O-bit.____ >>> > >>> > __ __ >>> > >>> > 2) However, related to point 1), we can't have multiple >>> > documents updating the definition differently. As such, the >>> > authors of the SFC iOAM draft and the SFC multi-layer-oam dra= ft >>> > need to come together and figure out what the clarification i= s >>> > for the definition of that bit. We do not believe as chairs >>> that >>> > either of these documents can move forward from the WG until >>> > such clarity has been reached. ____ >>> > >>> > __ __ >>> > >>> > 3) Related to the SFC iOAM, we need a clear definition of >>> iOAM. >>> > There seem to be differences between the definitions in >>> > published RFCs, the usage (which is not a definition) in the >>> SFC >>> > draft, and the various ippm drafts. Any such definition will >>> > need to be vetted with the ippm working group.____ >>> > >>> > __ __ >>> > >>> > Again, it would be good if members of the working group beyon= d >>> > the two author teams spoke up about their readings of the >>> > documents, and their understandings of what we need.____ >>> > >>> > __ __ >>> > >>> > Yours,____ >>> > >>> > Jim and Joel____ >>> > >>> > __ __ >>> > >>> > __ __ >>> > >>> > __ __ >>> > >>> > _______________________________________________ >>> > sfc mailing list >>> > sfc@ietf.org >>> > https://www.ietf.org/mailman/listinfo/sfc >>> > >>> > >>> > _______________________________________________ >>> > sfc mailing list >>> > sfc@ietf.org >>> > https://www.ietf.org/mailman/listinfo/sfc >>> > >>> > >>> > -- >>> > >>> > >>> > >>> > *Gyan Mishra* >>> > >>> > /Network Solutions A//rchitect / >>> > >>> > /Email gyan.s.mishra@verizon.com // >>> > / >>> > >>> > /M 301 502-1347 >>> > >>> > / >>> > >>> > >>> >> -- > > > *Gyan Mishra* > *Network Solutions A**rchitect * > *Email gyan.s.mishra@verizon.com * > > > *M 301 502-1347 * > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > --000000000000ee20df05d7fe4f24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Carlos,
top-posting your questio= ns addressed to my proposal to deprecate the O-bit. Please find my answers = and notes in-lined under the GIM>> tag below.
CMP: RFC= 8924 already includes ICMP and BFD as example SFC Action OAM protocols. Th= ose can be encapsulated in IP, in which the Next-Protocol indicates IP =E2= =80=94 and (as per RFC 8300) the O-bit is set to indicate an OAM packet.
GIM>> I cannot find in RFC 8924 the explanation of the encaps= ulation of the BFD Control message. Should we assume that IPv4/IPv6 is assu= med? If that is the case, which IP address is to be used as the destination= IP address? And one more, What special processing is ensured by setting th= e O bit?
CMP: The proposal of deprecating the O-bit breaks those = SFC OAM protocols already included in an RFC.
GIM>> Could y= ou please clarify in which part the removal of the O bit breaks, for exampl= e, ICMP or BFD?
CMP: That proposal of deprecating the O-bit also = breaks Section 4.1 of IOAM.
GIM>> Could you please clarify = to which IOAM document you are referring?
CMP: This expired I-D y= et implemented in open source uses the O-bit: https://www.ietf.org/archive/id= /draft-penno-sfc-trace-03.txt=C2=A0
GIM>> I recal= l that the WG discussed and agreed to significantly modify the NSH format. = That possibly had affected some existing implementations.

Regards,
Greg



On= Sun, Feb 13, 2022 at 8:06 PM Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Replying to this specific email in the thread, only because it is the lates= t one at this point in time, but bundling comments from various places on t= he thread. Please find some follow-up comments and questions marked =E2=80= =9CCMP=E2=80=9D, indicating the =E2=80=9CFrom=E2=80=9D, and organized chronologically:

James N Guichard <james.n.guichard@futurewei.com>:

1) The chairs have reviewed the O bit definition in RFC 8300.=C2=A0 That de= finition is at best open to interpretation and therefore incomplete.=C2=A0 = For example, the clear intention is only to mark packets which are intended= for SFC OAM at the SFC service layer.=C2=A0 But that is not what the current text says.=C2=A0 There is also, unfortunately= , ambiguity as to what constitutes an OAM packet.=C2=A0 So it is reasonable= for documents to update 8300 to clarify the exact applicability and action= for the O-bit.

CMP: It is unclear to me what exact issues the chairs are calling out.= There are two issues mentioned:
CMP: 1. "But that is not what the current text says.=E2=80=9D =E2= =80=94> what does the text say precisely?=C2=A0 Can you point to the spe= cific RFC 8300 text that is believed to be incomplete, and a detailed use c= ase that showcases the potential issue? An extrapolated counter-example just to make a point: the text does not =C2=A0say what day= s of the week OAM packets can be marked, yet there=E2=80=99s an expectation= that they will work Mondays and Saturdays all the same =E2=80=94 even holi= days.
CMP: 2. What specifically is the ambiguity with what an OAM packet is?= Please grep the RFC series for =E2=80=9Coam packet=E2=80=9D, it is not a n= ew term.=C2=A0
CMP: Net-net, O-bit=3D1, OAM packet.=C2=A0

2) However, related to point 1), we can't have multiple documents updat= ing the definition differently.=C2=A0 As such, the authors of the SFC iOAM = draft and the SFC multi-layer-oam draft need to come together and figure ou= t what the clarification is for the definition of that bit. We do not believe as chairs that either of these documents ca= n move forward from the WG until such clarity has been reached.

CMP: If there is still believed to be an ambiguity or a clear opportun= ity for improving the definition, I agree with consolidating that update. I= had suggested before that if such new text or real clarification is agreed= , a separate document that only makes that O-bit clarification is the most clear and clean way to go.= That doc should be a one-pager or less. I=E2=80=99d be happy to contribute= to that minimal doc, if it is shown to be needed.

CMP: For completeness also, the "SFC multi-layer-oam=E2=80=9D doc= ument has many outstanding issues besides the O-bit.

Greg Mirsky <gregimirsky@gmail.com>

I've reviewed our SFC OAM documents and draft= -ietf-sfc-nsh-tlv. As I understand these documents, the Active SFC OAM and = IOAM are identified by the respective values for the NSH Next Protocol fiel= d (to be assigned by IANA).

CMP: There is a major issue with the sentence above. Active SFC OAM (a= s a category), as per RFC 8300, needs to be identified by setting the O-bit= . No way around that based on RFC 8300. However, the text "the Active = SFC OAM=E2=80=9D creates confusion since it refer to a specific OAM protocol which has the same name as a the categ= ory as well. That name collision is quite unfortunate in my opinion.

At the same time, so far no OAM-specific meta dat= a TLV has been defined. Thus, it appears that one way forward could be to n= ot involve the O bit in the active SFC OAM or IOAM altogether. In other wor= ds, to deprecate the NSH O bit.

CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM proto= cols. Those can be encapsulated in IP, in which the Next-Protocol indicates= IP =E2=80=94 and (as per RFC 8300) the O-bit is set to indicate an OAM pac= ket.
CMP: The proposal of deprecating the O-bit breaks those SFC OAM protoc= ols already included in an RFC.
CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of= IOAM.
CMP: This expired I-D yet implemented in open source uses the O-bit:= =C2=A0https://www.ietf.org/archive/id/draft-penno-sfc-trace= -03.txt=C2=A0


Gyan Mishra <hayabusagsm@gmail.com>

I agree that what makes sense to me as a path forward is = to deprecate the O bit and not use in SFC Multilayer OAM and SFC IOAM, as b= oth SFC Multilayer=C2=A0OAM and SFC=C2=A0IOAM are identified by the respect= ive values for the NSH Next Protocol field (to be assigned by IANA), as well as so far no OAM-specific meta dat= a TLV has been yet defined.

CMP: What is the =E2=80=9CSFC Multilayer OAM=E2=80=9D?
CMP: The O-bit (reading RFC 8300) does not indicate if there is OAM Me= tadata. It indicates an OAM packet.


"Joel M. Halpern" <jmh@joelhalpern.com>

As far as I can tell, if we deprecate the O-bit a= nd rely on the next protocol field, we are saying that in practice (not by = rule) NSH metadata can not be used for OAM.=C2=A0 That's fine with me a= s long as we agree on that.

CMP: I do not fully follow this. Can you explain the relationship of t= he O-bit with Metadata?
CMP: Here=E2=80=99s an example: RFC 8924 shows ICMP as Active OAM. The= SFC next protocol is IP, the IP next protocol is ICMP, the O-bit needs to = be set.=C2=A0

CMP: Consider the following document, independent submission and in th= e RFC Publication queue already:
CMP: Is a Timestamp in Metadata an OAM element?=C2=A0

CMP: Where the base header borrows a bit for an OAM function.

CMP: Neither of those have any impact on the O-bit.=C2=A0


Greg Mirsky <gregimirsky@gmail.com>

I agree that, as we find SFC NSH now, no OAM meta= data has been defined. It appears to me that deprecating the O bit does not= affect any of the=C2=A0already defined mechanisms in the=C2=A0SFC NSH.

CMP: It actually does, see my example above.

I think that if a new, for example, MD Type =3D 2= TLV that=C2=A0is used for any OAM functionality to be proposed in the futu= re, deprecated the O bit would=C2=A0not prevent using such NSH TLV.

CMP: I agree with this =E2=80=94 because there is no correlation betwe= en MD Type field and O-bit as defined.

Best,

Carlos.



2/13/22 =E5=8D=88=E5=BE=8C12:32=E3=80=81Gyan Mishra <hayabusagsm@gmail.com>= =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

Hi Joel

I am in agreement as well with what you have stated that = once the O bit is deprecated that NSH metadata cannot be used for OAM and t= hat we would have to now from that point forward rely on the next protocol = field as we will be doing for SFC Multilayer and SFC IOAM drafts as well as will have backwards comp= atible with any already existing defined mechanisms in SFC NSH. =C2=A0

I don=E2=80=99t see any issues or impact with moving forw= ard.

Kind Regards=C2=A0

Gyan

On Sun, Feb 13, 2022 at 12:04 PM Greg= Mirsky <greg= imirsky@gmail.com> wrote:
Hi Joel,
I agree that, as we find SFC NSH now, no OAM metadata has been defined= . It appears to me that deprecating the O bit does not affect any of the=C2= =A0already defined mechanisms in the=C2=A0SFC NSH. I think that if a new, f= or example, MD Type =3D 2 TLV that=C2=A0is used for any OAM functionality to be proposed in the future, deprecated th= e O bit would=C2=A0not prevent using such NSH TLV.
What do you think?

Regards,
Greg

On Sun, Feb 13, 2022 at 6:55 AM Joel = M. Halpern <jmh= @joelhalpern.com> wrote:
There is an implication of deprecating the O-bit that I would like to
hear from more WG participants about.

As far as I can tell, if we deprecate the O-bit and rely on the next
protocol field, we are saying that in practice (not by rule) NSH
metadata can not be used for OAM.=C2=A0 That's fine with me as long as = we
agree on that.

Yours,
Joel

On 2/13/2022 2:52 AM, Gyan Mishra wrote:
>
> Hi Jim, Joel & SFC WG,
>
> I agree that the RFC 8300 definition of O bit is incomplete and not > clear as to its intended use.
>
> That is a problem that I agree needs to be rectified.
>
> I understand that we need to get this resolved before we can progress =
> Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM.
>
> I agree that what makes sense to me as a path forward is to deprecate =
> the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC =
> Multilayer OAM and SFC IOAM are identified by the respective values fo= r
> the NSH Next Protocol field (to be assigned by IANA), as well as so fa= r
> no OAM-specific meta data TLV has been yet defined.
>
> So we have I believe solid solution and path forward and I support > deprecating the O bit.
>
> Kind Regards
>
> Gyan
>
> On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Thank you, Jim and Joel, for guiding the SFC OAM wo= rk and pointing
>=C2=A0 =C2=A0 =C2=A0out the issue that must be addressed.
>
>=C2=A0 =C2=A0 =C2=A0I've reviewed our SFC OAM documents and draft-i= etf-sfc-nsh-tlv. As I
>=C2=A0 =C2=A0 =C2=A0understand these documents, the Active SFC OAM and = IOAM are
>=C2=A0 =C2=A0 =C2=A0identified by the respective values for the NSH Nex= t Protocol field
>=C2=A0 =C2=A0 =C2=A0(to be assigned by IANA). At the same time, so far = no OAM-specific
>=C2=A0 =C2=A0 =C2=A0meta data TLV has been defined. Thus, it appears th= at one way
>=C2=A0 =C2=A0 =C2=A0forward could be to not involve the O bit in the ac= tive SFC OAM or
>=C2=A0 =C2=A0 =C2=A0IOAM altogether. In other words, to deprecate the N= SH O bit.
>
>=C2=A0 =C2=A0 =C2=A0I greatly appreciate your comments on the proposal = to deprecate the
>=C2=A0 =C2=A0 =C2=A0NSH O bit.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Wed, Feb 2, 2022 at 10:36 AM James Guichard
>=C2=A0 =C2=A0 =C2=A0<james.n.guichard@futurewei.com
>=C2=A0 =C2=A0 =C2=A0<mailto:james.n.guichard@futurewei.com>> wrot= e:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi WG:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Having reviewed all of the OAM relate= d documents in our WG, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chairs would like to provide a few co= mments to hopefully
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generate discussion and forward progr= ess of this work:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01) The chairs have reviewed the O bit= definition in RFC 8300.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0That definition is at best open to in= terpretation and therefore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0incomplete.=C2=A0 For example, the cl= ear intention is only to mark
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets which are intended for SFC OA= M at the SFC service
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0layer.=C2=A0 But that is not what the= current text says.=C2=A0 There is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also, unfortunately, ambiguity as to = what constitutes an OAM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packet.=C2=A0 So it is reasonable for= documents to update 8300 to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clarify the exact applicability and a= ction for the O-bit.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) However, related to point 1), we c= an't have multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0documents updating the definition dif= ferently.=C2=A0 As such, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authors of the SFC iOAM draft and the= SFC multi-layer-oam draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need to come together and figure out = what the clarification is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for the definition of that bit. We do= not believe as chairs that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0either of these documents can move fo= rward from the WG until
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0such clarity has been reached. ____ >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03) Related to the SFC iOAM, we need a= clear definition of iOAM.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There seem to be differences between = the definitions in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0published RFCs, the usage (which is n= ot a definition) in the SFC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft, and the various ippm drafts.= =C2=A0 Any such definition will
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need to be vetted with the ippm worki= ng group.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Again, it would be good if members of= the working group beyond
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the two author teams spoke up about t= heir readings of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0documents, and their understandings o= f what we need.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yours,____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jim and Joel____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sfc mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sfc@ietf.org <mailto:sfc@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/= mailman/listinfo/sfc
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.= org/mailman/listinfo/sfc>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0sfc mailing list
>=C2=A0 =C2=A0 =C2=A0s= fc@ietf.org <mailto:sfc@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listin= fo/sfc
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/li= stinfo/sfc>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /Email = gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>//
> /
>
> /M 301 502-1347
>
> /
>
>
--

Gyan Mishra
Network Solutions Architect=C2=A0
M 301 502-1347


_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

--000000000000ee20df05d7fe4f24-- From nobody Tue Feb 15 04:51:08 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A393A08C7 for ; Tue, 15 Feb 2022 04:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 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_LOW=-0.7, 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 MZz4eu6Zim5u for ; Tue, 15 Feb 2022 04:51:01 -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 74D333A08C0 for ; Tue, 15 Feb 2022 04:51:01 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) (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 4Jygtq4MC3z2xhG; Tue, 15 Feb 2022 13:50:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1644929459; bh=AGDmSMcIw+t4HphMGWzze8063IJxRtMIuaWsmGtDg/o=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Lh+ue1sYj/LgSN51+n7C/2+/SAPF+kq6hR1ecdUPR/PltRiwdoE7LpVhCaXfSQtp6 756raoAX6ywqAD0fvEucnU7TGJe50j04orf+179nmY8SIk4c8Hvrmr6km9Xh16H0sA nvRLr7QqWK0fQunawdmzxP7zCcAnr7tB1Xqm59D2DfvvfLDocxsJu32LTMnRxRSFEq F2Claawj+nkpP3ZVqSEebCHOiwOpTJUPX4u+i+HkPxCrX6iF7edo2+qYZTRpk9MirR vn8Eh4lAA249OxsR4PmL8LuOHKUdI5Wte9BwWE4J3hs4NIEhj7J6jwFRsTJEa3WcWD yT+xEhZ7NtVnQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar01.francetelecom.fr (ESMTP service) with ESMTPS id 4Jygtq395pzBrN6; Tue, 15 Feb 2022 13:50:59 +0100 (CET) From: To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Future of SFC work Thread-Index: AQHYFHoL3GpaMlOQbkGg7jB59WPGjqyUqz+A Content-Class: Date: Tue, 15 Feb 2022 12:50:58 +0000 Message-ID: <19109_1644929459_620BA1B3_19109_4_2_787AE7BB302AE849A7480A190F8B933035494230@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> In-Reply-To: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-15T12:46:57Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=463e8ee7-19e6-4bf6-9d9b-ab4d29e58874; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Future of SFC work X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2022 12:51:07 -0000 Hi Joel/Jim, all,=20 The OAM work is an important piece of work that I hope can be finalized by = the WG.=20 I'm interested to contribute to the YANG part of the charter if there is en= ough energy in the WG. No rechartering is needed as this is already covered= by the current charter.=20 Cheers, Med > -----Message d'origine----- > De=A0: sfc De la part de Joel M. Halpern > Envoy=E9=A0: vendredi 28 janvier 2022 20:05 > =C0=A0: sfc@ietf.org > Objet=A0: [sfc] Future of SFC work >=20 > SFC Working Group: >=20 > As part of discussing the OAM elated drafts in SFC, the chairs have > been looking at the overall working group participation. We note that > very few people have spoken up about the issues being discussed. For > most recent drafts we have been working to advance, it has been a lot of > work to get enough comments to justify advancement (and folks could > argue that we did not succeed.) >=20 > We are considering various alternatives. We could, for example, > just close the working group. > One possibility is to recharter the working group to expand the scope. > There are two related questions that we would like to hear from the > working group about this. >=20 > 1) If we were to consider expanding the charter, what things would you > like to see included in it? >=20 > 2) If we do recharter will you work on the existing documents, and will > you engage on documents other than the one or two you personally would > like to see included? >=20 > Thank you, > Joel and Jim >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc ___________________________________________________________________________= ______________________________________________ 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. From nobody Tue Feb 15 19:08:49 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374B83A131B for ; Tue, 15 Feb 2022 19:08:47 -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_REMOTE_IMAGE=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 lIj78P7b8Udw for ; Tue, 15 Feb 2022 19:08:42 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0: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 0B2313A053E for ; Tue, 15 Feb 2022 19:08:41 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id u12so916294plf.13 for ; Tue, 15 Feb 2022 19:08: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=3INlAiqgk4/kUnYvNHl8t6EuNeBGJ1mBK4UnAi7BMjA=; b=fi/FtMGo3fxZAK1i89DLbjC15Rmp6yuRlzR6sJbzZMzVzR5j5rvDVut4lbScrBGuHL 2yl1pjxRAXuvXVHIktg7i3c0y14w6bSe/MaWroBBNrH+o1dD/HfXvXadC8V1yNNvAtQ6 h6PU2VGGLvz0JTD7pCKOllVeRYuMccGdpiLTypu3FP6t2FIYy6wUXw59bprEn1mIo+Tc ndIerCqVz530VuaLQ0Juu5a5fQzpCBPbnqp9E7Yndbvqc31sYJIPYPAbkuso5705MvrN ig7BHZRiL7E340GweaMLxyoXFMj4vTqalfHh1xJz5gzWgjmT3yP3MNSoA3xDjoePxKyS xRTQ== 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=3INlAiqgk4/kUnYvNHl8t6EuNeBGJ1mBK4UnAi7BMjA=; b=gHyX4jiX2oi1Grf1y8YYm1zLNJCMuOYeSm15npbc9iQDvtWrG05FGU8BtudTBkXLup eZIT/OabWcmTt7xMfKd7zDQ/0ufjg2RiNRpPPFrwdfOp075+ZqZTkwK8514v8bJUX69G sQKxQQoQ2IQIySwbTprE2dtwNLuGINa9/UnA8zqgmXiJuqkDUOYH2hHEhppvaYMSfvOQ 1oe7CNuNlgEBrlz32HbggcBmjlj2o+dRU5ClGNEzXHfEavDiU8OogAhUECbD6qM6nVXZ OZSNjsu0z8/ULNuexnT0QvC96kQ458JMiWeh+g0gOiKKsaFivCO/ub7VithxICzESxlt v4Lg== X-Gm-Message-State: AOAM5334F5XaXYR4Ajy8wZxaKO7Rge5gbuPRoSgwsWuojgNRNYwijTBT JB3TARaNvGwpEwK73/+mKSBJLlK4DY3jDkElqSrr6cOu X-Google-Smtp-Source: ABdhPJyo/0Dsh93xUx4GsNmDmNHXh0MQv5GikzgNcRsrG6Nrtzdb4f6HTWvsXuUHKIc024OHNPqoo4PmuzFdVka+jBk= X-Received: by 2002:a17:902:d88a:b0:14f:1aca:d956 with SMTP id b10-20020a170902d88a00b0014f1acad956mr598455plz.100.1644980917981; Tue, 15 Feb 2022 19:08:37 -0800 (PST) MIME-Version: 1.0 References: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> In-Reply-To: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> From: Gyan Mishra Date: Tue, 15 Feb 2022 22:08:26 -0500 Message-ID: To: "Joel M. Halpern" Cc: "sfc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000047703205d819f784" Archived-At: Subject: Re: [sfc] Future of SFC work X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 03:08:47 -0000 --00000000000047703205d819f784 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joel, Jim & all I would say that one measure of success of a WG is that when you do a google search, there are many scholarly articles related to SFC service plane benefits as well as vendor implementations that I know of personally with Cisco and Juniper and there maybe other vendors out there. I think the SFC WG has garnered overall interest in the technology industry wide and it=E2=80=99s importance of a service plane. Overall I would say hats off to the chairs and WG members and all the hard work as to the success!!! As far as commentary and involvement in drafts, that issue exists across the board as I am a member of every Routing Area WG, 54 WGs in total I would say the interest and involvement has been as well with other WGs related to personal drafts being progressed by individuals so I don=E2=80= =99t think it=E2=80=99s just an issue with SFC WG. My observation has been that whene= ver multiple vendors have competing solutions they want to get to WG adoption and progression, those are the hot ones that have tremendous interest. As well there are hot topics and the hot topics with drafts that have all the major vendors involvement get the most feedback and of course progress quickly. The key is garnering multi vendor interest and support to progress an idea which goes for SFC and any WG. In my mind NFV brought about the concept of the need for service chaining of VNF instances and now SFC has broadened the use case with NSH service plane beyond NFV with physical hardware endpoints and any virtualization model. I am in favor of expanding the scope of the WG to include in the charter any networking area that involves virtualization such as DC NVO encapsulation overlays such as VXLAN where I see Cisco and Juniper are providing their own on standardized methods service chaining that is SFC and SFC NSH independent where I think their can be tremendous benefits as well as when extending the fabric to the host being able to use SFC NSH service plane to link the SFF instances. I think as well maybe for TEAS network slicing with 5G virtualization the underlay network slice and now incorporating SFC NSH service plane into 5G UE services network slicing NSC slice controller. There maybe as well for OTN L1VPN and CCAMP WGs maybe a possibility of WG charter expansion into that arena SFC NSH possible considerations. Spring WG Segment Routing in my mind as it=E2=80=99s allows the ability for virtualization and abstraction of the underlay with SR-TE micro flow and macro flow path steering and it lends itself to be a critical component of TEAS network slicing, I believe that SFC NSH service plane can really take off in that area with a myriad of use cases across the board. I believe with the advent of SR really brings to light the criticality of SFC NSH service plane. I would be happy to work on all existing documents being progressed that I am involved as well as working on any I am not involved, as well as with the recharger expansion, any future development new work. Kind Regards Gyan On Fri, Jan 28, 2022 at 2:05 PM Joel M. Halpern wrote= : > SFC Working Group: > > As part of discussing the OAM elated drafts in SFC, the chairs have > been looking at the overall working group participation. We note that > very few people have spoken up about the issues being discussed. For > most recent drafts we have been working to advance, it has been a lot of > work to get enough comments to justify advancement (and folks could > argue that we did not succeed.) > > We are considering various alternatives. We could, for example, > just close the working group. > One possibility is to recharter the working group to expand the scope. > There are two related questions that we would like to hear from the > working group about this. > > 1) If we were to consider expanding the charter, what things would you > like to see included in it? > > 2) If we do recharter will you work on the existing documents, and will > you engage on documents other than the one or two you personally would > like to see included? > > Thank you, > Joel and Jim > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000047703205d819f784 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Joel, Jim & all

I would say that one measure of success of = a WG is that when you do a google search, there are many scholarly articles= related to SFC service plane benefits as well as vendor implementations th= at I know of personally with Cisco and Juniper and there maybe other vendor= s out there. =C2=A0

I th= ink the SFC WG has garnered overall interest in the technology industry wid= e and it=E2=80=99s importance of a service plane. =C2=A0

Overall I would say hats off to the chairs= and WG members and all the hard work =C2=A0as to the success!!!

As far as commentary and involveme= nt in drafts, that issue exists across the board as I am a member of every = Routing Area WG, 54 WGs in total I would say the interest and involvement h= as been as well with other WGs related to personal drafts being progressed = by individuals so I don=E2=80=99t think it=E2=80=99s just an issue with SFC= WG.=C2=A0 My observation has been that whenever multiple =C2=A0vendors hav= e competing solutions they want to get to WG adoption and progression, =C2= =A0those are the hot ones that have tremendous interest. =C2=A0 As well the= re are hot topics and the hot topics with drafts that have all the major ve= ndors involvement get the most feedback and of course progress quickly.=C2= =A0 The key is garnering multi vendor interest and support to progress an i= dea which goes for SFC and any WG.

In my mind NFV brought about the concept of the need for service= chaining of VNF instances and now SFC has broadened the use case with NSH = service plane beyond NFV with physical hardware endpoints and any virtualiz= ation model.

I am in fav= or of expanding the scope of the WG to include in the charter any networkin= g area that involves virtualization such as DC NVO encapsulation overlays s= uch as VXLAN where I see Cisco and Juniper are providing their own on stand= ardized methods service chaining that is SFC and SFC NSH independent where = I think their can be tremendous benefits as well as when extending the fabr= ic to the host being able to use SFC NSH service plane to link the SFF inst= ances. =C2=A0 I think as well maybe for TEAS network slicing with 5G virtua= lization the underlay network slice and now incorporating SFC NSH service p= lane into 5G UE services network slicing NSC slice controller.=C2=A0 There = =C2=A0maybe as well for OTN L1VPN and CCAMP WGs maybe a possibility of WG c= harter expansion into that arena SFC NSH possible considerations.

Spring WG Segment Routing in my m= ind as it=E2=80=99s allows the ability for virtualization and abstraction o= f the underlay with SR-TE micro flow and macro flow path steering and it le= nds itself to =C2=A0be a critical component of TEAS network slicing, I beli= eve that SFC NSH service plane can really take off in that area with a myri= ad of use cases across the board.=C2=A0 I believe with the advent of SR rea= lly brings to light the criticality of SFC NSH service plane.


I would b= e happy to work on all existing documents being progressed that I am involv= ed as well as working on any I am not involved, as well as with the recharg= er expansion, any future development new work.

<= /div>
Kind Regards=C2=A0

=
Gyan

On Fri, Jan 28, 2022 a= t 2:05 PM Joel M. Halpern <jmh@jo= elhalpern.com> wrote:
SFC Working Group:
=C2=A0 =C2=A0 =C2=A0As part of discussing the OAM elated drafts in SFC, the= chairs have
been looking at the overall working group participation.=C2=A0 We note that=
very few people have spoken up about the issues being discussed.=C2=A0 For =
most recent drafts we have been working to advance, it has been a lot of work to get enough comments to justify advancement (and folks could
argue that we did not succeed.)

=C2=A0 =C2=A0 =C2=A0We are considering various alternatives.=C2=A0 We could= , for example,
just close the working group.
One possibility is to recharter the working group to expand the scope.
There are two related questions that we would like to hear from the
working group about this.

1) If we were to consider expanding the charter, what things would you
like to see included in it?

2) If we do recharter will you work on the existing documents, and will you engage on documents other than the one or two you personally would
like to see included?

Thank you,
Joel and Jim

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--
--00000000000047703205d819f784-- From nobody Wed Feb 16 01:58:20 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF603A0D30 for ; Wed, 16 Feb 2022 01:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 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, RCVD_IN_VALIDITY_RPBL=1.31, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, UNPARSEABLE_RELAY=0.001] autolearn=no 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 txi9uPpHh7Ko for ; Wed, 16 Feb 2022 01:58:12 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 B7F493A08C2 for ; Wed, 16 Feb 2022 01:58:11 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) (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 opfedar20.francetelecom.fr (ESMTP service) with ESMTPS id 4JzD0y1mTsz8srq; Wed, 16 Feb 2022 10:58:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645005490; bh=FSEH8z+I5uXNT+I4tPlpGevAZF3dsGZMLeDWnTwi0L0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=K88AMk956u5qUeewK5d4wrl9zjsr7/2umZ0I04LJoKgfJlXEwAYUrsnogqkEn6lL5 hRGBSOsRrpFUZgGVt+Il9XahY2WAoPa64Q1EjWrErg5K0y62vERaGIxXnMPu6OkXTy NBTSzh5yr1LCPr63FTM0Me6/Co4fzlRabyJ+EDwA2ElnFj9aej1AyYaMt1JMMzO4gv B8Kv51ahWWUaAVzGXaXOpxZBDzdRR+hvbWwZR8Wpn15TuoD4jk2u+VUJDECUPfEu0v 3BRWcGPhvVX2Nrd2btPAMu3oUqq+f5X2nf1qkXP5VCOJQPtsk2xzJMqFyu8GsRWNFX B3KyqKUV7P5mQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar02.francetelecom.fr (ESMTP service) with ESMTPS id 4JzD0y0HGJzCqkv; Wed, 16 Feb 2022 10:58:10 +0100 (CET) From: To: James Guichard , "Carlos Pignataro (cpignata)" , Gyan Mishra CC: Greg Mirsky , "sfc@ietf.org" Thread-Topic: [sfc] Progression of OAM work in the SFC WG Thread-Index: AdgYYtG+l/ju054uSCa0IEDodR5p4AAI1AYAAgogAwAADsqJgAAEeXQAAAD7PAAAFinEAAAVIwJwAFqOIOA= Content-Class: Date: Wed, 16 Feb 2022 09:58:08 +0000 Message-ID: <9274_1645005490_620CCAB2_9274_472_1_787AE7BB302AE849A7480A190F8B933035494AA7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.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_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-16T09:24:55Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=2ad6f3d1-ca61-4561-be90-fcbd4269ad06; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933035494AA7OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 09:58:17 -0000 --_000_787AE7BB302AE849A7480A190F8B933035494AA7OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmltLCBhbGwsDQoNCldlIGhhZCBtYW55IGRpc2N1c3Npb25zIGluIHRoZSBwYXN0IGFib3V0 IHRoZSBPLWJpdCAoaW5jbHVkaW5nIGEgcHJvcG9zYWwgdG8gdGFnIHRoZSBmbGFnIGFzIHJlc2Vy dmVkIGFuZCBkZWZpbmUgaXQgd2hlbiBuZWVkZWQgWzFdLCBkZXByZWNhdGUgdGhlIE8tYml0IFsy XSkgYmVmb3JlIGZpbmFsbHkgYWdyZWVpbmcgb24gdGhlIHRleHQgd2UgaGF2ZSBpbiA4MzAwLg0K DQpJIGRvbuKAmXQgdGhpbmsgd2UgaGF2ZSBuZXcgYXJndW1lbnRzIHRvIGRlcHJlY2F0ZSB0aGUg Ty1iaXQuIEhvd2V2ZXIsIGEgY2xhcmlmaWNhdGlvbiBvZiBpbnRlbmRlZCBtZWFuaW5nIG9mIOKA nE9BTSBwYWNrZXTigJ0gaXMgd29ydGggdG8gaGF2ZS4gSeKAmW0gaGFwcHkgdG8gd29yayB3aXRo IG90aGVyIHZvbHVudGVlcnMgb24gYSBzaG9ydCBkb2N1bWVudCB0aGF0IGZpeGVzIHRoYXQuDQoN CkNoZWVycywNCk1lZA0KDQpbMV0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21z Zy9zZmMvZjRSYllsVUtLSG01M1UxZWFDdmpoTXlwTGMwLw0KWzJdIGh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2ZjL2x5VGZvamhjN2lpc3ByeUc0Ylg2NkI3RmNpNC8NCg0K RGUgOiBzZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnPiBEZSBsYSBwYXJ0IGRlIEphbWVzIEd1aWNo YXJkDQpFbnZvecOpIDogbHVuZGkgMTQgZsOpdnJpZXIgMjAyMiAxNToyOA0Kw4AgOiBDYXJsb3Mg UGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3Jn PjsgR3lhbiBNaXNocmEgPGhheWFidXNhZ3NtQGdtYWlsLmNvbT4NCkNjIDogR3JlZyBNaXJza3kg PGdyZWdpbWlyc2t5QGdtYWlsLmNvbT47IHNmY0BpZXRmLm9yZw0KT2JqZXQgOiBSZTogW3NmY10g UHJvZ3Jlc3Npb24gb2YgT0FNIHdvcmsgaW4gdGhlIFNGQyBXRw0KDQpIaSBDYXJsb3MsDQoNClNv bWUgcmVzcG9uc2VzIGluLWxpbmUg4oCmDQoNCkZyb206IHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKQ0KU2VudDogU3VuZGF5LCBGZWJydWFyeSAxMywgMjAyMiAxMTowNyBQ TQ0KVG86IEd5YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFpbC5jb208bWFpbHRvOmhheWFidXNh Z3NtQGdtYWlsLmNvbT4+DQpDYzogR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxt YWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIFByb2dyZXNzaW9uIG9mIE9BTSB3b3JrIGluIHRo ZSBTRkMgV0cNCg0KUmVwbHlpbmcgdG8gdGhpcyBzcGVjaWZpYyBlbWFpbCBpbiB0aGUgdGhyZWFk LCBvbmx5IGJlY2F1c2UgaXQgaXMgdGhlIGxhdGVzdCBvbmUgYXQgdGhpcyBwb2ludCBpbiB0aW1l LCBidXQgYnVuZGxpbmcgY29tbWVudHMgZnJvbSB2YXJpb3VzIHBsYWNlcyBvbiB0aGUgdGhyZWFk LiBQbGVhc2UgZmluZCBzb21lIGZvbGxvdy11cCBjb21tZW50cyBhbmQgcXVlc3Rpb25zIG1hcmtl ZCDigJxDTVDigJ0sIGluZGljYXRpbmcgdGhlIOKAnEZyb23igJ0sIGFuZCBvcmdhbml6ZWQgY2hy b25vbG9naWNhbGx5Og0KDQpKYW1lcyBOIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVy ZXdlaS5jb208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4+Og0KDQoxKSBU aGUgY2hhaXJzIGhhdmUgcmV2aWV3ZWQgdGhlIE8gYml0IGRlZmluaXRpb24gaW4gUkZDIDgzMDAu ICBUaGF0IGRlZmluaXRpb24gaXMgYXQgYmVzdCBvcGVuIHRvIGludGVycHJldGF0aW9uIGFuZCB0 aGVyZWZvcmUgaW5jb21wbGV0ZS4gIEZvciBleGFtcGxlLCB0aGUgY2xlYXIgaW50ZW50aW9uIGlz IG9ubHkgdG8gbWFyayBwYWNrZXRzIHdoaWNoIGFyZSBpbnRlbmRlZCBmb3IgU0ZDIE9BTSBhdCB0 aGUgU0ZDIHNlcnZpY2UgbGF5ZXIuICBCdXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgY3VycmVudCB0 ZXh0IHNheXMuICBUaGVyZSBpcyBhbHNvLCB1bmZvcnR1bmF0ZWx5LCBhbWJpZ3VpdHkgYXMgdG8g d2hhdCBjb25zdGl0dXRlcyBhbiBPQU0gcGFja2V0LiAgU28gaXQgaXMgcmVhc29uYWJsZSBmb3Ig ZG9jdW1lbnRzIHRvIHVwZGF0ZSA4MzAwIHRvIGNsYXJpZnkgdGhlIGV4YWN0IGFwcGxpY2FiaWxp dHkgYW5kIGFjdGlvbiBmb3IgdGhlIE8tYml0Lg0KDQpDTVA6IEl0IGlzIHVuY2xlYXIgdG8gbWUg d2hhdCBleGFjdCBpc3N1ZXMgdGhlIGNoYWlycyBhcmUgY2FsbGluZyBvdXQuIFRoZXJlIGFyZSB0 d28gaXNzdWVzIG1lbnRpb25lZDoNCkNNUDogMS4gIkJ1dCB0aGF0IGlzIG5vdCB3aGF0IHRoZSBj dXJyZW50IHRleHQgc2F5cy7igJ0g4oCUPiB3aGF0IGRvZXMgdGhlIHRleHQgc2F5IHByZWNpc2Vs eT8gIENhbiB5b3UgcG9pbnQgdG8gdGhlIHNwZWNpZmljIFJGQyA4MzAwIHRleHQgdGhhdCBpcyBi ZWxpZXZlZCB0byBiZSBpbmNvbXBsZXRlLCBhbmQgYSBkZXRhaWxlZCB1c2UgY2FzZSB0aGF0IHNo b3djYXNlcyB0aGUgcG90ZW50aWFsIGlzc3VlPyBBbiBleHRyYXBvbGF0ZWQgY291bnRlci1leGFt cGxlIGp1c3QgdG8gbWFrZSBhIHBvaW50OiB0aGUgdGV4dCBkb2VzIG5vdCAgc2F5IHdoYXQgZGF5 cyBvZiB0aGUgd2VlayBPQU0gcGFja2V0cyBjYW4gYmUgbWFya2VkLCB5ZXQgdGhlcmXigJlzIGFu IGV4cGVjdGF0aW9uIHRoYXQgdGhleSB3aWxsIHdvcmsgTW9uZGF5cyBhbmQgU2F0dXJkYXlzIGFs bCB0aGUgc2FtZSDigJQgZXZlbiBob2xpZGF5cy4NCg0KDQpKaW0+IEN1cnJlbnRseSBSRkM4MzAw IHNheXMg4oCcVGhlIE8gYml0IE1VU1QgYmUgc2V0IGZvciBPQU0gcGFja2V0cyBhbmQgTVVTVCBO T1QgYmUgc2V0IGZvciBub24tT0FNIHBhY2tldHPigJ0uIFRoZSBmaXJzdCBpc3N1ZSBpcyBkb2Vz IHRoaXMgbWVhbiB0aGUgTyBiaXQgc2hvdWxkIGJlIHNldCBmb3IgQUxMIE9BTSBwYWNrZXRzIHJl Z2FyZGxlc3Mgb2Ygd2hldGhlciB0aGV5IGJlbG9uZyB0byB0aGUgTlNIIHNlcnZpY2UgcGxhbmU/ IE9yIHNob3VsZCBpdCBvbmx5IGJlIHNldCBmb3IgU0ZDIE9BTSBwYWNrZXRzPyBBbmQgd2hhdCBl eGFjdGx5IGlzIGFuIFNGQyBPQU0gcGFja2V0IGFzIHRoZSBlYXJsaWVyIHJlZmVyZW5jZSB0byBS RkM2MjkxIGlzIGp1c3QgYSBnZW5lcmF0ZSBzZXQgb2YgZ3VpZGVsaW5lcyBmb3IgdGhlIHVzZSBv ZiB0aGUgdGVybSBPQU0uIFRoZSBzZWNvbmQgaXNzdWUgaXMgdGhhdCBpZiB0aGF0IE8gYml0IGlz IHNldCB0aGVuIEdyZWfigJlzIGRvY3VtZW50IGlzIGluIGNvbmZsaWN0IHdpdGggSU9BTSBhcyBi b3RoIHVzZSB0aGUgbmV4dCBwcm90b2NvbCBmaWVsZCBhbmQgZXZlbiBpZiB0aGUgTyBiaXQgaXMg c2V0IGl0IGlzIG1lYW5pbmdsZXNzIGFzIHRoZSBwcm90b2NvbCBhY3Rpb24gaXMgYmFzZWQgc29s ZWx5IG9uIHRoZSBzZXR0aW5nIG9mIHRoZSBuZXh0IHByb3RvY29sIGZpZWxkLiBTbyBpbiB0aGlz IGNhc2UgY2FuIHRoZWlyIHNvbHV0aW9ucyBzaW1wbHkgaWdub3JlIHdoYXQgUkZDIDgzMDAgc2F5 cyBlLmcuIE1VU1Qgc2V0IHRoZSBPIGJpdD8gT3IgaWYgdGhleSBzZXQgdGhlIE8gYml0IHRvIGJl IGNvbmZvcm1hbnQgdG8gd2hhdCBSRkMgODMwMCBzYXlzIHRoZW4gZG8gd2UgbmVlZCBjbGVhcmVy IHJ1bGVzIHN0YXRpbmcgd2hhdCB0byBkbyBpZiB0aGUgbmV4dCBwcm90b2NvbCBmaWVsZCBpcyBO T1QgYW4gT0FNIG5leHQgcHJvdG9jb2wgc3VjaCBhcyB0aGUgY29udGV4dCBoZWFkZXJzIHNob3Vs ZCB0aGVuIGJlIGV4YW1pbmVkPw0KDQoNCkNNUDogMi4gV2hhdCBzcGVjaWZpY2FsbHkgaXMgdGhl IGFtYmlndWl0eSB3aXRoIHdoYXQgYW4gT0FNIHBhY2tldCBpcz8gUGxlYXNlIGdyZXAgdGhlIFJG QyBzZXJpZXMgZm9yIOKAnG9hbSBwYWNrZXTigJ0sIGl0IGlzIG5vdCBhIG5ldyB0ZXJtLg0KQ01Q OiBOZXQtbmV0LCBPLWJpdD0xLCBPQU0gcGFja2V0Lg0KDQpKaW0+IGFtYmlndWl0eSBpcyB3aGV0 aGVyIGl0IGlzIG9ubHkgU0ZDIE9BTSBwYWNrZXRzIHRoYXQgYXJlIGJlaW5nIGRpc2N1c3NlZCBv ciBBTEwgT0FNIHBhY2tldHMgbm90aGluZyB0aGF0IHNvbWUgbWlnaHQgYmUgYXQgdGhlIHNlcnZp Y2UgbGF5ZXIgYW5kIHNvbWUgbWlnaHQgbm90Lg0KDQpKaW0NCg0KMikgSG93ZXZlciwgcmVsYXRl ZCB0byBwb2ludCAxKSwgd2UgY2FuJ3QgaGF2ZSBtdWx0aXBsZSBkb2N1bWVudHMgdXBkYXRpbmcg dGhlIGRlZmluaXRpb24gZGlmZmVyZW50bHkuICBBcyBzdWNoLCB0aGUgYXV0aG9ycyBvZiB0aGUg U0ZDIGlPQU0gZHJhZnQgYW5kIHRoZSBTRkMgbXVsdGktbGF5ZXItb2FtIGRyYWZ0IG5lZWQgdG8g Y29tZSB0b2dldGhlciBhbmQgZmlndXJlIG91dCB3aGF0IHRoZSBjbGFyaWZpY2F0aW9uIGlzIGZv ciB0aGUgZGVmaW5pdGlvbiBvZiB0aGF0IGJpdC4gV2UgZG8gbm90IGJlbGlldmUgYXMgY2hhaXJz IHRoYXQgZWl0aGVyIG9mIHRoZXNlIGRvY3VtZW50cyBjYW4gbW92ZSBmb3J3YXJkIGZyb20gdGhl IFdHIHVudGlsIHN1Y2ggY2xhcml0eSBoYXMgYmVlbiByZWFjaGVkLg0KDQpDTVA6IElmIHRoZXJl IGlzIHN0aWxsIGJlbGlldmVkIHRvIGJlIGFuIGFtYmlndWl0eSBvciBhIGNsZWFyIG9wcG9ydHVu aXR5IGZvciBpbXByb3ZpbmcgdGhlIGRlZmluaXRpb24sIEkgYWdyZWUgd2l0aCBjb25zb2xpZGF0 aW5nIHRoYXQgdXBkYXRlLiBJIGhhZCBzdWdnZXN0ZWQgYmVmb3JlIHRoYXQgaWYgc3VjaCBuZXcg dGV4dCBvciByZWFsIGNsYXJpZmljYXRpb24gaXMgYWdyZWVkLCBhIHNlcGFyYXRlIGRvY3VtZW50 IHRoYXQgb25seSBtYWtlcyB0aGF0IE8tYml0IGNsYXJpZmljYXRpb24gaXMgdGhlIG1vc3QgY2xl YXIgYW5kIGNsZWFuIHdheSB0byBnby4gVGhhdCBkb2Mgc2hvdWxkIGJlIGEgb25lLXBhZ2VyIG9y IGxlc3MuIEnigJlkIGJlIGhhcHB5IHRvIGNvbnRyaWJ1dGUgdG8gdGhhdCBtaW5pbWFsIGRvYywg aWYgaXQgaXMgc2hvd24gdG8gYmUgbmVlZGVkLg0KDQpDTVA6IEZvciBjb21wbGV0ZW5lc3MgYWxz bywgdGhlICJTRkMgbXVsdGktbGF5ZXItb2Ft4oCdIGRvY3VtZW50IGhhcyBtYW55IG91dHN0YW5k aW5nIGlzc3VlcyBiZXNpZGVzIHRoZSBPLWJpdC4NCg0KR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5 QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4NCg0KSSd2ZSByZXZpZXdl ZCBvdXIgU0ZDIE9BTSBkb2N1bWVudHMgYW5kIGRyYWZ0LWlldGYtc2ZjLW5zaC10bHYuIEFzIEkg dW5kZXJzdGFuZCB0aGVzZSBkb2N1bWVudHMsIHRoZSBBY3RpdmUgU0ZDIE9BTSBhbmQgSU9BTSBh cmUgaWRlbnRpZmllZCBieSB0aGUgcmVzcGVjdGl2ZSB2YWx1ZXMgZm9yIHRoZSBOU0ggTmV4dCBQ cm90b2NvbCBmaWVsZCAodG8gYmUgYXNzaWduZWQgYnkgSUFOQSkuDQoNCkNNUDogVGhlcmUgaXMg YSBtYWpvciBpc3N1ZSB3aXRoIHRoZSBzZW50ZW5jZSBhYm92ZS4gQWN0aXZlIFNGQyBPQU0gKGFz IGEgY2F0ZWdvcnkpLCBhcyBwZXIgUkZDIDgzMDAsIG5lZWRzIHRvIGJlIGlkZW50aWZpZWQgYnkg c2V0dGluZyB0aGUgTy1iaXQuIE5vIHdheSBhcm91bmQgdGhhdCBiYXNlZCBvbiBSRkMgODMwMC4g SG93ZXZlciwgdGhlIHRleHQgInRoZSBBY3RpdmUgU0ZDIE9BTeKAnSBjcmVhdGVzIGNvbmZ1c2lv biBzaW5jZSBpdCByZWZlciB0byBhIHNwZWNpZmljIE9BTSBwcm90b2NvbCB3aGljaCBoYXMgdGhl IHNhbWUgbmFtZSBhcyBhIHRoZSBjYXRlZ29yeSBhcyB3ZWxsLiBUaGF0IG5hbWUgY29sbGlzaW9u IGlzIHF1aXRlIHVuZm9ydHVuYXRlIGluIG15IG9waW5pb24uDQoNCkF0IHRoZSBzYW1lIHRpbWUs IHNvIGZhciBubyBPQU0tc3BlY2lmaWMgbWV0YSBkYXRhIFRMViBoYXMgYmVlbiBkZWZpbmVkLiBU aHVzLCBpdCBhcHBlYXJzIHRoYXQgb25lIHdheSBmb3J3YXJkIGNvdWxkIGJlIHRvIG5vdCBpbnZv bHZlIHRoZSBPIGJpdCBpbiB0aGUgYWN0aXZlIFNGQyBPQU0gb3IgSU9BTSBhbHRvZ2V0aGVyLiBJ biBvdGhlciB3b3JkcywgdG8gZGVwcmVjYXRlIHRoZSBOU0ggTyBiaXQuDQoNCkNNUDogUkZDIDg5 MjQgYWxyZWFkeSBpbmNsdWRlcyBJQ01QIGFuZCBCRkQgYXMgZXhhbXBsZSBTRkMgQWN0aW9uIE9B TSBwcm90b2NvbHMuIFRob3NlIGNhbiBiZSBlbmNhcHN1bGF0ZWQgaW4gSVAsIGluIHdoaWNoIHRo ZSBOZXh0LVByb3RvY29sIGluZGljYXRlcyBJUCDigJQgYW5kIChhcyBwZXIgUkZDIDgzMDApIHRo ZSBPLWJpdCBpcyBzZXQgdG8gaW5kaWNhdGUgYW4gT0FNIHBhY2tldC4NCkNNUDogVGhlIHByb3Bv c2FsIG9mIGRlcHJlY2F0aW5nIHRoZSBPLWJpdCBicmVha3MgdGhvc2UgU0ZDIE9BTSBwcm90b2Nv bHMgYWxyZWFkeSBpbmNsdWRlZCBpbiBhbiBSRkMuDQpDTVA6IFRoYXQgcHJvcG9zYWwgb2YgZGVw cmVjYXRpbmcgdGhlIE8tYml0IGFsc28gYnJlYWtzIFNlY3Rpb24gNC4xIG9mIElPQU0uDQpDTVA6 IFRoaXMgZXhwaXJlZCBJLUQgeWV0IGltcGxlbWVudGVkIGluIG9wZW4gc291cmNlIHVzZXMgdGhl IE8tYml0OiBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXBlbm5vLXNmYy10 cmFjZS0wMy50eHQ8aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGYXJjaGl2ZSUyRmlkJTJGZHJhZnQt cGVubm8tc2ZjLXRyYWNlLTAzLnR4dCZkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQw ZnV0dXJld2VpLmNvbSU3QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5MDhkOWVmNmY3ZmY1JTdDMGZlZThm ZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNDA4NDQ4MTE5NjI2NCU3 Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16 SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJnNkYXRhPXolMkJrRmdEcUgy NHB5WTQ3d0gwSk9KZ2VvMm1hTGxDZ2ZGU3AzTVo1S3paYyUzRCZyZXNlcnZlZD0wPg0KDQoNCkd5 YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFpbC5jb208bWFpbHRvOmhheWFidXNhZ3NtQGdtYWls LmNvbT4+DQoNCkkgYWdyZWUgdGhhdCB3aGF0IG1ha2VzIHNlbnNlIHRvIG1lIGFzIGEgcGF0aCBm b3J3YXJkIGlzIHRvIGRlcHJlY2F0ZSB0aGUgTyBiaXQgYW5kIG5vdCB1c2UgaW4gU0ZDIE11bHRp bGF5ZXIgT0FNIGFuZCBTRkMgSU9BTSwgYXMgYm90aCBTRkMgTXVsdGlsYXllciBPQU0gYW5kIFNG QyBJT0FNIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSByZXNwZWN0aXZlIHZhbHVlcyBmb3IgdGhlIE5T SCBOZXh0IFByb3RvY29sIGZpZWxkICh0byBiZSBhc3NpZ25lZCBieSBJQU5BKSwgYXMgd2VsbCBh cyBzbyBmYXIgbm8gT0FNLXNwZWNpZmljIG1ldGEgZGF0YSBUTFYgaGFzIGJlZW4geWV0IGRlZmlu ZWQuDQoNCkNNUDogV2hhdCBpcyB0aGUg4oCcU0ZDIE11bHRpbGF5ZXIgT0FN4oCdPw0KQ01QOiBU aGUgTy1iaXQgKHJlYWRpbmcgUkZDIDgzMDApIGRvZXMgbm90IGluZGljYXRlIGlmIHRoZXJlIGlz IE9BTSBNZXRhZGF0YS4gSXQgaW5kaWNhdGVzIGFuIE9BTSBwYWNrZXQuDQoNCg0KIkpvZWwgTS4g SGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ Pg0KDQpBcyBmYXIgYXMgSSBjYW4gdGVsbCwgaWYgd2UgZGVwcmVjYXRlIHRoZSBPLWJpdCBhbmQg cmVseSBvbiB0aGUgbmV4dCBwcm90b2NvbCBmaWVsZCwgd2UgYXJlIHNheWluZyB0aGF0IGluIHBy YWN0aWNlIChub3QgYnkgcnVsZSkgTlNIIG1ldGFkYXRhIGNhbiBub3QgYmUgdXNlZCBmb3IgT0FN LiAgVGhhdCdzIGZpbmUgd2l0aCBtZSBhcyBsb25nIGFzIHdlIGFncmVlIG9uIHRoYXQuDQoNCkNN UDogSSBkbyBub3QgZnVsbHkgZm9sbG93IHRoaXMuIENhbiB5b3UgZXhwbGFpbiB0aGUgcmVsYXRp b25zaGlwIG9mIHRoZSBPLWJpdCB3aXRoIE1ldGFkYXRhPw0KQ01QOiBIZXJl4oCZcyBhbiBleGFt cGxlOiBSRkMgODkyNCBzaG93cyBJQ01QIGFzIEFjdGl2ZSBPQU0uIFRoZSBTRkMgbmV4dCBwcm90 b2NvbCBpcyBJUCwgdGhlIElQIG5leHQgcHJvdG9jb2wgaXMgSUNNUCwgdGhlIE8tYml0IG5lZWRz IHRvIGJlIHNldC4NCg0KQ01QOiBDb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50LCBpbmRl cGVuZGVudCBzdWJtaXNzaW9uIGFuZCBpbiB0aGUgUkZDIFB1YmxpY2F0aW9uIHF1ZXVlIGFscmVh ZHk6DQpDTVA6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW15bWItc2Zj LW5zaC1hbGxvY2F0aW9uLXRpbWVzdGFtcC88aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZkcmFmdC1teW1iLXNmYy1uc2gtYWxsb2NhdGlvbi10aW1lc3RhbXAlMkYmZGF0YT0w NCU3QzAxJTdDamFtZXMubi5ndWljaGFyZCU0MGZ1dHVyZXdlaS5jb20lN0M5ZGIyYWIwYTkzODI0 NjEzOTdmOTA4ZDllZjZmN2ZmNSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdD MSU3QzElN0M2Mzc4MDQwODQ0ODExOTYyNjQlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lq b2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4w JTNEJTdDMzAwMCZzZGF0YT1CMCUyRlFQUVRiUXJ1VEt6cVhmaW42WmZFWXlhdUEyS1pocTBtOFlL U0x0TEUlM0QmcmVzZXJ2ZWQ9MD4NCkNNUDogSXMgYSBUaW1lc3RhbXAgaW4gTWV0YWRhdGEgYW4g T0FNIGVsZW1lbnQ/DQoNCkNNUDogQ29uc2lkZXIgdGhpcyBwcm9wb3NhbCBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktc2ZjLXBtYW1tLzxodHRwczovL25hbTEx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRh dHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LW1pcnNreS1zZmMtcG1hbW0lMkYmZGF0YT0w NCU3QzAxJTdDamFtZXMubi5ndWljaGFyZCU0MGZ1dHVyZXdlaS5jb20lN0M5ZGIyYWIwYTkzODI0 NjEzOTdmOTA4ZDllZjZmN2ZmNSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdD MSU3QzElN0M2Mzc4MDQwODQ0ODExOTYyNjQlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lq b2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4w JTNEJTdDMzAwMCZzZGF0YT1KaWlrR2dYRzM1JTJGVzUxOGRpc3VJeEF2YVdhNUZ1cXZrS2NHJTJG YXlnNlI0OCUzRCZyZXNlcnZlZD0wPg0KQ01QOiBXaGVyZSB0aGUgYmFzZSBoZWFkZXIgYm9ycm93 cyBhIGJpdCBmb3IgYW4gT0FNIGZ1bmN0aW9uLg0KDQpDTVA6IE5laXRoZXIgb2YgdGhvc2UgaGF2 ZSBhbnkgaW1wYWN0IG9uIHRoZSBPLWJpdC4NCg0KDQpHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lA Z21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+Pg0KDQpJIGFncmVlIHRoYXQs IGFzIHdlIGZpbmQgU0ZDIE5TSCBub3csIG5vIE9BTSBtZXRhZGF0YSBoYXMgYmVlbiBkZWZpbmVk LiBJdCBhcHBlYXJzIHRvIG1lIHRoYXQgZGVwcmVjYXRpbmcgdGhlIE8gYml0IGRvZXMgbm90IGFm ZmVjdCBhbnkgb2YgdGhlIGFscmVhZHkgZGVmaW5lZCBtZWNoYW5pc21zIGluIHRoZSBTRkMgTlNI Lg0KDQpDTVA6IEl0IGFjdHVhbGx5IGRvZXMsIHNlZSBteSBleGFtcGxlIGFib3ZlLg0KDQpJIHRo aW5rIHRoYXQgaWYgYSBuZXcsIGZvciBleGFtcGxlLCBNRCBUeXBlID0gMiBUTFYgdGhhdCBpcyB1 c2VkIGZvciBhbnkgT0FNIGZ1bmN0aW9uYWxpdHkgdG8gYmUgcHJvcG9zZWQgaW4gdGhlIGZ1dHVy ZSwgZGVwcmVjYXRlZCB0aGUgTyBiaXQgd291bGQgbm90IHByZXZlbnQgdXNpbmcgc3VjaCBOU0gg VExWLg0KDQpDTVA6IEkgYWdyZWUgd2l0aCB0aGlzIOKAlCBiZWNhdXNlIHRoZXJlIGlzIG5vIGNv cnJlbGF0aW9uIGJldHdlZW4gTUQgVHlwZSBmaWVsZCBhbmQgTy1iaXQgYXMgZGVmaW5lZC4NCg0K QmVzdCwNCg0KQ2FybG9zLg0KDQoNCg0KMi8xMy8yMiDljYjlvowxMjozMuOAgUd5YW4gTWlzaHJh IDxoYXlhYnVzYWdzbUBnbWFpbC5jb208bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbT4+44Gu 44Oh44O844OrOg0KDQpIaSBKb2VsDQoNCkkgYW0gaW4gYWdyZWVtZW50IGFzIHdlbGwgd2l0aCB3 aGF0IHlvdSBoYXZlIHN0YXRlZCB0aGF0IG9uY2UgdGhlIE8gYml0IGlzIGRlcHJlY2F0ZWQgdGhh dCBOU0ggbWV0YWRhdGEgY2Fubm90IGJlIHVzZWQgZm9yIE9BTSBhbmQgdGhhdCB3ZSB3b3VsZCBo YXZlIHRvIG5vdyBmcm9tIHRoYXQgcG9pbnQgZm9yd2FyZCByZWx5IG9uIHRoZSBuZXh0IHByb3Rv Y29sIGZpZWxkIGFzIHdlIHdpbGwgYmUgZG9pbmcgZm9yIFNGQyBNdWx0aWxheWVyIGFuZCBTRkMg SU9BTSBkcmFmdHMgYXMgd2VsbCBhcyB3aWxsIGhhdmUgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0 aCBhbnkgYWxyZWFkeSBleGlzdGluZyBkZWZpbmVkIG1lY2hhbmlzbXMgaW4gU0ZDIE5TSC4NCg0K SSBkb27igJl0IHNlZSBhbnkgaXNzdWVzIG9yIGltcGFjdCB3aXRoIG1vdmluZyBmb3J3YXJkLg0K DQpLaW5kIFJlZ2FyZHMNCg0KR3lhbg0KDQpPbiBTdW4sIEZlYiAxMywgMjAyMiBhdCAxMjowNCBQ TSBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBn bWFpbC5jb20+PiB3cm90ZToNCkhpIEpvZWwsDQpJIGFncmVlIHRoYXQsIGFzIHdlIGZpbmQgU0ZD IE5TSCBub3csIG5vIE9BTSBtZXRhZGF0YSBoYXMgYmVlbiBkZWZpbmVkLiBJdCBhcHBlYXJzIHRv IG1lIHRoYXQgZGVwcmVjYXRpbmcgdGhlIE8gYml0IGRvZXMgbm90IGFmZmVjdCBhbnkgb2YgdGhl IGFscmVhZHkgZGVmaW5lZCBtZWNoYW5pc21zIGluIHRoZSBTRkMgTlNILiBJIHRoaW5rIHRoYXQg aWYgYSBuZXcsIGZvciBleGFtcGxlLCBNRCBUeXBlID0gMiBUTFYgdGhhdCBpcyB1c2VkIGZvciBh bnkgT0FNIGZ1bmN0aW9uYWxpdHkgdG8gYmUgcHJvcG9zZWQgaW4gdGhlIGZ1dHVyZSwgZGVwcmVj YXRlZCB0aGUgTyBiaXQgd291bGQgbm90IHByZXZlbnQgdXNpbmcgc3VjaCBOU0ggVExWLg0KV2hh dCBkbyB5b3UgdGhpbms/DQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFN1biwgRmViIDEzLCAyMDIy IGF0IDY6NTUgQU0gSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tPj4gd3JvdGU6DQpUaGVyZSBpcyBhbiBpbXBsaWNhdGlvbiBvZiBk ZXByZWNhdGluZyB0aGUgTy1iaXQgdGhhdCBJIHdvdWxkIGxpa2UgdG8NCmhlYXIgZnJvbSBtb3Jl IFdHIHBhcnRpY2lwYW50cyBhYm91dC4NCg0KQXMgZmFyIGFzIEkgY2FuIHRlbGwsIGlmIHdlIGRl cHJlY2F0ZSB0aGUgTy1iaXQgYW5kIHJlbHkgb24gdGhlIG5leHQNCnByb3RvY29sIGZpZWxkLCB3 ZSBhcmUgc2F5aW5nIHRoYXQgaW4gcHJhY3RpY2UgKG5vdCBieSBydWxlKSBOU0gNCm1ldGFkYXRh IGNhbiBub3QgYmUgdXNlZCBmb3IgT0FNLiAgVGhhdCdzIGZpbmUgd2l0aCBtZSBhcyBsb25nIGFz IHdlDQphZ3JlZSBvbiB0aGF0Lg0KDQpZb3VycywNCkpvZWwNCg0KT24gMi8xMy8yMDIyIDI6NTIg QU0sIEd5YW4gTWlzaHJhIHdyb3RlOg0KPg0KPiBIaSBKaW0sIEpvZWwgJiBTRkMgV0csDQo+DQo+ IEkgYWdyZWUgdGhhdCB0aGUgUkZDIDgzMDAgZGVmaW5pdGlvbiBvZiBPIGJpdCBpcyBpbmNvbXBs ZXRlIGFuZCBub3QNCj4gY2xlYXIgYXMgdG8gaXRzIGludGVuZGVkIHVzZS4NCj4NCj4gVGhhdCBp cyBhIHByb2JsZW0gdGhhdCBJIGFncmVlIG5lZWRzIHRvIGJlIHJlY3RpZmllZC4NCj4NCj4gSSB1 bmRlcnN0YW5kIHRoYXQgd2UgbmVlZCB0byBnZXQgdGhpcyByZXNvbHZlZCBiZWZvcmUgd2UgY2Fu IHByb2dyZXNzDQo+IE11bHRpbGF5ZXIgU0ZDIE9BTSBkcmFmdC1pZXRmLXNmYy1tdWx0aS1sYXll ci1vYW0tMTggYW5kIFNGQyBJT0FNLg0KPg0KPiBJIGFncmVlIHRoYXQgd2hhdCBtYWtlcyBzZW5z ZSB0byBtZSBhcyBhIHBhdGggZm9yd2FyZCBpcyB0byBkZXByZWNhdGUNCj4gdGhlIE8gYml0IGFu ZCBub3QgdXNlIGluIFNGQyBNdWx0aWxheWVyIE9BTSBhbmQgU0ZDIElPQU0sIGFzIGJvdGggU0ZD DQo+IE11bHRpbGF5ZXIgT0FNIGFuZCBTRkMgSU9BTSBhcmUgaWRlbnRpZmllZCBieSB0aGUgcmVz cGVjdGl2ZSB2YWx1ZXMgZm9yDQo+IHRoZSBOU0ggTmV4dCBQcm90b2NvbCBmaWVsZCAodG8gYmUg YXNzaWduZWQgYnkgSUFOQSksIGFzIHdlbGwgYXMgc28gZmFyDQo+IG5vIE9BTS1zcGVjaWZpYyBt ZXRhIGRhdGEgVExWIGhhcyBiZWVuIHlldCBkZWZpbmVkLg0KPg0KPiBTbyB3ZSBoYXZlIEkgYmVs aWV2ZSBzb2xpZCBzb2x1dGlvbiBhbmQgcGF0aCBmb3J3YXJkIGFuZCBJIHN1cHBvcnQNCj4gZGVw cmVjYXRpbmcgdGhlIE8gYml0Lg0KPg0KPiBLaW5kIFJlZ2FyZHMNCj4NCj4gR3lhbg0KPg0KPiBP biBXZWQsIEZlYiAyLCAyMDIyIGF0IDU6NDIgUE0gR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdt YWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPg0KPiA8bWFpbHRvOmdyZWdpbWly c2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4+IHdyb3RlOg0KPg0K PiAgICAgVGhhbmsgeW91LCBKaW0gYW5kIEpvZWwsIGZvciBndWlkaW5nIHRoZSBTRkMgT0FNIHdv cmsgYW5kIHBvaW50aW5nDQo+ICAgICBvdXQgdGhlIGlzc3VlIHRoYXQgbXVzdCBiZSBhZGRyZXNz ZWQuDQo+DQo+ICAgICBJJ3ZlIHJldmlld2VkIG91ciBTRkMgT0FNIGRvY3VtZW50cyBhbmQgZHJh ZnQtaWV0Zi1zZmMtbnNoLXRsdi4gQXMgSQ0KPiAgICAgdW5kZXJzdGFuZCB0aGVzZSBkb2N1bWVu dHMsIHRoZSBBY3RpdmUgU0ZDIE9BTSBhbmQgSU9BTSBhcmUNCj4gICAgIGlkZW50aWZpZWQgYnkg dGhlIHJlc3BlY3RpdmUgdmFsdWVzIGZvciB0aGUgTlNIIE5leHQgUHJvdG9jb2wgZmllbGQNCj4g ICAgICh0byBiZSBhc3NpZ25lZCBieSBJQU5BKS4gQXQgdGhlIHNhbWUgdGltZSwgc28gZmFyIG5v IE9BTS1zcGVjaWZpYw0KPiAgICAgbWV0YSBkYXRhIFRMViBoYXMgYmVlbiBkZWZpbmVkLiBUaHVz LCBpdCBhcHBlYXJzIHRoYXQgb25lIHdheQ0KPiAgICAgZm9yd2FyZCBjb3VsZCBiZSB0byBub3Qg aW52b2x2ZSB0aGUgTyBiaXQgaW4gdGhlIGFjdGl2ZSBTRkMgT0FNIG9yDQo+ICAgICBJT0FNIGFs dG9nZXRoZXIuIEluIG90aGVyIHdvcmRzLCB0byBkZXByZWNhdGUgdGhlIE5TSCBPIGJpdC4NCj4N Cj4gICAgIEkgZ3JlYXRseSBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMgb24gdGhlIHByb3Bvc2Fs IHRvIGRlcHJlY2F0ZSB0aGUNCj4gICAgIE5TSCBPIGJpdC4NCj4NCj4gICAgIFJlZ2FyZHMsDQo+ ICAgICBHcmVnDQo+DQo+ICAgICBPbiBXZWQsIEZlYiAyLCAyMDIyIGF0IDEwOjM2IEFNIEphbWVz IEd1aWNoYXJkDQo+ICAgICA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPG1haWx0bzpq YW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+DQo+ICAgICA8bWFpbHRvOmphbWVzLm4uZ3Vp Y2hhcmRAZnV0dXJld2VpLmNvbTxtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29t Pj4+IHdyb3RlOg0KPg0KPiAgICAgICAgIEhpIFdHOl9fX18NCj4NCj4gICAgICAgICBfXyBfXw0K Pg0KPiAgICAgICAgIEhhdmluZyByZXZpZXdlZCBhbGwgb2YgdGhlIE9BTSByZWxhdGVkIGRvY3Vt ZW50cyBpbiBvdXIgV0csIHRoZQ0KPiAgICAgICAgIGNoYWlycyB3b3VsZCBsaWtlIHRvIHByb3Zp ZGUgYSBmZXcgY29tbWVudHMgdG8gaG9wZWZ1bGx5DQo+ICAgICAgICAgZ2VuZXJhdGUgZGlzY3Vz c2lvbiBhbmQgZm9yd2FyZCBwcm9ncmVzcyBvZiB0aGlzIHdvcms6X19fXw0KPg0KPiAgICAgICAg IF9fIF9fDQo+DQo+ICAgICAgICAgMSkgVGhlIGNoYWlycyBoYXZlIHJldmlld2VkIHRoZSBPIGJp dCBkZWZpbml0aW9uIGluIFJGQyA4MzAwLg0KPiAgICAgICAgIFRoYXQgZGVmaW5pdGlvbiBpcyBh dCBiZXN0IG9wZW4gdG8gaW50ZXJwcmV0YXRpb24gYW5kIHRoZXJlZm9yZQ0KPiAgICAgICAgIGlu Y29tcGxldGUuICBGb3IgZXhhbXBsZSwgdGhlIGNsZWFyIGludGVudGlvbiBpcyBvbmx5IHRvIG1h cmsNCj4gICAgICAgICBwYWNrZXRzIHdoaWNoIGFyZSBpbnRlbmRlZCBmb3IgU0ZDIE9BTSBhdCB0 aGUgU0ZDIHNlcnZpY2UNCj4gICAgICAgICBsYXllci4gIEJ1dCB0aGF0IGlzIG5vdCB3aGF0IHRo ZSBjdXJyZW50IHRleHQgc2F5cy4gIFRoZXJlIGlzDQo+ICAgICAgICAgYWxzbywgdW5mb3J0dW5h dGVseSwgYW1iaWd1aXR5IGFzIHRvIHdoYXQgY29uc3RpdHV0ZXMgYW4gT0FNDQo+ICAgICAgICAg cGFja2V0LiAgU28gaXQgaXMgcmVhc29uYWJsZSBmb3IgZG9jdW1lbnRzIHRvIHVwZGF0ZSA4MzAw IHRvDQo+ICAgICAgICAgY2xhcmlmeSB0aGUgZXhhY3QgYXBwbGljYWJpbGl0eSBhbmQgYWN0aW9u IGZvciB0aGUgTy1iaXQuX19fXw0KPg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgMikg SG93ZXZlciwgcmVsYXRlZCB0byBwb2ludCAxKSwgd2UgY2FuJ3QgaGF2ZSBtdWx0aXBsZQ0KPiAg ICAgICAgIGRvY3VtZW50cyB1cGRhdGluZyB0aGUgZGVmaW5pdGlvbiBkaWZmZXJlbnRseS4gIEFz IHN1Y2gsIHRoZQ0KPiAgICAgICAgIGF1dGhvcnMgb2YgdGhlIFNGQyBpT0FNIGRyYWZ0IGFuZCB0 aGUgU0ZDIG11bHRpLWxheWVyLW9hbSBkcmFmdA0KPiAgICAgICAgIG5lZWQgdG8gY29tZSB0b2dl dGhlciBhbmQgZmlndXJlIG91dCB3aGF0IHRoZSBjbGFyaWZpY2F0aW9uIGlzDQo+ICAgICAgICAg Zm9yIHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgYml0LiBXZSBkbyBub3QgYmVsaWV2ZSBhcyBjaGFp cnMgdGhhdA0KPiAgICAgICAgIGVpdGhlciBvZiB0aGVzZSBkb2N1bWVudHMgY2FuIG1vdmUgZm9y d2FyZCBmcm9tIHRoZSBXRyB1bnRpbA0KPiAgICAgICAgIHN1Y2ggY2xhcml0eSBoYXMgYmVlbiBy ZWFjaGVkLiBfX19fDQo+DQo+ICAgICAgICAgX18gX18NCj4NCj4gICAgICAgICAzKSBSZWxhdGVk IHRvIHRoZSBTRkMgaU9BTSwgd2UgbmVlZCBhIGNsZWFyIGRlZmluaXRpb24gb2YgaU9BTS4NCj4g ICAgICAgICBUaGVyZSBzZWVtIHRvIGJlIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIGRlZmluaXRp b25zIGluDQo+ICAgICAgICAgcHVibGlzaGVkIFJGQ3MsIHRoZSB1c2FnZSAod2hpY2ggaXMgbm90 IGEgZGVmaW5pdGlvbikgaW4gdGhlIFNGQw0KPiAgICAgICAgIGRyYWZ0LCBhbmQgdGhlIHZhcmlv dXMgaXBwbSBkcmFmdHMuICBBbnkgc3VjaCBkZWZpbml0aW9uIHdpbGwNCj4gICAgICAgICBuZWVk IHRvIGJlIHZldHRlZCB3aXRoIHRoZSBpcHBtIHdvcmtpbmcgZ3JvdXAuX19fXw0KPg0KPiAgICAg ICAgIF9fIF9fDQo+DQo+ICAgICAgICAgQWdhaW4sIGl0IHdvdWxkIGJlIGdvb2QgaWYgbWVtYmVy cyBvZiB0aGUgd29ya2luZyBncm91cCBiZXlvbmQNCj4gICAgICAgICB0aGUgdHdvIGF1dGhvciB0 ZWFtcyBzcG9rZSB1cCBhYm91dCB0aGVpciByZWFkaW5ncyBvZiB0aGUNCj4gICAgICAgICBkb2N1 bWVudHMsIGFuZCB0aGVpciB1bmRlcnN0YW5kaW5ncyBvZiB3aGF0IHdlIG5lZWQuX19fXw0KPg0K PiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgWW91cnMsX19fXw0KPg0KPiAgICAgICAgIEpp bSBhbmQgSm9lbF9fX18NCj4NCj4gICAgICAgICBfXyBfXw0KPg0KPiAgICAgICAgIF9fIF9fDQo+ DQo+ICAgICAgICAgX18gX18NCj4NCj4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgICAgIHNmYyBtYWlsaW5nIGxpc3QNCj4gICAg ICAgICBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gPG1haWx0bzpzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmM8aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGc2ZjJmRhdGE9MDQlN0MwMSU3Q2phbWVzLm4uZ3VpY2hhcmQlNDBmdXR1cmV3ZWku Y29tJTdDOWRiMmFiMGE5MzgyNDYxMzk3ZjkwOGQ5ZWY2ZjdmZjUlN0MwZmVlOGZmMmEzYjI0MDE4 OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3ODA0MDg0NDgxMTk2MjY0JTdDVW5rbm93biU3 Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2 SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9UjEyMHJQTWFZYmJSTE92NWpHQSUy QmlBSm90THE0Qk84ZmFoZzM0NTJuMlBVJTNEJnJlc2VydmVkPTA+DQo+ICAgICAgICAgPGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPGh0dHBzOi8vbmFtMTEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9y ZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNmYyZkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNo YXJkJTQwZnV0dXJld2VpLmNvbSU3QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5MDhkOWVmNmY3ZmY1JTdD MGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNDA4NDQ4MTM1 MjUxNCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9p VjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJnNkYXRhPSUyRmtv dEV3b2RnT2N3d3BQZ3JOSUl5WiUyQlk1dEMzYklpZWdLQWp6dm8lMkJwS0klM0QmcmVzZXJ2ZWQ9 MD4+DQo+DQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiAgICAgc2ZjIG1haWxpbmcgbGlzdA0KPiAgICAgc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0K PiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8aHR0cHM6Ly9u YW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG d3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2ZjJmRhdGE9MDQlN0MwMSU3Q2ph bWVzLm4uZ3VpY2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDOWRiMmFiMGE5MzgyNDYxMzk3ZjkwOGQ5 ZWY2ZjdmZjUlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3 ODA0MDg0NDgxMzUyNTE0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdN REFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAm c2RhdGE9JTJGa290RXdvZGdPY3d3cFBnck5JSXlaJTJCWTV0QzNiSWllZ0tBanp2byUyQnBLSSUz RCZyZXNlcnZlZD0wPg0KPiAgICAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjPGh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNmYyZk YXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzlkYjJhYjBh OTM4MjQ2MTM5N2Y5MDhkOWVmNmY3ZmY1JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZl ZGMlN0MxJTdDMSU3QzYzNzgwNDA4NDQ4MTM1MjUxNCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhl eUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZD STZNbjAlM0QlN0MzMDAwJnNkYXRhPSUyRmtvdEV3b2RnT2N3d3BQZ3JOSUl5WiUyQlk1dEMzYklp ZWdLQWp6dm8lMkJwS0klM0QmcmVzZXJ2ZWQ9MD4+DQo+DQo+IC0tDQo+DQo+IDxodHRwOi8vd3d3 LnZlcml6b24uY29tLzxodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cCUzQSUyRiUyRnd3dy52ZXJpem9uLmNvbSUyRiZkYXRhPTA0JTdDMDElN0Nq YW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5MDhk OWVmNmY3ZmY1JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYz NzgwNDA4NDQ4MTM1MjUxNCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3 TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAw JnNkYXRhPU9OamZnM0daSjVhdHIxeDhCUjc5Mlh6TyUyRjlwb3pqTjJHR0pCQSUyRjVqSzh3JTNE JnJlc2VydmVkPTA+Pg0KPg0KPiAqR3lhbiBNaXNocmEqDQo+DQo+IC9OZXR3b3JrIFNvbHV0aW9u cyBBLy9yY2hpdGVjdCAvDQo+DQo+IC9FbWFpbCBneWFuLnMubWlzaHJhQHZlcml6b24uY29tPG1h aWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tPiA8bWFpbHRvOmd5YW4ucy5taXNocmFAdmVy aXpvbi5jb208bWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20+Pi8vDQo+IC8NCj4NCj4g L00gMzAxIDUwMi0xMzQ3DQo+DQo+IC8NCj4NCj4NCi0tDQpbaHR0cDovL3NzNy52encuY29tL2lz L2ltYWdlL1Zlcml6b25XaXJlbGVzcy92ei1sb2dvLWVtYWlsXTxodHRwczovL25hbTExLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnd3dy52ZXJpem9u LmNvbSUyRiZkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3 QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5MDhkOWVmNmY3ZmY1JTdDMGZlZThmZjJhM2IyNDAxODljNzUz YTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNDA4NDQ4MTM1MjUxNCU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhh V3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJnNkYXRhPU9OamZnM0daSjVhdHIxeDhCUjc5Mlh6TyUy Rjlwb3pqTjJHR0pCQSUyRjVqSzh3JTNEJnJlc2VydmVkPTA+DQpHeWFuIE1pc2hyYQ0KTmV0d29y ayBTb2x1dGlvbnMgQXJjaGl0ZWN0DQpFbWFpbCBneWFuLnMubWlzaHJhQHZlcml6b24uY29tPG1h aWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tPg0KTSAzMDEgNTAyLTEzNDcNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxp c3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_787AE7BB302AE849A7480A190F8B933035494AA7OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5Okdlb3JnaWE7DQoJcGFub3NlLTE6MiA0IDUgMiA1IDQgNSAyIDMgMzt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ047fQ0K c3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1M IENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9y bWF0w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ047fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgSmltLCBhbGwsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2UgaGFkIG1h bnkgZGlzY3Vzc2lvbnMgaW4gdGhlIHBhc3QgYWJvdXQgdGhlIE8tYml0IChpbmNsdWRpbmcgYSBw cm9wb3NhbCB0byB0YWcgdGhlIGZsYWcgYXMgcmVzZXJ2ZWQgYW5kIGRlZmluZSBpdCB3aGVuIG5l ZWRlZCBbMV0sIGRlcHJlY2F0ZQ0KIHRoZSBPLWJpdCBbMl0pIGJlZm9yZSBmaW5hbGx5IGFncmVl aW5nIG9uIHRoZSB0ZXh0IHdlIGhhdmUgaW4gODMwMC4gPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkkgZG9u4oCZdCB0aGluayB3ZSBoYXZlIG5ldyBhcmd1bWVudHMgdG8gZGVwcmVjYXRlIHRoZSBP LWJpdC4gSG93ZXZlciwgYSBjbGFyaWZpY2F0aW9uIG9mIGludGVuZGVkIG1lYW5pbmcgb2Yg4oCc T0FNIHBhY2tldOKAnSBpcyB3b3J0aCB0byBoYXZlLg0KIEnigJltIGhhcHB5IHRvIHdvcmsgd2l0 aCBvdGhlciB2b2x1bnRlZXJzIG9uIGEgc2hvcnQgZG9jdW1lbnQgdGhhdCBmaXhlcyB0aGF0LiA8 bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+WzFdDQo8YSBocmVmPSJo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NmYy9mNFJiWWxVS0tIbTUzVTFl YUN2amhNeXBMYzAvIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2Zj L2Y0UmJZbFVLS0htNTNVMWVhQ3ZqaE15cExjMC88L2E+ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+WzJdDQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3NmYy9seVRmb2poYzdpaXNwcnlHNGJYNjZCN0ZjaTQvIj4NCmh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2ZjL2x5VGZvamhjN2lpc3ByeUc0Ylg2 NkI3RmNpNC88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBzZmMgJmx0O3Nm Yy1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+RGUgbGEgcGFydCBkZTwvYj4gSmFtZXMgR3VpY2hh cmQ8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbHVuZGkgMTQgZsOpdnJpZXIgMjAyMiAxNToy ODxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpICZsdDtj cGlnbmF0YT00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs7IEd5YW4gTWlzaHJhICZsdDto YXlhYnVzYWdzbUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBHcmVnIE1pcnNr eSAmbHQ7Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0Ozsgc2ZjQGlldGYub3JnPGJyPg0KPGI+T2Jq ZXQmbmJzcDs6PC9iPiBSZTogW3NmY10gUHJvZ3Jlc3Npb24gb2YgT0FNIHdvcmsgaW4gdGhlIFNG QyBXRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIENh cmxvcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Tb21lIHJlc3BvbnNl cyBpbi1saW5lIOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNmYyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKTxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEZlYnJ1YXJ5IDEzLCAyMDIyIDExOjA3IFBN PGJyPg0KPGI+VG86PC9iPiBHeWFuIE1pc2hyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhheWFidXNh Z3NtQGdtYWlsLmNvbSI+aGF5YWJ1c2Fnc21AZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8 L2I+IEdyZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29t Ij5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIFBy b2dyZXNzaW9uIG9mIE9BTSB3b3JrIGluIHRoZSBTRkMgV0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5SZXBseWluZyB0byB0aGlzIHNwZWNpZmljIGVtYWlsIGluIHRoZSB0aHJl YWQsIG9ubHkgYmVjYXVzZSBpdCBpcyB0aGUgbGF0ZXN0IG9uZSBhdCB0aGlzIHBvaW50IGluIHRp bWUsIGJ1dCBidW5kbGluZyBjb21tZW50cyBmcm9tIHZhcmlvdXMgcGxhY2VzIG9uIHRoZSB0aHJl YWQuIFBsZWFzZSBmaW5kIHNvbWUgZm9sbG93LXVwIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgbWFy a2VkDQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iPuKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+Q01QPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIj7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPiwgaW5kaWNhdGluZyB0aGUNCjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiI+4oCcPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIj7igJ08L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPiwgYW5kIG9yZ2FuaXplZCBjaHJvbm9sb2dpY2FsbHk6DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5KYW1lcyBOIEd1aWNo YXJkICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tIj5q YW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208L2E+Jmd0Ozo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MSkgVGhlIGNoYWlycyBoYXZlIHJldmlld2VkIHRoZSBP IGJpdCBkZWZpbml0aW9uIGluIFJGQyA4MzAwLiZuYnNwOyBUaGF0IGRlZmluaXRpb24gaXMgYXQg YmVzdCBvcGVuIHRvIGludGVycHJldGF0aW9uIGFuZCB0aGVyZWZvcmUgaW5jb21wbGV0ZS4mbmJz cDsgRm9yIGV4YW1wbGUsIHRoZSBjbGVhcg0KIGludGVudGlvbiBpcyBvbmx5IHRvIG1hcmsgcGFj a2V0cyB3aGljaCBhcmUgaW50ZW5kZWQgZm9yIFNGQyBPQU0gYXQgdGhlIFNGQyBzZXJ2aWNlIGxh eWVyLiZuYnNwOyBCdXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgY3VycmVudCB0ZXh0IHNheXMuJm5i c3A7IFRoZXJlIGlzIGFsc28sIHVuZm9ydHVuYXRlbHksIGFtYmlndWl0eSBhcyB0byB3aGF0IGNv bnN0aXR1dGVzIGFuIE9BTSBwYWNrZXQuJm5ic3A7IFNvIGl0IGlzIHJlYXNvbmFibGUgZm9yIGRv Y3VtZW50cyB0byB1cGRhdGUNCiA4MzAwIHRvIGNsYXJpZnkgdGhlIGV4YWN0IGFwcGxpY2FiaWxp dHkgYW5kIGFjdGlvbiBmb3IgdGhlIE8tYml0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q01QOiBJdCBpcyB1bmNsZWFyIHRv IG1lIHdoYXQgZXhhY3QgaXNzdWVzIHRoZSBjaGFpcnMgYXJlIGNhbGxpbmcgb3V0LiBUaGVyZSBh cmUgdHdvIGlzc3VlcyBtZW50aW9uZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNNUDogMS4gJnF1 b3Q7QnV0IHRoYXQgaXMgbm90IHdoYXQgdGhlIGN1cnJlbnQgdGV4dCBzYXlzLjwvc3Bhbj48c3Bh biBsYW5nPSJaSC1DTiI+4oCdIOKAlDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyB3aGF0 IGRvZXMgdGhlIHRleHQgc2F5IHByZWNpc2VseT8gJm5ic3A7Q2FuIHlvdSBwb2ludCB0byB0aGUg c3BlY2lmaWMgUkZDIDgzMDAgdGV4dCB0aGF0IGlzIGJlbGlldmVkIHRvIGJlIGluY29tcGxldGUs DQogYW5kIGEgZGV0YWlsZWQgdXNlIGNhc2UgdGhhdCBzaG93Y2FzZXMgdGhlIHBvdGVudGlhbCBp c3N1ZT8gQW4gZXh0cmFwb2xhdGVkIGNvdW50ZXItZXhhbXBsZSBqdXN0IHRvIG1ha2UgYSBwb2lu dDogdGhlIHRleHQgZG9lcyBub3QgJm5ic3A7c2F5IHdoYXQgZGF5cyBvZiB0aGUgd2VlayBPQU0g cGFja2V0cyBjYW4gYmUgbWFya2VkLCB5ZXQgdGhlcmU8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04i PuKAmTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+cyBhbiBleHBlY3RhdGlvbg0KIHRoYXQgdGhl eSB3aWxsIHdvcmsgTW9uZGF5cyBhbmQgU2F0dXJkYXlzIGFsbCB0aGUgc2FtZSA8L3NwYW4+PHNw YW4gbGFuZz0iWkgtQ04iPuKAlDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IGV2ZW4gaG9saWRh eXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5KaW0mZ3Q7IEN1cnJlbnRseSBSRkM4MzAwIHNh eXMg4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlRoZSBPIGJpdCBNVVNUIGJlIHNldCBmb3IgT0FNIHBhY2tldHMgYW5kIE1VU1QgTk9UIGJlIHNl dCBmb3Igbm9uLU9BTSBwYWNrZXRz4oCdLiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIGZpcnN0IGlz c3VlIGlzIGRvZXMgdGhpcyBtZWFuIHRoZSBPIGJpdCBzaG91bGQgYmUgc2V0IGZvciBBTEwgT0FN IHBhY2tldHMgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZXkgYmVsb25nIHRvIHRoZSBOU0ggc2Vy dmljZSBwbGFuZT8gT3Igc2hvdWxkIGl0IG9ubHkgYmUgc2V0IGZvciBTRkMgT0FNIHBhY2tldHM/ IEFuZCB3aGF0IGV4YWN0bHkgaXMgYW4gU0ZDIE9BTSBwYWNrZXQgYXMgdGhlIGVhcmxpZXIgcmVm ZXJlbmNlIHRvIFJGQzYyOTEgaXMganVzdCBhIGdlbmVyYXRlIHNldCBvZiBndWlkZWxpbmVzIGZv ciB0aGUgdXNlIG9mIHRoZSB0ZXJtIE9BTS4gVGhlIHNlY29uZCBpc3N1ZSBpcyB0aGF0IGlmIHRo YXQgTyBiaXQgaXMgc2V0IHRoZW4gR3JlZ+KAmXMgZG9jdW1lbnQgaXMgaW4gY29uZmxpY3Qgd2l0 aCBJT0FNIGFzIGJvdGggdXNlIHRoZSBuZXh0IHByb3RvY29sIGZpZWxkIGFuZCBldmVuIGlmIHRo ZSBPIGJpdCBpcyBzZXQgaXQgaXMgbWVhbmluZ2xlc3MgYXMgdGhlIHByb3RvY29sIGFjdGlvbiBp cyBiYXNlZCBzb2xlbHkgb24gdGhlIHNldHRpbmcgb2YgdGhlIG5leHQgcHJvdG9jb2wgZmllbGQu IFNvIGluIHRoaXMgY2FzZSBjYW4gdGhlaXIgc29sdXRpb25zIHNpbXBseSBpZ25vcmUgd2hhdCBS RkMgODMwMCBzYXlzIGUuZy4gTVVTVCBzZXQgdGhlIE8gYml0PyBPciBpZiB0aGV5IHNldCB0aGUg TyBiaXQgdG8gYmUgY29uZm9ybWFudCB0byB3aGF0IFJGQyA4MzAwIHNheXMgdGhlbiBkbyB3ZSBu ZWVkIGNsZWFyZXIgcnVsZXMgc3RhdGluZyB3aGF0IHRvIGRvIGlmIHRoZSBuZXh0IHByb3RvY29s IGZpZWxkIGlzIE5PVCBhbiBPQU0gbmV4dCBwcm90b2NvbCBzdWNoIGFzIHRoZSBjb250ZXh0IGhl YWRlcnMgc2hvdWxkIHRoZW4gYmUgZXhhbWluZWQ/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNNUDogMi4gV2hh dCBzcGVjaWZpY2FsbHkgaXMgdGhlIGFtYmlndWl0eSB3aXRoIHdoYXQgYW4gT0FNIHBhY2tldCBp cz8gUGxlYXNlIGdyZXAgdGhlIFJGQyBzZXJpZXMgZm9yDQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgt Q04iPuKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+b2FtIHBhY2tldDwvc3Bhbj48c3BhbiBs YW5nPSJaSC1DTiI+4oCdPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4sIGl0IGlzIG5vdCBhIG5l dyB0ZXJtLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DTVA6IE5ldC1uZXQsIE8tYml0PTEs IE9BTSBwYWNrZXQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+SmltJmd0OyBhbWJpZ3VpdHkgaXMgd2hldGhlciBpdCBpcyBvbmx5IFNGQyBPQU0gcGFja2V0 cyB0aGF0IGFyZSBiZWluZyBkaXNjdXNzZWQgb3IgQUxMIE9BTSBwYWNrZXRzIG5vdGhpbmcgdGhh dCBzb21lIG1pZ2h0IGJlIGF0IHRoZSBzZXJ2aWNlIGxheWVyIGFuZCBzb21lIG1pZ2h0DQogbm90 LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5KaW08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+MikgSG93ZXZlciwgcmVsYXRlZCB0byBwb2ludCAxKSwgd2UgY2FuJ3QgaGF2ZSBtdWx0aXBs ZSBkb2N1bWVudHMgdXBkYXRpbmcgdGhlIGRlZmluaXRpb24gZGlmZmVyZW50bHkuJm5ic3A7IEFz IHN1Y2gsIHRoZSBhdXRob3JzIG9mIHRoZSBTRkMgaU9BTSBkcmFmdCBhbmQgdGhlIFNGQw0KIG11 bHRpLWxheWVyLW9hbSBkcmFmdCBuZWVkIHRvIGNvbWUgdG9nZXRoZXIgYW5kIGZpZ3VyZSBvdXQg d2hhdCB0aGUgY2xhcmlmaWNhdGlvbiBpcyBmb3IgdGhlIGRlZmluaXRpb24gb2YgdGhhdCBiaXQu IFdlIGRvIG5vdCBiZWxpZXZlIGFzIGNoYWlycyB0aGF0IGVpdGhlciBvZiB0aGVzZSBkb2N1bWVu dHMgY2FuIG1vdmUgZm9yd2FyZCBmcm9tIHRoZSBXRyB1bnRpbCBzdWNoIGNsYXJpdHkgaGFzIGJl ZW4gcmVhY2hlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q01QOiBJZiB0aGVyZSBpcyBzdGlsbCBiZWxpZXZl ZCB0byBiZSBhbiBhbWJpZ3VpdHkgb3IgYSBjbGVhciBvcHBvcnR1bml0eSBmb3IgaW1wcm92aW5n IHRoZSBkZWZpbml0aW9uLCBJIGFncmVlIHdpdGggY29uc29saWRhdGluZyB0aGF0IHVwZGF0ZS4g SSBoYWQgc3VnZ2VzdGVkIGJlZm9yZSB0aGF0IGlmIHN1Y2ggbmV3IHRleHQgb3IgcmVhbCBjbGFy aWZpY2F0aW9uIGlzIGFncmVlZCwNCiBhIHNlcGFyYXRlIGRvY3VtZW50IHRoYXQgb25seSBtYWtl cyB0aGF0IE8tYml0IGNsYXJpZmljYXRpb24gaXMgdGhlIG1vc3QgY2xlYXIgYW5kIGNsZWFuIHdh eSB0byBnby4gVGhhdCBkb2Mgc2hvdWxkIGJlIGEgb25lLXBhZ2VyIG9yIGxlc3MuIEk8L3NwYW4+ PHNwYW4gbGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ZCBiZSBoYXBw eSB0byBjb250cmlidXRlIHRvIHRoYXQgbWluaW1hbCBkb2MsIGlmIGl0IGlzIHNob3duIHRvDQog YmUgbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Q01QOiBGb3IgY29tcGxldGVuZXNzIGFsc28sIHRoZSAmcXVvdDtTRkMgbXVsdGktbGF5ZXIt b2FtPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIj7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PiBkb2N1bWVudCBoYXMgbWFueSBvdXRzdGFuZGluZyBpc3N1ZXMgYmVzaWRlcyB0aGUgTy1iaXQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5HcmVn IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSI+Z3JlZ2lt aXJza3lAZ21haWwuY29tPC9hPiZndDs8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSd2ZSByZXZp ZXdlZCBvdXIgU0ZDIE9BTSBkb2N1bWVudHMgYW5kIGRyYWZ0LWlldGYtc2ZjLW5zaC10bHYuIEFz IEkgdW5kZXJzdGFuZCB0aGVzZSBkb2N1bWVudHMsIHRoZSBBY3RpdmUgU0ZDIE9BTSBhbmQgSU9B TSBhcmUgaWRlbnRpZmllZCBieSB0aGUgcmVzcGVjdGl2ZSB2YWx1ZXMgZm9yIHRoZSBOU0ggTmV4 dCBQcm90b2NvbCBmaWVsZCAodG8gYmUgYXNzaWduZWQgYnkgSUFOQSkuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DTVA6IFRoZXJlIGlz IGEgbWFqb3IgaXNzdWUgd2l0aCB0aGUgc2VudGVuY2UgYWJvdmUuIEFjdGl2ZSBTRkMgT0FNIChh cyBhIGNhdGVnb3J5KSwgYXMgcGVyIFJGQyA4MzAwLCBuZWVkcyB0byBiZSBpZGVudGlmaWVkIGJ5 IHNldHRpbmcgdGhlIE8tYml0LiBObyB3YXkgYXJvdW5kIHRoYXQgYmFzZWQgb24gUkZDIDgzMDAu IEhvd2V2ZXIsIHRoZSB0ZXh0ICZxdW90O3RoZSBBY3RpdmUgU0ZDDQogT0FNPC9zcGFuPjxzcGFu IGxhbmc9IlpILUNOIj7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBjcmVhdGVzIGNvbmZ1 c2lvbiBzaW5jZSBpdCByZWZlciB0byBhIHNwZWNpZmljIE9BTSBwcm90b2NvbCB3aGljaCBoYXMg dGhlIHNhbWUgbmFtZSBhcyBhIHRoZSBjYXRlZ29yeSBhcyB3ZWxsLiBUaGF0IG5hbWUgY29sbGlz aW9uIGlzIHF1aXRlIHVuZm9ydHVuYXRlIGluIG15IG9waW5pb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QXQgdGhlIHNhbWUgdGltZSwgc28gZmFyIG5vIE9B TS1zcGVjaWZpYyBtZXRhIGRhdGEgVExWIGhhcyBiZWVuIGRlZmluZWQuIFRodXMsIGl0IGFwcGVh cnMgdGhhdCBvbmUgd2F5IGZvcndhcmQgY291bGQgYmUgdG8gbm90IGludm9sdmUgdGhlIE8gYml0 IGluIHRoZSBhY3RpdmUgU0ZDIE9BTSBvciBJT0FNIGFsdG9nZXRoZXIuIEluIG90aGVyIHdvcmRz LCB0byBkZXByZWNhdGUgdGhlDQogTlNIIE8gYml0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q01QOiBSRkMgODkyNCBhbHJlYWR5IGluY2x1ZGVzIElD TVAgYW5kIEJGRCBhcyBleGFtcGxlIFNGQyBBY3Rpb24gT0FNIHByb3RvY29scy4gVGhvc2UgY2Fu IGJlIGVuY2Fwc3VsYXRlZCBpbiBJUCwgaW4gd2hpY2ggdGhlIE5leHQtUHJvdG9jb2wgaW5kaWNh dGVzIElQDQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iPuKAlDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+IGFuZCAoYXMgcGVyIFJGQyA4MzAwKSB0aGUgTy1iaXQgaXMgc2V0IHRvIGluZGljYXRl IGFuIE9BTSBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNNUDogVGhlIHByb3Bvc2FsIG9m IGRlcHJlY2F0aW5nIHRoZSBPLWJpdCBicmVha3MgdGhvc2UgU0ZDIE9BTSBwcm90b2NvbHMgYWxy ZWFkeSBpbmNsdWRlZCBpbiBhbiBSRkMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNNUDogVGhhdCBw cm9wb3NhbCBvZiBkZXByZWNhdGluZyB0aGUgTy1iaXQgYWxzbyBicmVha3MgU2VjdGlvbiA0LjEg b2YgSU9BTS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q01QOiBUaGlzIGV4cGlyZWQgSS1EIHlldCBp bXBsZW1lbnRlZCBpbiBvcGVuIHNvdXJjZSB1c2VzIHRoZSBPLWJpdDombmJzcDs8YSBocmVmPSJo dHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZhcmNoaXZlJTJGaWQlMkZkcmFmdC1wZW5uby1zZmMtdHJh Y2UtMDMudHh0JmFtcDtkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2Vp LmNvbSU3QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5MDhkOWVmNmY3ZmY1JTdDMGZlZThmZjJhM2IyNDAx ODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNDA4NDQ4MTE5NjI2NCU3Q1Vua25vd24l N0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJ NklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT16JTJCa0ZnRHFIMjRweVk0 N3dIMEpPSmdlbzJtYUxsQ2dmRlNwM01aNUt6WmMlM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBzOi8v d3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtcGVubm8tc2ZjLXRyYWNlLTAzLnR4dDwvYT4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5HeWFuIE1pc2hyYSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbSI+aGF5YWJ1c2Fnc21AZ21haWwuY29tPC9hPiZndDs8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYWdyZWUgdGhhdCB3aGF0IG1ha2VzIHNl bnNlIHRvIG1lIGFzIGEgcGF0aCBmb3J3YXJkIGlzIHRvIGRlcHJlY2F0ZSB0aGUgTyBiaXQgYW5k IG5vdCB1c2UgaW4gU0ZDIE11bHRpbGF5ZXIgT0FNIGFuZCBTRkMgSU9BTSwgYXMgYm90aCBTRkMg TXVsdGlsYXllciZuYnNwO09BTSBhbmQgU0ZDJm5ic3A7SU9BTSBhcmUgaWRlbnRpZmllZCBieSB0 aGUgcmVzcGVjdGl2ZSB2YWx1ZXMgZm9yIHRoZSBOU0gNCiBOZXh0IFByb3RvY29sIGZpZWxkICh0 byBiZSBhc3NpZ25lZCBieSBJQU5BKSwgYXMgd2VsbCBhcyBzbyBmYXIgbm8gT0FNLXNwZWNpZmlj IG1ldGEgZGF0YSBUTFYgaGFzIGJlZW4geWV0IGRlZmluZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNNUDog V2hhdCBpcyB0aGUgPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIj7igJw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPlNGQyBNdWx0aWxheWVyIE9BTTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiI+4oCd PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNNUDogVGhl IE8tYml0IChyZWFkaW5nIFJGQyA4MzAwKSBkb2VzIG5vdCBpbmRpY2F0ZSBpZiB0aGVyZSBpcyBP QU0gTWV0YWRhdGEuIEl0IGluZGljYXRlcyBhbiBPQU0gcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiPiZxdW90O0pvZWwgTS4gSGFscGVybiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpt aEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0Ozwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5BcyBmYXIgYXMgSSBjYW4gdGVsbCwgaWYgd2UgZGVwcmVjYXRlIHRoZSBP LWJpdCBhbmQgcmVseSBvbiB0aGUgbmV4dCBwcm90b2NvbCBmaWVsZCwgd2UgYXJlIHNheWluZyB0 aGF0IGluIHByYWN0aWNlIChub3QgYnkgcnVsZSkgTlNIIG1ldGFkYXRhIGNhbiBub3QgYmUgdXNl ZCBmb3IgT0FNLiAmbmJzcDtUaGF0J3MgZmluZSB3aXRoIG1lIGFzIGxvbmcgYXMgd2UgYWdyZWUg b24gdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5DTVA6IEkgZG8gbm90IGZ1bGx5IGZvbGxvdyB0aGlzLiBDYW4geW91IGV4cGxhaW4g dGhlIHJlbGF0aW9uc2hpcCBvZiB0aGUgTy1iaXQgd2l0aCBNZXRhZGF0YT88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Q01QOiBIZXJlPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPnMgYW4gZXhhbXBsZTogUkZDIDg5MjQgc2hvd3MgSUNNUCBhcyBBY3Rp dmUgT0FNLiBUaGUgU0ZDIG5leHQgcHJvdG9jb2wgaXMgSVAsIHRoZSBJUCBuZXh0IHByb3RvY29s IGlzIElDTVAsIHRoZSBPLWJpdCBuZWVkcyB0byBiZSBzZXQuJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DTVA6IENvbnNpZGVyIHRoZSBmb2xs b3dpbmcgZG9jdW1lbnQsIGluZGVwZW5kZW50IHN1Ym1pc3Npb24gYW5kIGluIHRoZSBSRkMgUHVi bGljYXRpb24gcXVldWUgYWxyZWFkeTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q01QOiZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtbXltYi1z ZmMtbnNoLWFsbG9jYXRpb24tdGltZXN0YW1wJTJGJmFtcDtkYXRhPTA0JTdDMDElN0NqYW1lcy5u Lmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5MDhkOWVmNmY3 ZmY1JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNDA4 NDQ4MTE5NjI2NCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxD SlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtz ZGF0YT1CMCUyRlFQUVRiUXJ1VEt6cVhmaW42WmZFWXlhdUEyS1pocTBtOFlLU0x0TEUlM0QmYW1w O3Jlc2VydmVkPTAiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW15bWIt c2ZjLW5zaC1hbGxvY2F0aW9uLXRpbWVzdGFtcC88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNN UDogSXMgYSBUaW1lc3RhbXAgaW4gTWV0YWRhdGEgYW4gT0FNIGVsZW1lbnQ/Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DTVA6IENvbnNpZGVy IHRoaXMgcHJvcG9zYWwmbmJzcDs8YSBocmVmPSJodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9y ZyUyRmRvYyUyRmRyYWZ0LW1pcnNreS1zZmMtcG1hbW0lMkYmYW1wO2RhdGE9MDQlN0MwMSU3Q2ph bWVzLm4uZ3VpY2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDOWRiMmFiMGE5MzgyNDYxMzk3ZjkwOGQ5 ZWY2ZjdmZjUlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3 ODA0MDg0NDgxMTk2MjY0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdN REFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAm YW1wO3NkYXRhPUppaWtHZ1hHMzUlMkZXNTE4ZGlzdUl4QXZhV2E1RnVxdmtLY0clMkZheWc2UjQ4 JTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1taXJza3ktc2ZjLXBtYW1tLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q01QOiBXaGVyZSB0 aGUgYmFzZSBoZWFkZXIgYm9ycm93cyBhIGJpdCBmb3IgYW4gT0FNIGZ1bmN0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q01QOiBOZWl0aGVyIG9m IHRob3NlIGhhdmUgYW55IGltcGFjdCBvbiB0aGUgTy1iaXQuJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyI+R3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFp bC5jb20iPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkkgYWdyZWUgdGhhdCwgYXMgd2UgZmluZCBTRkMgTlNIIG5vdywgbm8gT0FNIG1ldGFkYXRh IGhhcyBiZWVuIGRlZmluZWQuIEl0IGFwcGVhcnMgdG8gbWUgdGhhdCBkZXByZWNhdGluZyB0aGUg TyBiaXQgZG9lcyBub3QgYWZmZWN0IGFueSBvZiB0aGUmbmJzcDthbHJlYWR5IGRlZmluZWQgbWVj aGFuaXNtcyBpbiB0aGUmbmJzcDtTRkMgTlNILjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNNUDogSXQgYWN0dWFsbHkgZG9lcywgc2VlIG15 IGV4YW1wbGUgYWJvdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5JIHRoaW5rIHRoYXQgaWYgYSBuZXcsIGZvciBleGFtcGxlLCBNRCBU eXBlID0gMiBUTFYgdGhhdCZuYnNwO2lzIHVzZWQgZm9yIGFueSBPQU0gZnVuY3Rpb25hbGl0eSB0 byBiZSBwcm9wb3NlZCBpbiB0aGUgZnV0dXJlLCBkZXByZWNhdGVkIHRoZSBPIGJpdCB3b3VsZCZu YnNwO25vdCBwcmV2ZW50IHVzaW5nIHN1Y2ggTlNIIFRMVi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNNUDogSSBhZ3JlZSB3 aXRoIHRoaXMgPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIj7igJQ8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPiBiZWNhdXNlIHRoZXJlIGlzIG5vIGNvcnJlbGF0aW9uIGJldHdlZW4gTUQgVHlwZSBm aWVsZCBhbmQgTy1iaXQgYXMgZGVmaW5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5DYXJsb3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Mi8xMy8yMiA8L3NwYW4+PHNw YW4gbGFuZz0iWkgtQ04iPuWNiOW+jDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+MTI6MzI8L3Nw YW4+PHNwYW4gbGFuZz0iWkgtQ04iPuOAgTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+R3lhbiBN aXNocmEgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20iPmhheWFidXNh Z3NtQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIj7jga7jg6Hjg7zj g6s8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5IaSBKb2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5JIGFtIGluIGFncmVlbWVudCBhcyB3ZWxsIHdpdGggd2hhdCB5b3UgaGF2 ZSBzdGF0ZWQgdGhhdCBvbmNlIHRoZSBPIGJpdCBpcyBkZXByZWNhdGVkIHRoYXQgTlNIIG1ldGFk YXRhIGNhbm5vdCBiZSB1c2VkIGZvciBPQU0gYW5kIHRoYXQgd2Ugd291bGQgaGF2ZSB0byBub3cg ZnJvbSB0aGF0IHBvaW50IGZvcndhcmQgcmVseSBvbiB0aGUgbmV4dCBwcm90b2NvbCBmaWVsZCBh cyB3ZQ0KIHdpbGwgYmUgZG9pbmcgZm9yIFNGQyBNdWx0aWxheWVyIGFuZCBTRkMgSU9BTSBkcmFm dHMgYXMgd2VsbCBhcyB3aWxsIGhhdmUgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBhbnkgYWxy ZWFkeSBleGlzdGluZyBkZWZpbmVkIG1lY2hhbmlzbXMgaW4gU0ZDIE5TSC4gJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGRvbjwvc3Bhbj48 c3BhbiBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj50IHNlZSBhbnkg aXNzdWVzIG9yIGltcGFjdCB3aXRoIG1vdmluZyBmb3J3YXJkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+S2luZCBSZWdhcmRzJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HeWFuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFN1biwgRmViIDEzLCAyMDIy IGF0IDEyOjA0IFBNIEdyZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lA Z21haWwuY29tIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SGkgSm9lbCwgPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFncmVlIHRoYXQsIGFzIHdlIGZp bmQgU0ZDIE5TSCBub3csIG5vIE9BTSBtZXRhZGF0YSBoYXMgYmVlbiBkZWZpbmVkLiBJdCBhcHBl YXJzIHRvIG1lIHRoYXQgZGVwcmVjYXRpbmcgdGhlIE8gYml0IGRvZXMgbm90IGFmZmVjdCBhbnkg b2YgdGhlJm5ic3A7YWxyZWFkeSBkZWZpbmVkIG1lY2hhbmlzbXMgaW4gdGhlJm5ic3A7U0ZDIE5T SC4gSSB0aGluayB0aGF0IGlmIGEgbmV3LCBmb3IgZXhhbXBsZSwNCiBNRCBUeXBlID0gMiBUTFYg dGhhdCZuYnNwO2lzIHVzZWQgZm9yIGFueSBPQU0gZnVuY3Rpb25hbGl0eSB0byBiZSBwcm9wb3Nl ZCBpbiB0aGUgZnV0dXJlLCBkZXByZWNhdGVkIHRoZSBPIGJpdCB3b3VsZCZuYnNwO25vdCBwcmV2 ZW50IHVzaW5nIHN1Y2ggTlNIIFRMVi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hhdCBkbyB5b3Ug dGhpbms/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBTdW4sIEZlYiAxMywg MjAyMiBhdCA2OjU1IEFNIEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGVyZSBpcyBhbiBpbXBsaWNhdGlvbiBvZiBkZXByZWNhdGluZyB0 aGUgTy1iaXQgdGhhdCBJIHdvdWxkIGxpa2UgdG8NCjxicj4NCmhlYXIgZnJvbSBtb3JlIFdHIHBh cnRpY2lwYW50cyBhYm91dC48YnI+DQo8YnI+DQpBcyBmYXIgYXMgSSBjYW4gdGVsbCwgaWYgd2Ug ZGVwcmVjYXRlIHRoZSBPLWJpdCBhbmQgcmVseSBvbiB0aGUgbmV4dCA8YnI+DQpwcm90b2NvbCBm aWVsZCwgd2UgYXJlIHNheWluZyB0aGF0IGluIHByYWN0aWNlIChub3QgYnkgcnVsZSkgTlNIIDxi cj4NCm1ldGFkYXRhIGNhbiBub3QgYmUgdXNlZCBmb3IgT0FNLiZuYnNwOyBUaGF0J3MgZmluZSB3 aXRoIG1lIGFzIGxvbmcgYXMgd2UgPGJyPg0KYWdyZWUgb24gdGhhdC48YnI+DQo8YnI+DQpZb3Vy cyw8YnI+DQpKb2VsPGJyPg0KPGJyPg0KT24gMi8xMy8yMDIyIDI6NTIgQU0sIEd5YW4gTWlzaHJh IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBKaW0sIEpvZWwgJmFtcDsgU0ZDIFdHLDxi cj4NCiZndDsgPGJyPg0KJmd0OyBJIGFncmVlIHRoYXQgdGhlIFJGQyA4MzAwIGRlZmluaXRpb24g b2YgTyBiaXQgaXMgaW5jb21wbGV0ZSBhbmQgbm90IDxicj4NCiZndDsgY2xlYXIgYXMgdG8gaXRz IGludGVuZGVkIHVzZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhdCBpcyBhIHByb2JsZW0gdGhh dCBJIGFncmVlIG5lZWRzIHRvIGJlIHJlY3RpZmllZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB1 bmRlcnN0YW5kIHRoYXQgd2UgbmVlZCB0byBnZXQgdGhpcyByZXNvbHZlZCBiZWZvcmUgd2UgY2Fu IHByb2dyZXNzIDxicj4NCiZndDsgTXVsdGlsYXllciBTRkMgT0FNIGRyYWZ0LWlldGYtc2ZjLW11 bHRpLWxheWVyLW9hbS0xOCBhbmQgU0ZDIElPQU0uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgYWdy ZWUgdGhhdCB3aGF0IG1ha2VzIHNlbnNlIHRvIG1lIGFzIGEgcGF0aCBmb3J3YXJkIGlzIHRvIGRl cHJlY2F0ZSA8YnI+DQomZ3Q7IHRoZSBPIGJpdCBhbmQgbm90IHVzZSBpbiBTRkMgTXVsdGlsYXll ciBPQU0gYW5kIFNGQyBJT0FNLCBhcyBib3RoIFNGQyA8YnI+DQomZ3Q7IE11bHRpbGF5ZXIgT0FN IGFuZCBTRkMgSU9BTSBhcmUgaWRlbnRpZmllZCBieSB0aGUgcmVzcGVjdGl2ZSB2YWx1ZXMgZm9y IDxicj4NCiZndDsgdGhlIE5TSCBOZXh0IFByb3RvY29sIGZpZWxkICh0byBiZSBhc3NpZ25lZCBi eSBJQU5BKSwgYXMgd2VsbCBhcyBzbyBmYXIgPGJyPg0KJmd0OyBubyBPQU0tc3BlY2lmaWMgbWV0 YSBkYXRhIFRMViBoYXMgYmVlbiB5ZXQgZGVmaW5lZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgU28g d2UgaGF2ZSBJIGJlbGlldmUgc29saWQgc29sdXRpb24gYW5kIHBhdGggZm9yd2FyZCBhbmQgSSBz dXBwb3J0IDxicj4NCiZndDsgZGVwcmVjYXRpbmcgdGhlIE8gYml0Ljxicj4NCiZndDsgPGJyPg0K Jmd0OyBLaW5kIFJlZ2FyZHM8YnI+DQomZ3Q7IDxicj4NCiZndDsgR3lhbjxicj4NCiZndDsgPGJy Pg0KJmd0OyBPbiBXZWQsIEZlYiAyLCAyMDIyIGF0IDU6NDIgUE0gR3JlZyBNaXJza3kgJmx0Ozxh IGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ncmVn aW1pcnNreUBnbWFpbC5jb208L2E+DQo8YnI+DQomZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdpbWlyc2t5QGdt YWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO1RoYW5rIHlvdSwgSmltIGFuZCBKb2VsLCBmb3IgZ3VpZGluZyB0aGUgU0ZDIE9B TSB3b3JrIGFuZCBwb2ludGluZzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO291dCB0aGUg aXNzdWUgdGhhdCBtdXN0IGJlIGFkZHJlc3NlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwO0kndmUgcmV2aWV3ZWQgb3VyIFNGQyBPQU0gZG9jdW1lbnRzIGFuZCBkcmFm dC1pZXRmLXNmYy1uc2gtdGx2LiBBcyBJPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dW5k ZXJzdGFuZCB0aGVzZSBkb2N1bWVudHMsIHRoZSBBY3RpdmUgU0ZDIE9BTSBhbmQgSU9BTSBhcmU8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtpZGVudGlmaWVkIGJ5IHRoZSByZXNwZWN0aXZl IHZhbHVlcyBmb3IgdGhlIE5TSCBOZXh0IFByb3RvY29sIGZpZWxkPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7KHRvIGJlIGFzc2lnbmVkIGJ5IElBTkEpLiBBdCB0aGUgc2FtZSB0aW1lLCBz byBmYXIgbm8gT0FNLXNwZWNpZmljPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7bWV0YSBk YXRhIFRMViBoYXMgYmVlbiBkZWZpbmVkLiBUaHVzLCBpdCBhcHBlYXJzIHRoYXQgb25lIHdheTxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2ZvcndhcmQgY291bGQgYmUgdG8gbm90IGludm9s dmUgdGhlIE8gYml0IGluIHRoZSBhY3RpdmUgU0ZDIE9BTSBvcjxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO0lPQU0gYWx0b2dldGhlci4gSW4gb3RoZXIgd29yZHMsIHRvIGRlcHJlY2F0ZSB0 aGUgTlNIIE8gYml0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7SSBn cmVhdGx5IGFwcHJlY2lhdGUgeW91ciBjb21tZW50cyBvbiB0aGUgcHJvcG9zYWwgdG8gZGVwcmVj YXRlIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO05TSCBPIGJpdC48YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1JlZ2FyZHMsPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7R3JlZzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 T24gV2VkLCBGZWIgMiwgMjAyMiBhdCAxMDozNiBBTSBKYW1lcyBHdWljaGFyZDxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBm dXR1cmV3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWku Y29tPC9hPjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmph bWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SGkgV0c6X19fXzxi cj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfXyBf Xzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtI YXZpbmcgcmV2aWV3ZWQgYWxsIG9mIHRoZSBPQU0gcmVsYXRlZCBkb2N1bWVudHMgaW4gb3VyIFdH LCB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NoYWlycyB3 b3VsZCBsaWtlIHRvIHByb3ZpZGUgYSBmZXcgY29tbWVudHMgdG8gaG9wZWZ1bGx5PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtnZW5lcmF0ZSBkaXNjdXNzaW9uIGFu ZCBmb3J3YXJkIHByb2dyZXNzIG9mIHRoaXMgd29yazpfX19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzEpIFRoZSBjaGFpcnMgaGF2ZSBy ZXZpZXdlZCB0aGUgTyBiaXQgZGVmaW5pdGlvbiBpbiBSRkMgODMwMC4gPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGF0IGRlZmluaXRpb24gaXMgYXQgYmVzdCBv cGVuIHRvIGludGVycHJldGF0aW9uIGFuZCB0aGVyZWZvcmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luY29tcGxldGUuJm5ic3A7IEZvciBleGFtcGxlLCB0aGUg Y2xlYXIgaW50ZW50aW9uIGlzIG9ubHkgdG8gbWFyazxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7cGFja2V0cyB3aGljaCBhcmUgaW50ZW5kZWQgZm9yIFNGQyBPQU0g YXQgdGhlIFNGQyBzZXJ2aWNlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtsYXllci4mbmJzcDsgQnV0IHRoYXQgaXMgbm90IHdoYXQgdGhlIGN1cnJlbnQgdGV4dCBz YXlzLiZuYnNwOyBUaGVyZSBpczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7YWxzbywgdW5mb3J0dW5hdGVseSwgYW1iaWd1aXR5IGFzIHRvIHdoYXQgY29uc3RpdHV0 ZXMgYW4gT0FNPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYWNr ZXQuJm5ic3A7IFNvIGl0IGlzIHJlYXNvbmFibGUgZm9yIGRvY3VtZW50cyB0byB1cGRhdGUgODMw MCB0bzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2xhcmlmeSB0 aGUgZXhhY3QgYXBwbGljYWJpbGl0eSBhbmQgYWN0aW9uIGZvciB0aGUgTy1iaXQuX19fXzxicj4N CiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfXyBfXzxi cj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsyKSBI b3dldmVyLCByZWxhdGVkIHRvIHBvaW50IDEpLCB3ZSBjYW4ndCBoYXZlIG11bHRpcGxlPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkb2N1bWVudHMgdXBkYXRpbmcg dGhlIGRlZmluaXRpb24gZGlmZmVyZW50bHkuJm5ic3A7IEFzIHN1Y2gsIHRoZTxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXV0aG9ycyBvZiB0aGUgU0ZDIGlPQU0g ZHJhZnQgYW5kIHRoZSBTRkMgbXVsdGktbGF5ZXItb2FtIGRyYWZ0PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtuZWVkIHRvIGNvbWUgdG9nZXRoZXIgYW5kIGZpZ3Vy ZSBvdXQgd2hhdCB0aGUgY2xhcmlmaWNhdGlvbiBpczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Zm9yIHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgYml0LiBXZSBkbyBu b3QgYmVsaWV2ZSBhcyBjaGFpcnMgdGhhdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ZWl0aGVyIG9mIHRoZXNlIGRvY3VtZW50cyBjYW4gbW92ZSBmb3J3YXJkIGZy b20gdGhlIFdHIHVudGlsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtzdWNoIGNsYXJpdHkgaGFzIGJlZW4gcmVhY2hlZC4gX19fXzxicj4NCiZndDsgPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfXyBfXzxicj4NCiZndDsgPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDszKSBSZWxhdGVkIHRvIHRoZSBT RkMgaU9BTSwgd2UgbmVlZCBhIGNsZWFyIGRlZmluaXRpb24gb2YgaU9BTS4gPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGVyZSBzZWVtIHRvIGJlIGRpZmZlcmVu Y2VzIGJldHdlZW4gdGhlIGRlZmluaXRpb25zIGluPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtwdWJsaXNoZWQgUkZDcywgdGhlIHVzYWdlICh3aGljaCBpcyBub3Qg YSBkZWZpbml0aW9uKSBpbiB0aGUgU0ZDPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtkcmFmdCwgYW5kIHRoZSB2YXJpb3VzIGlwcG0gZHJhZnRzLiZuYnNwOyBBbnkg c3VjaCBkZWZpbml0aW9uIHdpbGw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO25lZWQgdG8gYmUgdmV0dGVkIHdpdGggdGhlIGlwcG0gd29ya2luZyBncm91cC5fX19f PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19f IF9fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0FnYWluLCBpdCB3b3VsZCBiZSBnb29kIGlmIG1lbWJlcnMgb2YgdGhlIHdvcmtpbmcgZ3JvdXAg YmV5b25kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgdHdv IGF1dGhvciB0ZWFtcyBzcG9rZSB1cCBhYm91dCB0aGVpciByZWFkaW5ncyBvZiB0aGU8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RvY3VtZW50cywgYW5kIHRoZWly IHVuZGVyc3RhbmRpbmdzIG9mIHdoYXQgd2UgbmVlZC5fX19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1lvdXJzLF9fX188YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SmltIGFuZCBKb2Vs X19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtfXyBfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtfXyBfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtfXyBfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2ZjIG1haWxpbmcg bGlzdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4gJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2Zj QGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUy RnNmYyZhbXA7ZGF0YT0wNCU3QzAxJTdDamFtZXMubi5ndWljaGFyZCU0MGZ1dHVyZXdlaS5jb20l N0M5ZGIyYWIwYTkzODI0NjEzOTdmOTA4ZDllZjZmN2ZmNSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1 M2ExZDU1OTFmZWRjJTdDMSU3QzElN0M2Mzc4MDQwODQ0ODExOTYyNjQlN0NVbmtub3duJTdDVFdG cGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFo YVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9UjEyMHJQTWFZYmJSTE92NWpHQSUy QmlBSm90THE0Qk84ZmFoZzM0NTJuMlBVJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9u YW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG d3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2ZjJmFtcDtkYXRhPTA0JTdDMDEl N0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5 MDhkOWVmNmY3ZmY1JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3 QzYzNzgwNDA4NDQ4MTM1MjUxNCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdM akF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0Mz MDAwJmFtcDtzZGF0YT0lMkZrb3RFd29kZ09jd3dwUGdyTklJeVolMkJZNXRDM2JJaWVnS0FqenZv JTJCcEtJJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtzZmMgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL25hbTExLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmcl MkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzZmMmYW1wO2RhdGE9MDQlN0MwMSU3Q2phbWVzLm4uZ3Vp Y2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDOWRiMmFiMGE5MzgyNDYxMzk3ZjkwOGQ5ZWY2ZjdmZjUl N0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3ODA0MDg0NDgx MzUyNTE0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlq b2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRh PSUyRmtvdEV3b2RnT2N3d3BQZ3JOSUl5WiUyQlk1dEMzYklpZWdLQWp6dm8lMkJwS0klM0QmYW1w O3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJl Zj0iaHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2ZjJmFtcDtk YXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzlkYjJhYjBh OTM4MjQ2MTM5N2Y5MDhkOWVmNmY3ZmY1JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZl ZGMlN0MxJTdDMSU3QzYzNzgwNDA4NDQ4MTM1MjUxNCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhl eUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZD STZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT0lMkZrb3RFd29kZ09jd3dwUGdyTklJeVolMkJZNXRD M2JJaWVnS0FqenZvJTJCcEtJJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+Jmd0Ozxicj4NCiZndDsg PGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8v bmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJG d3d3LnZlcml6b24uY29tJTJGJmFtcDtkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQw ZnV0dXJld2VpLmNvbSU3QzlkYjJhYjBhOTM4MjQ2MTM5N2Y5MDhkOWVmNmY3ZmY1JTdDMGZlZThm ZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNDA4NDQ4MTM1MjUxNCU3 Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16 SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1PTmpmZzNH Wko1YXRyMXg4QlI3OTJYek8lMkY5cG96ak4yR0dKQkElMkY1aks4dyUzRCZhbXA7cmVzZXJ2ZWQ9 MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cudmVyaXpvbi5jb20vPC9hPiZndDs8YnI+DQom Z3Q7IDxicj4NCiZndDsgKkd5YW4gTWlzaHJhKjxicj4NCiZndDsgPGJyPg0KJmd0OyAvTmV0d29y ayBTb2x1dGlvbnMgQS8vcmNoaXRlY3QgLzxicj4NCiZndDsgPGJyPg0KJmd0OyAvRW1haWwgPGEg aHJlZj0ibWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5n eWFuLnMubWlzaHJhQHZlcml6b24uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpn eWFuLnMubWlzaHJhQHZlcml6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3lhbi5zLm1pc2hyYUB2 ZXJpem9uLmNvbTwvYT4mZ3Q7Ly88YnI+DQomZ3Q7IC88YnI+DQomZ3Q7IDxicj4NCiZndDsgL00g MzAxIDUwMi0xMzQ3PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC88YnI+DQomZ3Q7IDxicj4NCiZndDsg PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+LS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnd3dy52ZXJpem9uLmNvbSUyRiZhbXA7ZGF0YT0w NCU3QzAxJTdDamFtZXMubi5ndWljaGFyZCU0MGZ1dHVyZXdlaS5jb20lN0M5ZGIyYWIwYTkzODI0 NjEzOTdmOTA4ZDllZjZmN2ZmNSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdD MSU3QzElN0M2Mzc4MDQwODQ0ODEzNTI1MTQlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lq b2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4w JTNEJTdDMzAwMCZhbXA7c2RhdGE9T05qZmczR1pKNWF0cjF4OEJSNzkyWHpPJTJGOXBvempOMkdH SkJBJTJGNWpLOHclM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxMTU1Q0M7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcg Ym9yZGVyPSIwIiB3aWR0aD0iODEiIGhlaWdodD0iMTgiIHN0eWxlPSJ3aWR0aDouODQzN2luO2hl aWdodDouMTg3NWluIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHA6Ly9zczcudnp3LmNvbS9p cy9pbWFnZS9WZXJpem9uV2lyZWxlc3MvdnotbG9nby1lbWFpbCI+PC9zcGFuPjwvYT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDo5 Ljc1cHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+R3lhbiBNaXNocmE8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6OS43NXB0Ij48aT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWY7Y29sb3I6IzIyMjIy MiI+TmV0d29yayBTb2x1dGlvbnMgQXJjaGl0ZWN0Jm5ic3A7PC9zcGFuPjwvaT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGluZS1oZWlnaHQt YWx0OjkuNzVwdCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWY7Y29sb3I6IzIyMjIyMiI+RW1h aWwNCjxhIGhyZWY9Im1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tIiB0YXJnZXQ9Il9i bGFuayI+Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTwvYT48L3NwYW4+PC9pPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0O21zby1saW5lLWhlaWdodC1hbHQ6OS43NXB0Ij48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWYiPk0gMzAxIDUwMi0xMzQ3 PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRt bD4NCg== --_000_787AE7BB302AE849A7480A190F8B933035494AA7OPEXCAUBMA2corp_-- From nobody Wed Feb 16 05:08:20 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC3D3A082D for ; Wed, 16 Feb 2022 05:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, T_REMOTE_IMAGE=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 mo80B1-6zFcd for ; Wed, 16 Feb 2022 05:08:10 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20731.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e88::731]) (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 5FEA93A091B for ; Wed, 16 Feb 2022 05:08:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gcKp4dY9OW+7d8eXyukS6mI2IysBY+Sv2lDQ+RS3AK1gRTmtezyojKNdnEO22Z74JfYR8l5b9Lsym0CRS6X1MBB4GkKOST76a2IQ10aEe9s8+BU6bVNQaFD7BnVYinpcOzRD8Mer/Y42uWIGbSPoSbfmFHt3eIYuJM6tUKifPa0qpg2ksCweiwMWRAmqn0aVWFaVpnhXCv/VWKDtNjsA9mZSCJkujWjgAAT5ZRlQq4OHpyYbFNMO11ag412VjrUzbRyQ1+RUuUq4mxV5fwyBUMr2SiEcE1Exr/MSJXnVSNlIfeTKN3sP4FNyPDGSOS0ZABG+k3LjY47NBE2e6DAoPw== 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=27Dk1ixb99IpubvizA5b/pDR4rPDJscqDaJFQKrJd4U=; b=ga2KIzIKdxciWnJbBOyiF1SPjcqKNX7XdvV/4j2reIJGmk6Bha6lXbuDrlAErZwJKYsVV7Q6x5AsYITbGukus2YcLJaBek/g6yxgi0p5LKCVrRYY8f7Mgu9e/uSeN0UNpn8brCLbrJ90bB80qJ93Fva3QbsdVwNts6kIPd9VBNaZdxUMMNRGINwKtLkeCOWu6QicCGizcsczDehKcAI8LLc3vU+ucJ4Iwj50+ikZYbIYLbN4CAy9wFk8YyPaSE+bHgwSuPY031TYS0xAZDRLP7op0LwWmqCByqVmm/aAicv9FW4bqqBWK9MJBIy2GMUR8Djwt4BO6soGYjhqa7i4JA== 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=27Dk1ixb99IpubvizA5b/pDR4rPDJscqDaJFQKrJd4U=; b=E9JEZP6p1keL1oRJbTDCvbp+DCF9SturAFMWT7W0z3ZNFarpliiYRABPP9OAOlQi5M0gQ39Fi10kO37TgtU1MbEjRzhRezV30388QvjzopGv/uwWZvfArrvXGsLTj868UpA+5yjc6H4fEBrjY1sB37k0rwDigAktAy0IIfrzDXM= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by SJ0PR13MB5804.namprd13.prod.outlook.com (2603:10b6:a03:3eb::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.13; Wed, 16 Feb 2022 13:08:02 +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 13:08:02 +0000 From: James Guichard To: "Carlos Pignataro (cpignata)" CC: Gyan Mishra , Greg Mirsky , "sfc@ietf.org" Thread-Topic: [sfc] Progression of OAM work in the SFC WG Thread-Index: AdgYYtG+l/ju054uSCa0IEDodR5p4AAI1AYAAgogAwAADsqJgAAEeXQAAAD7PAAAFinEAAAVIwJwAAHkVoAAX/UxwA== Date: Wed, 16 Feb 2022 13:08:02 +0000 Message-ID: References: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.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=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2742a21-3cd0-4d91-0bf3-08d9f14d5d2b x-ms-traffictypediagnostic: SJ0PR13MB5804:EE_ x-ms-exchange-atpmessageproperties: SA|SL 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: mRfsTzfHjf4F7zBTHAga7EPTsATp+gzIrVTV+GZ2w1NHaDLGdcN/7GKwgko/VV8pRwyvI8ligTPtT2mzqa0ONqtw8bFdFiUj9aweZF6UmXqn3rz+zrI7Nehq39ucCq09TZkOQfoXCPTIOgsifiYLDIXL+NP4Nn2+BbJCwPlhxB/ODxDlKUZsIJLTuZswEeqcI40rbSEaRMpm3rPZXKk7OkxiKMsXgK5aLPqJUszn9wEb5zIO/zAtcoJFIEgp+UYnEuGctXyzofSMxul0XfR9tpEvWujHz2KV1F0m3k+EER3oF04h78utRvuebPj3XerDJDogVGYfmd5sCUwT3WLMKbXbcLkS6Jmizb68GxJ0dmRi1syuErdN1/G5/ASvd/bpUhqWblXft/3Rkk6cjLuaLwXn3B9ZzCOLyh6Amrr3f0U53llIwyvXB2cr9Wf5TxpxOcldMr+zlVqblD5De15Hd/E543avUk4kNK+wtyUi9/MZ2MbOu7oI2+fsWB0fVulUMvZNJpnfDzC3OCEooLf1gggyYB8FKSvU3B0Rcl5tNmd+M99SmzG0wLId6PyOlBrmmBune4B5+kpaPL+yd7pzESJgNos9jdovU9u4slmE7r3uj/7Wg+CnljNiYC1ejUcUXptQHHC8/4EOPc2mlxLJfiQX978SRQ8BfUn6G58MgoKoEb767bGUK7BjkfNkeomMHP4slyWvNGQSroNo3zoK7XCqhXs+xfdOeVD8Y/enYWW0BLGeOAkrLXbvD4HH/bcaX2Wdc9T5S/ThwKQRxvFiRPg0pvlvDlIdfH8ZuET+UTHrdoQXQHxwdGvvyQck3Syw3qdd3LMhz5JdjyoPaMzUrr98gpweSsOkxlk5YZ2vOj4jxByskigz26bBeeh7000l 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)(508600001)(83380400001)(53546011)(9686003)(66946007)(6506007)(86362001)(40140700001)(7696005)(71200400001)(6916009)(55016003)(316002)(966005)(166002)(33656002)(54906003)(8936002)(38100700002)(76116006)(8676002)(66446008)(64756008)(5660300002)(186003)(30864003)(4326008)(9326002)(38070700005)(52536014)(2906002)(66476007)(66556008)(122000001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?S0RuL0trU2NZN3JLMUhhaWVnWWZMdnMwMzgyenBRL0tNYlBRODB5c3dI?= =?iso-2022-jp?B?Wmtkbjdvc0FpOWdVeGExSWkwTzRwSGhtVkRHdEpXMk01VDRyS3V4V0Nl?= =?iso-2022-jp?B?YVllYjRFR1cyZXpIWnFGRjl3SnhrRTZVcHh4dXRLc080TnZoSXVZdWpk?= =?iso-2022-jp?B?VExDZUdSZ2RQaHNTcmQrc3VBNmhkRHA0RlpHSnlGdGEyWUhkcko3dVFV?= =?iso-2022-jp?B?U3Rhcm1qVk56RW9XUmoyUE1vY0h2TVY5UWtvcXdwWk51UllucU0yMTBU?= =?iso-2022-jp?B?UmlyTkgwSG1EaDUrcGNPaS9tbGhkaEFKUTU2bW9BTUhzbUw3NEpsaGFM?= =?iso-2022-jp?B?R3R5UUJFQktCVG5ZMjJHL2UxN3JGSDRSL0pvMFE1bEs0OHl5aWlkRlpi?= =?iso-2022-jp?B?c21uNFY4dWFha0pObHhKMng4ZEVvV2JJajBCdDI1UWRnVFZhV1hMaEtr?= =?iso-2022-jp?B?Z0Q5V01NSkNYV1VWZTFhVm9KblNBYzVSNFFpSTlWNlpoZy83TjVBNUZ0?= =?iso-2022-jp?B?M0V4aHNBMUx5M2IrU3YvV1I1KzRwNmQ1d2tVMTdjN05ORFdueE1pQllq?= =?iso-2022-jp?B?N0xqSERaWFFrWEJReEVaUU9XYlY0UmF5WjdSREQzTzlJV3FzSVZ1ZENX?= =?iso-2022-jp?B?QlhUMWphcm9YSkZoRzQ2M3RXL3J1Zng2d0k1ZEl3b2VmYlVMdzFOVkQ3?= =?iso-2022-jp?B?akFaakJlMWVqbmhDWitmSDJFU1ZkWUJHc3B2MzdrSVBIK2NWRHBZV3NW?= =?iso-2022-jp?B?SUtuL0tVNFI2TGorbEEzbkhJMHJJWVBwZ244WHN0TUkrZSt2OCs0SGI4?= =?iso-2022-jp?B?eU1VYjBCVnVPb1VHL2ZMcGxheWk5RWsyMHk5aGp0NHd1aFhha3UxTDgw?= =?iso-2022-jp?B?citrc2RLaUViem9BMy9acGNGK3pSRit3K0Z0K2Eya2NpK2pYOGJubWFp?= =?iso-2022-jp?B?VWk3SEFJNlhSNFc4Y0JjblFrdnV1SUsrRFFMZk1aaDdQOVVOelJiZ1NN?= =?iso-2022-jp?B?NXJKRUpCclhTd21TSkk2a3JvSUY0RU1ONDVJMFI2WTIrY3p5UHNlSmdT?= =?iso-2022-jp?B?MHB6ZmNYRXFHVlpVcE0vTzU3UXJOWDhRV2xLT2ZxMmd0alBrWDZmd1Vw?= =?iso-2022-jp?B?Y2pSVllxbUN4d2kydXUxRUxMSTBHRGFLZDg2c3BFTFpYTUJNR3hrU29B?= =?iso-2022-jp?B?NVV1Wnc0bmthT1RhZVJmdit0Tks2a2VlZFRRS0RqcmRUeTZJRmFac3Ru?= =?iso-2022-jp?B?SXFxS2Mzc2cvTjIxSzA3MjhiMFhPWldLejhBRVZFRmh1Y2FFZVczWVNM?= =?iso-2022-jp?B?Y0QzSDA1VVZZNzVjR0lodHZOSGVrRW1DZ25TR2dQRGIvakxLNHlzamJD?= =?iso-2022-jp?B?ekJ4cmxLZWdTOTBKNHg4c1lhK1ZoUzJCU0lBTzVBWHc1SGphTGc2bEg4?= =?iso-2022-jp?B?dExUaSs4dHFxdksvZ0UxeFc5NHlUckJTdDRQcFJYbFlYM2NGR2RlRGdx?= =?iso-2022-jp?B?UG5hcHF5Tk9ZVDdleEN2dDF0azVuNEdRV1pSbm5pYkpCVzN4M0tMb1k1?= =?iso-2022-jp?B?c0k0OUNjOHhEcytTQjgzOGM0YUNtcTloeExGSWRhelpiTDJJRk1PZjNQ?= =?iso-2022-jp?B?UEorb3IzZmFmM291c0R5SFdrMGNtVWE1cy9pMjVndEJjK3R0UnNWejdV?= =?iso-2022-jp?B?RU4wWGpXdnpqNjRGSTlVc2hSem9va0p0NVE4VTBiV0xid3BFelB2UWdN?= =?iso-2022-jp?B?emxTODNQN0gwSnB1QTZSRzh0SjBKY3FiN0pNOEp1OEtrUDFiMUM0bGJB?= =?iso-2022-jp?B?RzJla1k2QjkwODA1QlBtSC9xRHRDNkd2NmNSenlLYjA1MjJQK0VXUnl6?= =?iso-2022-jp?B?MkVZZDdQeDl1YVREZG84QWxNaVg4OVhIWTJ4RGo1M0hnZ28ycjNZQStq?= =?iso-2022-jp?B?OCtSL292WFMvcVpEMmxGb1RkZ1pVcGdTZnUyaTZJQk1zV1hFc29MREJL?= =?iso-2022-jp?B?RUlqL2l3MDkvVVhKNmdydGpjOW9hMml6VHF4UkgrWGNDSEZRcGR0OFlD?= =?iso-2022-jp?B?V1ZtcllOM3VmK0ZsTFRPNXpha2NxUkwrSWptUWxqazg3TS9yZUd4QUxm?= =?iso-2022-jp?B?MzBBOGxGQ1BGamtqTHZ2ZWpkUUlaeE9xc0svaEVRNnpwalZkR1pJdHEw?= =?iso-2022-jp?B?TVYxeE5vTEJ4enRpUm9FNkpyaDgyRzlXMFk3aDZlUUZhNVJqQm5BZDFz?= =?iso-2022-jp?B?MVo5Yk1uZU93Nzdvd2Q0Ymp1TUdITzNOa2hGSE1tKzJwKzI5aUdsYTdH?= =?iso-2022-jp?B?RGdKQW15V1oxTXhQUUtSUktMT0E1dlB0WXdlbnRGNmdYZE1TV05vY3N0?= =?iso-2022-jp?B?eDNiNzg1c1hYR1ByUHNZeFFlU2lVMEZUdGtrTHFLMzhRSTltWG50UFpN?= =?iso-2022-jp?B?Vzh3ZFMrbWs3ckNXcTQ1ejNqNW9VMFRNbHhzPQ==?= Content-Type: multipart/alternative; boundary="_000_MN2PR13MB420626AB9D53F319BC827ADAD2359MN2PR13MB4206namp_" 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: f2742a21-3cd0-4d91-0bf3-08d9f14d5d2b X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2022 13:08:02.5951 (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: Wi5UGYfGCOGsRh8ILSiO8sqNebsyXEE5ChSLZgs2VJAu4NUHm4s726eDOQUUaX0UamufJYbpAAr9Eida7zvGGw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR13MB5804 Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 13:08:16 -0000 --_000_MN2PR13MB420626AB9D53F319BC827ADAD2359MN2PR13MB4206namp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Carlos, Thank you for the clarification. Your response highlights quite nicely the = issues that the chairs are trying to bring to the WGs attention - maybe res= ponses to the following questions will help settle this: 1. Should the O-bit be set ONLY for OAM packets that are specific to the= SFC service layer? 2. Should the O-bit be set in the cases where a solution uses the next p= rotocol field in the NSH header? In this case what is the purpose of the O-= bit given that the next protocol field already indicates the expected behav= ior? 3. If the O-bit is set is it the expected behavior to find relevant SFC = service layer OAM information in the context headers? Thanks! Jim From: Carlos Pignataro (cpignata) Sent: Monday, February 14, 2022 10:06 AM To: James Guichard Cc: Gyan Mishra ; Greg Mirsky ; sfc@ietf.org Subject: Re: [sfc] Progression of OAM work in the SFC WG Thanks - I=1B$B!G=1B(Bd expect SFC OAM layer packets only, and would also e= xpect a model that works equally with multilayer-oam approaches or with exi= sting OAMs. Thanks! Carlos. 2/14/22 =1B$B8aA0=1B(B9:28=1B$B!"=1B(BJames Guichard >=1B$B$N%a!<%k=1B(B: Hi Carlos, Some responses in-line =1B$B!D=1B(B From: sfc > On Behalf Of = Carlos Pignataro (cpignata) Sent: Sunday, February 13, 2022 11:07 PM To: Gyan Mishra > Cc: Greg Mirsky >; sfc@= ietf.org Subject: Re: [sfc] Progression of OAM work in the SFC WG Replying to this specific email in the thread, only because it is the lates= t one at this point in time, but bundling comments from various places on t= he thread. Please find some follow-up comments and questions marked =1B$B!H= =1B(BCMP=1B$B!I=1B(B, indicating the =1B$B!H=1B(BFrom=1B$B!I=1B(B, and orga= nized chronologically: James N Guichard >: 1) The chairs have reviewed the O bit definition in RFC 8300. That definit= ion is at best open to interpretation and therefore incomplete. For exampl= e, the clear intention is only to mark packets which are intended for SFC O= AM at the SFC service layer. But that is not what the current text says. = There is also, unfortunately, ambiguity as to what constitutes an OAM packe= t. So it is reasonable for documents to update 8300 to clarify the exact a= pplicability and action for the O-bit. CMP: It is unclear to me what exact issues the chairs are calling out. Ther= e are two issues mentioned: CMP: 1. "But that is not what the current text says.=1B$B!I=1B(B -> what do= es the text say precisely? Can you point to the specific RFC 8300 text tha= t is believed to be incomplete, and a detailed use case that showcases the = potential issue? An extrapolated counter-example just to make a point: the = text does not say what days of the week OAM packets can be marked, yet the= re=1B$B!G=1B(Bs an expectation that they will work Mondays and Saturdays al= l the same - even holidays. Jim> Currently RFC8300 says =1B$B!H=1B(BThe O bit MUST be set for OAM packe= ts and MUST NOT be set for non-OAM packets=1B$B!I=1B(B. The first issue is = does this mean the O bit should be set for ALL OAM packets regardless of wh= ether they belong to the NSH service plane? Or should it only be set for SF= C OAM packets? And what exactly is an SFC OAM packet as the earlier referen= ce to RFC6291 is just a generate set of guidelines for the use of the term = OAM. The second issue is that if that O bit is set then Greg=1B$B!G=1B(Bs d= ocument is in conflict with IOAM as both use the next protocol field and ev= en if the O bit is set it is meaningless as the protocol action is based so= lely on the setting of the next protocol field. So in this case can their s= olutions simply ignore what RFC 8300 says e.g. MUST set the O bit? Or if th= ey set the O bit to be conformant to what RFC 8300 says then do we need cle= arer rules stating what to do if the next protocol field is NOT an OAM next= protocol such as the context headers should then be examined? CMP: 2. What specifically is the ambiguity with what an OAM packet is? Plea= se grep the RFC series for =1B$B!H=1B(Boam packet=1B$B!I=1B(B, it is not a = new term. CMP: Net-net, O-bit=3D1, OAM packet. Jim> ambiguity is whether it is only SFC OAM packets that are being discuss= ed or ALL OAM packets nothing that some might be at the service layer and s= ome might not. Jim 2) However, related to point 1), we can't have multiple documents updating = the definition differently. As such, the authors of the SFC iOAM draft and= the SFC multi-layer-oam draft need to come together and figure out what th= e clarification is for the definition of that bit. We do not believe as cha= irs that either of these documents can move forward from the WG until such = clarity has been reached. CMP: If there is still believed to be an ambiguity or a clear opportunity f= or improving the definition, I agree with consolidating that update. I had = suggested before that if such new text or real clarification is agreed, a s= eparate document that only makes that O-bit clarification is the most clear= and clean way to go. That doc should be a one-pager or less. I=1B$B!G=1B(B= d be happy to contribute to that minimal doc, if it is shown to be needed. CMP: For completeness also, the "SFC multi-layer-oam=1B$B!I=1B(B document h= as many outstanding issues besides the O-bit. Greg Mirsky > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I unders= tand these documents, the Active SFC OAM and IOAM are identified by the res= pective values for the NSH Next Protocol field (to be assigned by IANA). CMP: There is a major issue with the sentence above. Active SFC OAM (as a c= ategory), as per RFC 8300, needs to be identified by setting the O-bit. No = way around that based on RFC 8300. However, the text "the Active SFC OAM=1B= $B!I=1B(B creates confusion since it refer to a specific OAM protocol which= has the same name as a the category as well. That name collision is quite = unfortunate in my opinion. At the same time, so far no OAM-specific meta data TLV has been defined. Th= us, it appears that one way forward could be to not involve the O bit in th= e active SFC OAM or IOAM altogether. In other words, to deprecate the NSH O= bit. CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM proto= cols. Those can be encapsulated in IP, in which the Next-Protocol indicates= IP - and (as per RFC 8300) the O-bit is set to indicate an OAM packet. CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols a= lready included in an RFC. CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM= . CMP: This expired I-D yet implemented in open source uses the O-bit: https:= //www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt Gyan Mishra > I agree that what makes sense to me as a path forward is to deprecate the O= bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC Multilayer= OAM and SFC IOAM are identified by the respective values for the NSH Next = Protocol field (to be assigned by IANA), as well as so far no OAM-specific = meta data TLV has been yet defined. CMP: What is the =1B$B!H=1B(BSFC Multilayer OAM=1B$B!I=1B(B? CMP: The O-bit (reading RFC 8300) does not indicate if there is OAM Metadat= a. It indicates an OAM packet. "Joel M. Halpern" > As far as I can tell, if we deprecate the O-bit and rely on the next protoc= ol field, we are saying that in practice (not by rule) NSH metadata can not= be used for OAM. That's fine with me as long as we agree on that. CMP: I do not fully follow this. Can you explain the relationship of the O-= bit with Metadata? CMP: Here=1B$B!G=1B(Bs an example: RFC 8924 shows ICMP as Active OAM. The S= FC next protocol is IP, the IP next protocol is ICMP, the O-bit needs to be= set. CMP: Consider the following document, independent submission and in the RFC= Publication queue already: CMP: https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timesta= mp/ CMP: Is a Timestamp in Metadata an OAM element? CMP: Consider this proposal https://datatracker.ietf.org/doc/draft-mirsky-s= fc-pmamm/ CMP: Where the base header borrows a bit for an OAM function. CMP: Neither of those have any impact on the O-bit. Greg Mirsky > I agree that, as we find SFC NSH now, no OAM metadata has been defined. It = appears to me that deprecating the O bit does not affect any of the already= defined mechanisms in the SFC NSH. CMP: It actually does, see my example above. I think that if a new, for example, MD Type =3D 2 TLV that is used for any = OAM functionality to be proposed in the future, deprecated the O bit would = not prevent using such NSH TLV. CMP: I agree with this - because there is no correlation between MD Type fi= eld and O-bit as defined. Best, Carlos. 2/13/22 =1B$B8a8e=1B(B12:32=1B$B!"=1B(BGyan Mishra >=1B$B$N%a!<%k=1B(B: Hi Joel I am in agreement as well with what you have stated that once the O bit is = deprecated that NSH metadata cannot be used for OAM and that we would have = to now from that point forward rely on the next protocol field as we will b= e doing for SFC Multilayer and SFC IOAM drafts as well as will have backwar= ds compatible with any already existing defined mechanisms in SFC NSH. I don=1B$B!G=1B(Bt see any issues or impact with moving forward. Kind Regards Gyan On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky > wrote: Hi Joel, I agree that, as we find SFC NSH now, no OAM metadata has been defined. It = appears to me that deprecating the O bit does not affect any of the already= defined mechanisms in the SFC NSH. I think that if a new, for example, MD = Type =3D 2 TLV that is used for any OAM functionality to be proposed in the= future, deprecated the O bit would not prevent using such NSH TLV. What do you think? Regards, Greg On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern > wrote: There is an implication of deprecating the O-bit that I would like to hear from more WG participants about. As far as I can tell, if we deprecate the O-bit and rely on the next protocol field, we are saying that in practice (not by rule) NSH metadata can not be used for OAM. That's fine with me as long as we agree on that. Yours, Joel On 2/13/2022 2:52 AM, Gyan Mishra wrote: > > Hi Jim, Joel & SFC WG, > > I agree that the RFC 8300 definition of O bit is incomplete and not > clear as to its intended use. > > That is a problem that I agree needs to be rectified. > > I understand that we need to get this resolved before we can progress > Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM. > > I agree that what makes sense to me as a path forward is to deprecate > the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC > Multilayer OAM and SFC IOAM are identified by the respective values for > the NSH Next Protocol field (to be assigned by IANA), as well as so far > no OAM-specific meta data TLV has been yet defined. > > So we have I believe solid solution and path forward and I support > deprecating the O bit. > > Kind Regards > > Gyan > > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky > >> wrote: > > Thank you, Jim and Joel, for guiding the SFC OAM work and pointing > out the issue that must be addressed. > > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I > understand these documents, the Active SFC OAM and IOAM are > identified by the respective values for the NSH Next Protocol field > (to be assigned by IANA). At the same time, so far no OAM-specific > meta data TLV has been defined. Thus, it appears that one way > forward could be to not involve the O bit in the active SFC OAM or > IOAM altogether. In other words, to deprecate the NSH O bit. > > I greatly appreciate your comments on the proposal to deprecate the > NSH O bit. > > Regards, > Greg > > On Wed, Feb 2, 2022 at 10:36 AM James Guichard > > >> wrote: > > Hi WG:____ > > __ __ > > Having reviewed all of the OAM related documents in our WG, the > chairs would like to provide a few comments to hopefully > generate discussion and forward progress of this work:____ > > __ __ > > 1) The chairs have reviewed the O bit definition in RFC 8300. > That definition is at best open to interpretation and therefore > incomplete. For example, the clear intention is only to mark > packets which are intended for SFC OAM at the SFC service > layer. But that is not what the current text says. There is > also, unfortunately, ambiguity as to what constitutes an OAM > packet. So it is reasonable for documents to update 8300 to > clarify the exact applicability and action for the O-bit.____ > > __ __ > > 2) However, related to point 1), we can't have multiple > documents updating the definition differently. As such, the > authors of the SFC iOAM draft and the SFC multi-layer-oam draft > need to come together and figure out what the clarification is > for the definition of that bit. We do not believe as chairs that > either of these documents can move forward from the WG until > such clarity has been reached. ____ > > __ __ > > 3) Related to the SFC iOAM, we need a clear definition of iOAM. > There seem to be differences between the definitions in > published RFCs, the usage (which is not a definition) in the SFC > draft, and the various ippm drafts. Any such definition will > need to be vetted with the ippm working group.____ > > __ __ > > Again, it would be good if members of the working group beyond > the two author teams spoke up about their readings of the > documents, and their understandings of what we need.____ > > __ __ > > Yours,____ > > Jim and Joel____ > > __ __ > > __ __ > > __ __ > > _______________________________________________ > sfc mailing list > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > > -- > > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /Email gyan.s.mishra@verizon.com >// > / > > /M 301 502-1347 > > / > > -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_MN2PR13MB420626AB9D53F319BC827ADAD2359MN2PR13MB4206namp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Carlos,

 =

Thank you for the clarif= ication. Your response highlights quite nicely the issues that the chairs a= re trying to bring to the WGs attention – maybe responses to the following questions will help settle this:

 =

  1. Should the O-bit be set ONLY for OAM pack= ets that are specific to the SFC service layer?
  2. Should the O-bit be set in the cases where a s= olution uses the next protocol field in the NSH header? In this case what is the purpose of the O-bit given that the n= ext protocol field already indicates the expected behavior?
  3. If the O-bit is set is it the expe= cted behavior to find relevant SFC service layer OAM information in the context headers?

 =

Thanks!

 =

Jim

 =

From: Carlos Pignataro (cpignata) &l= t;cpignata@cisco.com>
Sent: Monday, February 14, 2022 10:06 AM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Greg Mirsky <gregi= mirsky@gmail.com>; sfc@ietf.org
Subject: Re: [sfc] Progression of OAM work in the SFC WG<= /span>

 

Thanks — I=1B$B!G=1B(Bd expect SFC OAM layer p= ackets only, and would also expect a model that works equally with multilay= er-oam approaches or with existing OAMs.

 

Thanks!

 

Carlos.



2/14/22 =1B$B8aA0=1B(B9:= 28=1B$B!"=1B(BJames Guichard <james.n.guichard@futurewei.com><= span lang=3D"ZH-CN">=1B$B$N%a!<%k=1B(B:

 

Hi Carlos,

 

Some responses in-line =1B$B!D=1B(B

 

From: sfc <sfc-bounces@ietf.org> On Behalf Of Carlos Pignataro (cpignata)
Sent: Sunday, Febr= uary 13, 2022 11:07 PM
To: Gyan Mishra &l= t;hayabusagsm@gmail.com> Cc: Greg Mirsky &l= t;gregimirsky@gmail.com>; sfc@ietf.org
Subject: Re: [sfc]= Progression of OAM work in the SFC WG

 

Replying to this specific email in the thread, only = because it is the latest one at this point in time, but bundling comments f= rom various places on the thread. Please find some follow-up comments and q= uestions marked =1B$B!H=1B(BCMP=1B$B!I=1B(= B, indicating the =1B$B!H=1B(BFrom=1B$B!I=1B(B, and organi= zed chronologically: 

 

James N Guichard <james.n.guichard@futurewei.com>:

 

1) The chairs have reviewed the O bit definition in= RFC 8300.  That definition is at best open to interpretation and ther= efore incomplete.  For example, the clear intention is only to mark packets which are intended for SFC OAM at the SFC service = layer.  But that is not what the current text says.  There is als= o, unfortunately, ambiguity as to what constitutes an OAM packet.  So = it is reasonable for documents to update 8300 to clarify the exact applicability and action for the O-bit.

 

CMP: It is unclear to me what exact issues the chair= s are calling out. There are two issues mentioned:

CMP: 1. "But that is not what the current text = says.=1B$B!I=1B(B —> what does the tex= t say precisely?  Can you point to the specific RFC 8300 text that is = believed to be incomplete, and a detailed use case that showcases the potential issue? An extrapolated counter-example just to make a point:= the text does not  say what days of the week OAM packets can be marke= d, yet there=1B$B!G=1B(Bs an expectation that t= hey will work Mondays and Saturdays all the same — even holidays.

 

Jim> Currently RFC8300 says =1B$B!H=1B(BThe O bit MUST be set for=
 OAM packets and MUST NOT be set for non-OAM packets=1B$B!I=1B(B. T=
he first issue is does this mean the O bit should be set for ALL OAM packet=
s regardless of whether they belong to the NSH service plane? Or should it =
only be set for SFC OAM packets? And what exactly is an SFC OAM packet as t=
he earlier reference to RFC6291 is just a generate set of guidelines for th=
e use of the term OAM. The second issue is that if that O bit is set then G=
reg=1B$B!G=1B(Bs document is in conflict with IOAM as both use the next pro=
tocol field and even if the O bit is set it is meaningless as the protocol =
action is based solely on the setting of the next protocol field. So in thi=
s case can their solutions simply ignore what RFC 8300 says e.g. MUST set t=
he O bit? Or if they set the O bit to be conformant to what RFC 8300 says t=
hen do we need clearer rules stating what to do if the next protocol field =
is NOT an OAM next protocol such as the context headers should then be exam=
ined?

 

 

CMP: 2. What specifically is the ambiguity with what= an OAM packet is? Please grep the RFC series for =1B$B!H=1B(Boam packet=1B$= B!I=1B(B, it is not a new term. 

CMP: Net-net, O-bit=3D1, OAM packet. 

 

Jim> ambiguity is whether it is only SFC OAM pac= kets that are being discussed or ALL OAM packets nothing that some might be= at the service layer and some might not.

 

Jim

 

2) However, related to point 1), we can't have mult= iple documents updating the definition differently.  As such, the auth= ors of the SFC iOAM draft and the SFC multi-layer-oam draft need to come together and figure out what the clarification is for t= he definition of that bit. We do not believe as chairs that either of these= documents can move forward from the WG until such clarity has been reached= .

 

CMP: If there is still believed to be an ambiguity o= r a clear opportunity for improving the definition, I agree with consolidat= ing that update. I had suggested before that if such new text or real clari= fication is agreed, a separate document that only makes that O-bit clarification is the most clear and clean way t= o go. That doc should be a one-pager or less. I=1B$B!G= =1B(Bd be happy to contribute to that minimal doc, if it is shown to= be needed.

 

CMP: For completeness also, the "SFC multi-laye= r-oam=1B$B!I=1B(B document has many outstanding= issues besides the O-bit.

 

Greg Mirsky <gregimirsky@gmail.com>

 

I've reviewed our SFC OAM documents and draft-ietf-s= fc-nsh-tlv. As I understand these documents, the Active SFC OAM and IOAM ar= e identified by the respective values for the NSH Next Protocol field (to b= e assigned by IANA).

 

CMP: There is a major issue with the sentence above.= Active SFC OAM (as a category), as per RFC 8300, needs to be identified by= setting the O-bit. No way around that based on RFC 8300. However, the text= "the Active SFC OAM=1B$B!I=1B(B creates confusion since it refer to a specific OAM protocol which has the = same name as a the category as well. That name collision is quite unfortuna= te in my opinion.

 

At the same time, so far no OAM-specific meta data T= LV has been defined. Thus, it appears that one way forward could be to not = involve the O bit in the active SFC OAM or IOAM altogether. In other words,= to deprecate the NSH O bit.

 

CMP: RFC 8924 already includes ICMP and BFD as examp= le SFC Action OAM protocols. Those can be encapsulated in IP, in which the = Next-Protocol indicates IP — and (as per RFC 8300) the O-bit is set = to indicate an OAM packet.

CMP: The proposal of deprecating the O-bit breaks th= ose SFC OAM protocols already included in an RFC.

CMP: That proposal of deprecating the O-bit also bre= aks Section 4.1 of IOAM.

CMP: This expired I-D yet implemented in open source= uses the O-bit: https://www.ietf.org/archive/id/dra= ft-penno-sfc-trace-03.txt 

 

 

Gyan Mishra <hayabusagsm@gmail.com>

 

I agree that what makes sense to me as a path forwar= d is to deprecate the O bit and not use in SFC Multilayer OAM and SFC IOAM,= as both SFC Multilayer OAM and SFC IOAM are identified by the re= spective values for the NSH Next Protocol field (to be assigned by IANA), as well as so far no OAM-specific meta data TLV = has been yet defined.

 

CMP: What is the =1B$B!H=1B(BSFC Multilayer OAM=1B$B!I=1B(B?=

CMP: The O-bit (reading RFC 8300) does not indicate = if there is OAM Metadata. It indicates an OAM packet.

 

 

"Joel M. Halpern" <jmh@joelhalpern.com>

 

As far as I can tell, if we deprecate the O-bit and = rely on the next protocol field, we are saying that in practice (not by rul= e) NSH metadata can not be used for OAM.  That's fine with me as long = as we agree on that.

 

CMP: I do not fully follow this. Can you explain the= relationship of the O-bit with Metadata?

CMP: Here=1B$B!G=1B(Bs a= n example: RFC 8924 shows ICMP as Active OAM. The SFC next protocol is IP, = the IP next protocol is ICMP, the O-bit needs to be set. 

 

CMP: Consider the following document, independent su= bmission and in the RFC Publication queue already:

CMP: Is a Timestamp in Metadata an OAM element? = ;

 

CMP: Where the base header borrows a bit for an OAM = function.

 

CMP: Neither of those have any impact on the O-bit.&= nbsp;

 

 

Greg Mirsky <gregimirsky@gmail.com>

 

I agree that, as we find SFC NSH now, no OAM metadat= a has been defined. It appears to me that deprecating the O bit does not af= fect any of the already defined mechanisms in the SFC NSH.

 

CMP: It actually does, see my example above.




I think that if a new, for example, MD Type =3D 2 TL= V that is used for any OAM functionality to be proposed in the future,= deprecated the O bit would not prevent using such NSH TLV.=

 

CMP: I agree with this —<= /span> because there is no correlation between MD Type field and O-bit as d= efined.

 

Best,

 

Carlos.

 

 




2/13/22 <= /span>=1B$B8a8e=1B(B12:32= =1B$B!"=1B(BGyan Mishra <hayabusagsm@gmail.com>=1B$B$N%a!<%k=1B(B:

 

Hi Joel

 

I am in agreement as well with what you have stated = that once the O bit is deprecated that NSH metadata cannot be used for OAM = and that we would have to now from that point forward rely on the next prot= ocol field as we will be doing for SFC Multilayer and SFC IOAM drafts as well as will have backwards compatib= le with any already existing defined mechanisms in SFC NSH.  

 

I don=1B$B!G=1B(Bt see a= ny issues or impact with moving forward.

 

Kind Regards 

 

Gyan

 

On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky <gregimirsky@gmail.com> wrote:<= o:p>

Hi Joel, =

I agree that, as we find SFC NSH now, no OAM metadat= a has been defined. It appears to me that deprecating the O bit does not af= fect any of the already defined mechanisms in the SFC NSH. I thin= k that if a new, for example, MD Type =3D 2 TLV that is used for any OAM functionality to be proposed in the future, = deprecated the O bit would not prevent using such NSH TLV.<= /p>

What do you think?

 

Regards,

Greg

 

On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:

There is an implication of deprecating the O-bit tha= t I would like to 
hear from more WG participants about.

As far as I can tell, if we deprecate the O-bit and rely on the next 
protocol field, we are saying that in practice (not by rule) NSH 
metadata can not be used for OAM.  That's fine with me as long as we 
agree on that.

Yours,
Joel

On 2/13/2022 2:52 AM, Gyan Mishra wrote:
> 
> Hi Jim, Joel & SFC WG,
> 
> I agree that the RFC 8300 definition of O bit is incomplete and not 
> clear as to its intended use.
> 
> That is a problem that I agree needs to be rectified.
> 
> I understand that we need to get this resolved before we can progress<= span class=3D"apple-converted-space"> 
> Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM.
> 
> I agree that what makes sense to me as a path forward is to deprecate<= span class=3D"apple-converted-space"> 
> the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC<= span class=3D"apple-converted-space"> 
> Multilayer OAM and SFC IOAM are identified by the respective values fo= r 
> the NSH Next Protocol field (to be assigned by IANA), as well as so fa= r 
> no OAM-specific meta data TLV has been yet defined.
> 
> So we have I believe solid solution and path forward and I support 
> deprecating the O bit.
> 
> Kind Regards
> 
> Gyan
> 
> On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky <gregimirsky@gmail.com 
> <mailto:= gregimirsky@gmail.com>> wrote:
> 
>     Thank you, Jim and Joel, for guiding the SFC OAM wo= rk and pointing
>     out the issue that must be addressed.
> 
>     I've reviewed our SFC OAM documents and draft-ietf-= sfc-nsh-tlv. As I
>     understand these documents, the Active SFC OAM and = IOAM are
>     identified by the respective values for the NSH Nex= t Protocol field
>     (to be assigned by IANA). At the same time, so far = no OAM-specific
>     meta data TLV has been defined. Thus, it appears th= at one way
>     forward could be to not involve the O bit in the ac= tive SFC OAM or
>     IOAM altogether. In other words, to deprecate the N= SH O bit.
> 
>     I greatly appreciate your comments on the proposal = to deprecate the
>     NSH O bit.
> 
>     Regards,
>     Greg
> 
>     On Wed, Feb 2, 2022 at 10:36 AM James Guichard
>     <james.n.guichard@futurewei.com
>     <mailto:james.n.guichard@futurewei.com>> wrot= e:
> 
>         Hi WG:____
> 
>         __ __
> 
>         Having reviewed all of the OAM relate= d documents in our WG, the
>         chairs would like to provide a few co= mments to hopefully
>         generate discussion and forward progr= ess of this work:____
> 
>         __ __
> 
>         1) The chairs have reviewed the O bit= definition in RFC 8300. =
>         That definition is at best open to in= terpretation and therefore
>         incomplete.  For example, the cl= ear intention is only to mark
>         packets which are intended for SFC OA= M at the SFC service
>         layer.  But that is not what the= current text says.  There is
>         also, unfortunately, ambiguity as to = what constitutes an OAM
>         packet.  So it is reasonable for= documents to update 8300 to
>         clarify the exact applicability and a= ction for the O-bit.____
> 
>         __ __
> 
>         2) However, related to point 1), we c= an't have multiple
>         documents updating the definition dif= ferently.  As such, the
>         authors of the SFC iOAM draft and the= SFC multi-layer-oam draft
>         need to come together and figure out = what the clarification is
>         for the definition of that bit. We do= not believe as chairs that
>         either of these documents can move fo= rward from the WG until
>         such clarity has been reached. ____ > 
>         __ __
> 
>         3) Related to the SFC iOAM, we need a= clear definition of iOAM. 
>         There seem to be differences between = the definitions in
>         published RFCs, the usage (which is n= ot a definition) in the SFC
>         draft, and the various ippm drafts.&n= bsp; Any such definition will
>         need to be vetted with the ippm worki= ng group.____
> 
>         __ __
> 
>         Again, it would be good if members of= the working group beyond
>         the two author teams spoke up about t= heir readings of the
>         documents, and their understandings o= f what we need.____
> 
>         __ __
> 
>         Yours,____
> 
>         Jim and Joel____
> 
>         __ __
> 
>         __ __
> 
>         __ __
> 
>         _____________________________________= __________
>         sfc mailing list
>         sfc@ietf.org <mailto:sfc@ietf.= org>
>         https://www.ietf.org/m= ailman/listinfo/sfc
>         <https://www.ietf.o= rg/mailman/listinfo/sfc>
> 
>     _______________________________________________
>     sfc mailing list
>     s= fc@ietf.org <mailt= o:sfc@ietf.org> >     https://www.ietf.org/mailman/listinf= o/sfc
>     <https://www.ietf.org/mailman/lis= tinfo/sfc>
> 
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /Email gyan.s.mishra@verizon.com=  <mailto:gyan.s.mishra@veriz= on.com>//
> /
> 
> /M 301 502-1347
> 
> /
> 
> 

-- 

Gyan Mishra

Network Solutions Architect <= /p>

M 301 502-1347

 

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

 

 

--_000_MN2PR13MB420626AB9D53F319BC827ADAD2359MN2PR13MB4206namp_-- From nobody Wed Feb 16 05:16:11 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAFD3A12E4 for ; Wed, 16 Feb 2022 05:16:09 -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_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 XY8YIAEjlMIZ for ; Wed, 16 Feb 2022 05:16:04 -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 7D36D3A12E9 for ; Wed, 16 Feb 2022 05:16:04 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (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 opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 4JzJPG4dFpz5vsh; Wed, 16 Feb 2022 14:16:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645017362; bh=nS62dpFX+/e9y0ANpGZdoG3RUR6f8dQvrFJpobhvld4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=iZIaOTFyBoND83LOMwIvToAXaatlVsjJTtypV34Sj5f8KHyNer7bwtaYF8nWA/dhw NUyX04PSOihW4vn93wxRiDtGmcJfoLdtzOF1PpTQWfbR9HObzzOo/2wskNTfuW3Zmj Mx8xoTMQ3D5xEgGIJXsvcgTb6uUvnqgodjcrz+H2xRTXrd02oizkEciHOL3GrJJ7jA kzW9+nU67dcRPG114eOrK8PfW7vTO1Dlx8/8GkCeBXNEpLQyQjvRdx10X2SODfr8OR eobbs7RTVWnVbrY89eawEiNu6Bx6RYzGGGW+dvsF5ud3oXR265+zKpZVh60aZrU3HD 9Xjpx2PKDm68w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4JzJPG3FRzzCqkX; Wed, 16 Feb 2022 14:16:02 +0100 (CET) From: To: Greg Mirsky , "Joel M. Halpern" CC: Gyan Mishra , "sfc@ietf.org" Thread-Topic: [sfc] Progression of OAM work in the SFC WG Thread-Index: AQHYIK6hl/ju054uSCa0IEDodR5p4KyRgXeAgAAjywCABIZqMA== Content-Class: Date: Wed, 16 Feb 2022 13:16:01 +0000 Message-ID: <30783_1645017362_620CF912_30783_202_2_787AE7BB302AE849A7480A190F8B933035494C12@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: 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_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-16T13:12:41Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=e6ee4601-1954-49b5-a03f-6912742d4ec4; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933035494C12OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 13:16:10 -0000 --_000_787AE7BB302AE849A7480A190F8B933035494C12OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpBbiBhcHByb2FjaCB0aGF0IHdvdWxkIHJlY29uY2lsaWF0ZSBhbGwgYWN0aXZlIE9B TSBkb2N1bWVudHMgaXMgdG8gY2xhcmlmeSDigJxzb21ld2hlcmXigJ0gdGhhdCBhbiBPQU0gcGFj a2V0IChtZW50aW9uZWQgaW4gODMwMCkgaXMgImFuIE5TSC1lbmNhcHN1bGF0ZWQgbWVzc2FnZSB0 aGF0IGV4Y2x1c2l2ZWx5IGluY2x1ZGUgYW4gT0FNIGNvbW1hbmQgYW5kL29yIGRhdGEgaW4gdGhl IE5TSCBDb250ZXh0IEhlYWRlcihzKSBvciBldmVuIGluIHRoZSBwYWNrZXQgcGF5bG9hZCIuDQoN CldlIGNhbiBmdXJ0aGVyIHR3ZWFrIHRoZSBsYW5ndWFnZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRl IDogc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9yZz4gRGUgbGEgcGFydCBkZSBHcmVnIE1pcnNreQ0K RW52b3nDqSA6IGRpbWFuY2hlIDEzIGbDqXZyaWVyIDIwMjIgMTg6MDQNCsOAIDogSm9lbCBNLiBI YWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KQ2MgOiBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fn c21AZ21haWwuY29tPjsgc2ZjQGlldGYub3JnDQpPYmpldCA6IFJlOiBbc2ZjXSBQcm9ncmVzc2lv biBvZiBPQU0gd29yayBpbiB0aGUgU0ZDIFdHDQoNCkhpIEpvZWwsDQpJIGFncmVlIHRoYXQsIGFz IHdlIGZpbmQgU0ZDIE5TSCBub3csIG5vIE9BTSBtZXRhZGF0YSBoYXMgYmVlbiBkZWZpbmVkLiBJ dCBhcHBlYXJzIHRvIG1lIHRoYXQgZGVwcmVjYXRpbmcgdGhlIE8gYml0IGRvZXMgbm90IGFmZmVj dCBhbnkgb2YgdGhlIGFscmVhZHkgZGVmaW5lZCBtZWNoYW5pc21zIGluIHRoZSBTRkMgTlNILiBJ IHRoaW5rIHRoYXQgaWYgYSBuZXcsIGZvciBleGFtcGxlLCBNRCBUeXBlID0gMiBUTFYgdGhhdCBp cyB1c2VkIGZvciBhbnkgT0FNIGZ1bmN0aW9uYWxpdHkgdG8gYmUgcHJvcG9zZWQgaW4gdGhlIGZ1 dHVyZSwgZGVwcmVjYXRlZCB0aGUgTyBiaXQgd291bGQgbm90IHByZXZlbnQgdXNpbmcgc3VjaCBO U0ggVExWLg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFN1biwg RmViIDEzLCAyMDIyIGF0IDY6NTUgQU0gSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4u Y29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4gd3JvdGU6DQpUaGVyZSBpcyBhbiBpbXBs aWNhdGlvbiBvZiBkZXByZWNhdGluZyB0aGUgTy1iaXQgdGhhdCBJIHdvdWxkIGxpa2UgdG8NCmhl YXIgZnJvbSBtb3JlIFdHIHBhcnRpY2lwYW50cyBhYm91dC4NCg0KQXMgZmFyIGFzIEkgY2FuIHRl bGwsIGlmIHdlIGRlcHJlY2F0ZSB0aGUgTy1iaXQgYW5kIHJlbHkgb24gdGhlIG5leHQNCnByb3Rv Y29sIGZpZWxkLCB3ZSBhcmUgc2F5aW5nIHRoYXQgaW4gcHJhY3RpY2UgKG5vdCBieSBydWxlKSBO U0gNCm1ldGFkYXRhIGNhbiBub3QgYmUgdXNlZCBmb3IgT0FNLiAgVGhhdCdzIGZpbmUgd2l0aCBt ZSBhcyBsb25nIGFzIHdlDQphZ3JlZSBvbiB0aGF0Lg0KDQpZb3VycywNCkpvZWwNCg0KT24gMi8x My8yMDIyIDI6NTIgQU0sIEd5YW4gTWlzaHJhIHdyb3RlOg0KPg0KPiBIaSBKaW0sIEpvZWwgJiBT RkMgV0csDQo+DQo+IEkgYWdyZWUgdGhhdCB0aGUgUkZDIDgzMDAgZGVmaW5pdGlvbiBvZiBPIGJp dCBpcyBpbmNvbXBsZXRlIGFuZCBub3QNCj4gY2xlYXIgYXMgdG8gaXRzIGludGVuZGVkIHVzZS4N Cj4NCj4gVGhhdCBpcyBhIHByb2JsZW0gdGhhdCBJIGFncmVlIG5lZWRzIHRvIGJlIHJlY3RpZmll ZC4NCj4NCj4gSSB1bmRlcnN0YW5kIHRoYXQgd2UgbmVlZCB0byBnZXQgdGhpcyByZXNvbHZlZCBi ZWZvcmUgd2UgY2FuIHByb2dyZXNzDQo+IE11bHRpbGF5ZXIgU0ZDIE9BTSBkcmFmdC1pZXRmLXNm Yy1tdWx0aS1sYXllci1vYW0tMTggYW5kIFNGQyBJT0FNLg0KPg0KPiBJIGFncmVlIHRoYXQgd2hh dCBtYWtlcyBzZW5zZSB0byBtZSBhcyBhIHBhdGggZm9yd2FyZCBpcyB0byBkZXByZWNhdGUNCj4g dGhlIE8gYml0IGFuZCBub3QgdXNlIGluIFNGQyBNdWx0aWxheWVyIE9BTSBhbmQgU0ZDIElPQU0s IGFzIGJvdGggU0ZDDQo+IE11bHRpbGF5ZXIgT0FNIGFuZCBTRkMgSU9BTSBhcmUgaWRlbnRpZmll ZCBieSB0aGUgcmVzcGVjdGl2ZSB2YWx1ZXMgZm9yDQo+IHRoZSBOU0ggTmV4dCBQcm90b2NvbCBm aWVsZCAodG8gYmUgYXNzaWduZWQgYnkgSUFOQSksIGFzIHdlbGwgYXMgc28gZmFyDQo+IG5vIE9B TS1zcGVjaWZpYyBtZXRhIGRhdGEgVExWIGhhcyBiZWVuIHlldCBkZWZpbmVkLg0KPg0KPiBTbyB3 ZSBoYXZlIEkgYmVsaWV2ZSBzb2xpZCBzb2x1dGlvbiBhbmQgcGF0aCBmb3J3YXJkIGFuZCBJIHN1 cHBvcnQNCj4gZGVwcmVjYXRpbmcgdGhlIE8gYml0Lg0KPg0KPiBLaW5kIFJlZ2FyZHMNCj4NCj4g R3lhbg0KPg0KPiBPbiBXZWQsIEZlYiAyLCAyMDIyIGF0IDU6NDIgUE0gR3JlZyBNaXJza3kgPGdy ZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPg0KPiA8bWFp bHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4+ IHdyb3RlOg0KPg0KPiAgICAgVGhhbmsgeW91LCBKaW0gYW5kIEpvZWwsIGZvciBndWlkaW5nIHRo ZSBTRkMgT0FNIHdvcmsgYW5kIHBvaW50aW5nDQo+ICAgICBvdXQgdGhlIGlzc3VlIHRoYXQgbXVz dCBiZSBhZGRyZXNzZWQuDQo+DQo+ICAgICBJJ3ZlIHJldmlld2VkIG91ciBTRkMgT0FNIGRvY3Vt ZW50cyBhbmQgZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi4gQXMgSQ0KPiAgICAgdW5kZXJzdGFuZCB0 aGVzZSBkb2N1bWVudHMsIHRoZSBBY3RpdmUgU0ZDIE9BTSBhbmQgSU9BTSBhcmUNCj4gICAgIGlk ZW50aWZpZWQgYnkgdGhlIHJlc3BlY3RpdmUgdmFsdWVzIGZvciB0aGUgTlNIIE5leHQgUHJvdG9j b2wgZmllbGQNCj4gICAgICh0byBiZSBhc3NpZ25lZCBieSBJQU5BKS4gQXQgdGhlIHNhbWUgdGlt ZSwgc28gZmFyIG5vIE9BTS1zcGVjaWZpYw0KPiAgICAgbWV0YSBkYXRhIFRMViBoYXMgYmVlbiBk ZWZpbmVkLiBUaHVzLCBpdCBhcHBlYXJzIHRoYXQgb25lIHdheQ0KPiAgICAgZm9yd2FyZCBjb3Vs ZCBiZSB0byBub3QgaW52b2x2ZSB0aGUgTyBiaXQgaW4gdGhlIGFjdGl2ZSBTRkMgT0FNIG9yDQo+ ICAgICBJT0FNIGFsdG9nZXRoZXIuIEluIG90aGVyIHdvcmRzLCB0byBkZXByZWNhdGUgdGhlIE5T SCBPIGJpdC4NCj4NCj4gICAgIEkgZ3JlYXRseSBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMgb24g dGhlIHByb3Bvc2FsIHRvIGRlcHJlY2F0ZSB0aGUNCj4gICAgIE5TSCBPIGJpdC4NCj4NCj4gICAg IFJlZ2FyZHMsDQo+ICAgICBHcmVnDQo+DQo+ICAgICBPbiBXZWQsIEZlYiAyLCAyMDIyIGF0IDEw OjM2IEFNIEphbWVzIEd1aWNoYXJkDQo+ICAgICA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWku Y29tPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+DQo+ICAgICA8bWFpbHRv OmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTxtYWlsdG86amFtZXMubi5ndWljaGFyZEBm dXR1cmV3ZWkuY29tPj4+IHdyb3RlOg0KPg0KPiAgICAgICAgIEhpIFdHOl9fX18NCj4NCj4gICAg ICAgICBfXyBfXw0KPg0KPiAgICAgICAgIEhhdmluZyByZXZpZXdlZCBhbGwgb2YgdGhlIE9BTSBy ZWxhdGVkIGRvY3VtZW50cyBpbiBvdXIgV0csIHRoZQ0KPiAgICAgICAgIGNoYWlycyB3b3VsZCBs aWtlIHRvIHByb3ZpZGUgYSBmZXcgY29tbWVudHMgdG8gaG9wZWZ1bGx5DQo+ICAgICAgICAgZ2Vu ZXJhdGUgZGlzY3Vzc2lvbiBhbmQgZm9yd2FyZCBwcm9ncmVzcyBvZiB0aGlzIHdvcms6X19fXw0K Pg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgMSkgVGhlIGNoYWlycyBoYXZlIHJldmll d2VkIHRoZSBPIGJpdCBkZWZpbml0aW9uIGluIFJGQyA4MzAwLg0KPiAgICAgICAgIFRoYXQgZGVm aW5pdGlvbiBpcyBhdCBiZXN0IG9wZW4gdG8gaW50ZXJwcmV0YXRpb24gYW5kIHRoZXJlZm9yZQ0K PiAgICAgICAgIGluY29tcGxldGUuICBGb3IgZXhhbXBsZSwgdGhlIGNsZWFyIGludGVudGlvbiBp cyBvbmx5IHRvIG1hcmsNCj4gICAgICAgICBwYWNrZXRzIHdoaWNoIGFyZSBpbnRlbmRlZCBmb3Ig U0ZDIE9BTSBhdCB0aGUgU0ZDIHNlcnZpY2UNCj4gICAgICAgICBsYXllci4gIEJ1dCB0aGF0IGlz IG5vdCB3aGF0IHRoZSBjdXJyZW50IHRleHQgc2F5cy4gIFRoZXJlIGlzDQo+ICAgICAgICAgYWxz bywgdW5mb3J0dW5hdGVseSwgYW1iaWd1aXR5IGFzIHRvIHdoYXQgY29uc3RpdHV0ZXMgYW4gT0FN DQo+ICAgICAgICAgcGFja2V0LiAgU28gaXQgaXMgcmVhc29uYWJsZSBmb3IgZG9jdW1lbnRzIHRv IHVwZGF0ZSA4MzAwIHRvDQo+ICAgICAgICAgY2xhcmlmeSB0aGUgZXhhY3QgYXBwbGljYWJpbGl0 eSBhbmQgYWN0aW9uIGZvciB0aGUgTy1iaXQuX19fXw0KPg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ ICAgICAgICAgMikgSG93ZXZlciwgcmVsYXRlZCB0byBwb2ludCAxKSwgd2UgY2FuJ3QgaGF2ZSBt dWx0aXBsZQ0KPiAgICAgICAgIGRvY3VtZW50cyB1cGRhdGluZyB0aGUgZGVmaW5pdGlvbiBkaWZm ZXJlbnRseS4gIEFzIHN1Y2gsIHRoZQ0KPiAgICAgICAgIGF1dGhvcnMgb2YgdGhlIFNGQyBpT0FN IGRyYWZ0IGFuZCB0aGUgU0ZDIG11bHRpLWxheWVyLW9hbSBkcmFmdA0KPiAgICAgICAgIG5lZWQg dG8gY29tZSB0b2dldGhlciBhbmQgZmlndXJlIG91dCB3aGF0IHRoZSBjbGFyaWZpY2F0aW9uIGlz DQo+ICAgICAgICAgZm9yIHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgYml0LiBXZSBkbyBub3QgYmVs aWV2ZSBhcyBjaGFpcnMgdGhhdA0KPiAgICAgICAgIGVpdGhlciBvZiB0aGVzZSBkb2N1bWVudHMg Y2FuIG1vdmUgZm9yd2FyZCBmcm9tIHRoZSBXRyB1bnRpbA0KPiAgICAgICAgIHN1Y2ggY2xhcml0 eSBoYXMgYmVlbiByZWFjaGVkLiBfX19fDQo+DQo+ICAgICAgICAgX18gX18NCj4NCj4gICAgICAg ICAzKSBSZWxhdGVkIHRvIHRoZSBTRkMgaU9BTSwgd2UgbmVlZCBhIGNsZWFyIGRlZmluaXRpb24g b2YgaU9BTS4NCj4gICAgICAgICBUaGVyZSBzZWVtIHRvIGJlIGRpZmZlcmVuY2VzIGJldHdlZW4g dGhlIGRlZmluaXRpb25zIGluDQo+ICAgICAgICAgcHVibGlzaGVkIFJGQ3MsIHRoZSB1c2FnZSAo d2hpY2ggaXMgbm90IGEgZGVmaW5pdGlvbikgaW4gdGhlIFNGQw0KPiAgICAgICAgIGRyYWZ0LCBh bmQgdGhlIHZhcmlvdXMgaXBwbSBkcmFmdHMuICBBbnkgc3VjaCBkZWZpbml0aW9uIHdpbGwNCj4g ICAgICAgICBuZWVkIHRvIGJlIHZldHRlZCB3aXRoIHRoZSBpcHBtIHdvcmtpbmcgZ3JvdXAuX19f Xw0KPg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgQWdhaW4sIGl0IHdvdWxkIGJlIGdv b2QgaWYgbWVtYmVycyBvZiB0aGUgd29ya2luZyBncm91cCBiZXlvbmQNCj4gICAgICAgICB0aGUg dHdvIGF1dGhvciB0ZWFtcyBzcG9rZSB1cCBhYm91dCB0aGVpciByZWFkaW5ncyBvZiB0aGUNCj4g ICAgICAgICBkb2N1bWVudHMsIGFuZCB0aGVpciB1bmRlcnN0YW5kaW5ncyBvZiB3aGF0IHdlIG5l ZWQuX19fXw0KPg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgWW91cnMsX19fXw0KPg0K PiAgICAgICAgIEppbSBhbmQgSm9lbF9fX18NCj4NCj4gICAgICAgICBfXyBfXw0KPg0KPiAgICAg ICAgIF9fIF9fDQo+DQo+ICAgICAgICAgX18gX18NCj4NCj4gICAgICAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgICAgIHNmYyBtYWlsaW5n IGxpc3QNCj4gICAgICAgICBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gPG1haWx0 bzpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+ICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gICAgICAgICA8aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM+DQo+DQo+ICAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgc2ZjIG1haWxpbmcgbGlzdA0K PiAgICAgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4gICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYz4NCj4NCj4gLS0NCj4NCj4gPGh0dHA6Ly93d3cudmVyaXpvbi5jb20vPg0KPg0K PiAqR3lhbiBNaXNocmEqDQo+DQo+IC9OZXR3b3JrIFNvbHV0aW9ucyBBLy9yY2hpdGVjdCAvDQo+ DQo+IC9FbWFpbCBneWFuLnMubWlzaHJhQHZlcml6b24uY29tPG1haWx0bzpneWFuLnMubWlzaHJh QHZlcml6b24uY29tPiA8bWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208bWFpbHRvOmd5 YW4ucy5taXNocmFAdmVyaXpvbi5jb20+Pi8vDQo+IC8NCj4NCj4gL00gMzAxIDUwMi0xMzQ3DQo+ DQo+IC8NCj4NCj4NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_787AE7BB302AE849A7480A190F8B933035494C12OPEXCAUBMA2corp_ 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 bC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPlJlLSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BbiBhcHByb2FjaCB0aGF0IHdvdWxk IHJlY29uY2lsaWF0ZSBhbGwgYWN0aXZlIE9BTSBkb2N1bWVudHMgaXMgdG8gY2xhcmlmeSDigJxz b21ld2hlcmXigJ0gdGhhdA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmFuIE9BTSBwYWNrZXQgKG1lbnRpb25lZCBp biA4MzAwKSBpcyAmcXVvdDthbiBOU0gtZW5jYXBzdWxhdGVkIG1lc3NhZ2UgdGhhdCBleGNsdXNp dmVseSBpbmNsdWRlIGFuIE9BTSBjb21tYW5kIGFuZC9vciBkYXRhIGluIHRoZSBOU0ggQ29udGV4 dCBIZWFkZXIocykgb3IgZXZlbiBpbiB0aGUgcGFja2V0IHBheWxvYWQmcXVvdDsuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2UgY2FuIGZ1cnRoZXIg dHdlYWsgdGhlIGxhbmd1YWdlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNoZWVycyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5EZSZuYnNwOzo8L2I+IHNmYyAmbHQ7c2ZjLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IDxiPkRlIGxhIHBhcnQgZGU8L2I+IEdyZWcgTWlyc2t5PGJyPg0KPGI+RW52b3nDqSZu YnNwOzo8L2I+IGRpbWFuY2hlIDEzIGbDqXZyaWVyIDIwMjIgMTg6MDQ8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IEpvZWwgTS4gSGFscGVybiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDs8YnI+DQo8 Yj5DYyZuYnNwOzo8L2I+IEd5YW4gTWlzaHJhICZsdDtoYXlhYnVzYWdzbUBnbWFpbC5jb20mZ3Q7 OyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbc2ZjXSBQcm9ncmVz c2lvbiBvZiBPQU0gd29yayBpbiB0aGUgU0ZDIFdHPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEpvZWwsPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0LCBhcyB3ZSBmaW5kIFNGQyBOU0gg bm93LCBubyBPQU0gbWV0YWRhdGEgaGFzIGJlZW4gZGVmaW5lZC4gSXQgYXBwZWFycyB0byBtZSB0 aGF0IGRlcHJlY2F0aW5nIHRoZSBPIGJpdCBkb2VzIG5vdCBhZmZlY3QgYW55IG9mIHRoZSZuYnNw O2FscmVhZHkgZGVmaW5lZCBtZWNoYW5pc21zIGluIHRoZSZuYnNwO1NGQyBOU0guIEkgdGhpbmsg dGhhdCBpZiBhIG5ldywgZm9yIGV4YW1wbGUsIE1EIFR5cGUgPSAyIFRMVg0KIHRoYXQmbmJzcDtp cyB1c2VkIGZvciBhbnkgT0FNIGZ1bmN0aW9uYWxpdHkgdG8gYmUgcHJvcG9zZWQgaW4gdGhlIGZ1 dHVyZSwgZGVwcmVjYXRlZCB0aGUgTyBiaXQgd291bGQmbmJzcDtub3QgcHJldmVudCB1c2luZyBz dWNoIE5TSCBUTFYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XaGF0IGRvIHlvdSB0aGluaz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBGZWIgMTMsIDIwMjIgYXQgNjo1 NSBBTSBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBhbiBpbXBs aWNhdGlvbiBvZiBkZXByZWNhdGluZyB0aGUgTy1iaXQgdGhhdCBJIHdvdWxkIGxpa2UgdG8NCjxi cj4NCmhlYXIgZnJvbSBtb3JlIFdHIHBhcnRpY2lwYW50cyBhYm91dC48YnI+DQo8YnI+DQpBcyBm YXIgYXMgSSBjYW4gdGVsbCwgaWYgd2UgZGVwcmVjYXRlIHRoZSBPLWJpdCBhbmQgcmVseSBvbiB0 aGUgbmV4dCA8YnI+DQpwcm90b2NvbCBmaWVsZCwgd2UgYXJlIHNheWluZyB0aGF0IGluIHByYWN0 aWNlIChub3QgYnkgcnVsZSkgTlNIIDxicj4NCm1ldGFkYXRhIGNhbiBub3QgYmUgdXNlZCBmb3Ig T0FNLiZuYnNwOyBUaGF0J3MgZmluZSB3aXRoIG1lIGFzIGxvbmcgYXMgd2UgPGJyPg0KYWdyZWUg b24gdGhhdC48YnI+DQo8YnI+DQpZb3Vycyw8YnI+DQpKb2VsPGJyPg0KPGJyPg0KT24gMi8xMy8y MDIyIDI6NTIgQU0sIEd5YW4gTWlzaHJhIHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBK aW0sIEpvZWwgJmFtcDsgU0ZDIFdHLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFncmVlIHRoYXQg dGhlIFJGQyA4MzAwIGRlZmluaXRpb24gb2YgTyBiaXQgaXMgaW5jb21wbGV0ZSBhbmQgbm90IDxi cj4NCiZndDsgY2xlYXIgYXMgdG8gaXRzIGludGVuZGVkIHVzZS48YnI+DQomZ3Q7IDxicj4NCiZn dDsgVGhhdCBpcyBhIHByb2JsZW0gdGhhdCBJIGFncmVlIG5lZWRzIHRvIGJlIHJlY3RpZmllZC48 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB1bmRlcnN0YW5kIHRoYXQgd2UgbmVlZCB0byBnZXQgdGhp cyByZXNvbHZlZCBiZWZvcmUgd2UgY2FuIHByb2dyZXNzIDxicj4NCiZndDsgTXVsdGlsYXllciBT RkMgT0FNIGRyYWZ0LWlldGYtc2ZjLW11bHRpLWxheWVyLW9hbS0xOCBhbmQgU0ZDIElPQU0uPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEkgYWdyZWUgdGhhdCB3aGF0IG1ha2VzIHNlbnNlIHRvIG1lIGFz IGEgcGF0aCBmb3J3YXJkIGlzIHRvIGRlcHJlY2F0ZSA8YnI+DQomZ3Q7IHRoZSBPIGJpdCBhbmQg bm90IHVzZSBpbiBTRkMgTXVsdGlsYXllciBPQU0gYW5kIFNGQyBJT0FNLCBhcyBib3RoIFNGQyA8 YnI+DQomZ3Q7IE11bHRpbGF5ZXIgT0FNIGFuZCBTRkMgSU9BTSBhcmUgaWRlbnRpZmllZCBieSB0 aGUgcmVzcGVjdGl2ZSB2YWx1ZXMgZm9yIDxicj4NCiZndDsgdGhlIE5TSCBOZXh0IFByb3RvY29s IGZpZWxkICh0byBiZSBhc3NpZ25lZCBieSBJQU5BKSwgYXMgd2VsbCBhcyBzbyBmYXIgPGJyPg0K Jmd0OyBubyBPQU0tc3BlY2lmaWMgbWV0YSBkYXRhIFRMViBoYXMgYmVlbiB5ZXQgZGVmaW5lZC48 YnI+DQomZ3Q7IDxicj4NCiZndDsgU28gd2UgaGF2ZSBJIGJlbGlldmUgc29saWQgc29sdXRpb24g YW5kIHBhdGggZm9yd2FyZCBhbmQgSSBzdXBwb3J0IDxicj4NCiZndDsgZGVwcmVjYXRpbmcgdGhl IE8gYml0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBLaW5kIFJlZ2FyZHM8YnI+DQomZ3Q7IDxicj4N CiZndDsgR3lhbjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBXZWQsIEZlYiAyLCAyMDIyIGF0IDU6 NDIgUE0gR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+DQo8YnI+DQomZ3Q7 ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1RoYW5rIHlvdSwgSmltIGFuZCBKb2Vs LCBmb3IgZ3VpZGluZyB0aGUgU0ZDIE9BTSB3b3JrIGFuZCBwb2ludGluZzxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwO291dCB0aGUgaXNzdWUgdGhhdCBtdXN0IGJlIGFkZHJlc3NlZC48YnI+ DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0kndmUgcmV2aWV3ZWQgb3VyIFNG QyBPQU0gZG9jdW1lbnRzIGFuZCBkcmFmdC1pZXRmLXNmYy1uc2gtdGx2LiBBcyBJPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7dW5kZXJzdGFuZCB0aGVzZSBkb2N1bWVudHMsIHRoZSBBY3Rp dmUgU0ZDIE9BTSBhbmQgSU9BTSBhcmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtpZGVu dGlmaWVkIGJ5IHRoZSByZXNwZWN0aXZlIHZhbHVlcyBmb3IgdGhlIE5TSCBOZXh0IFByb3RvY29s IGZpZWxkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7KHRvIGJlIGFzc2lnbmVkIGJ5IElB TkEpLiBBdCB0aGUgc2FtZSB0aW1lLCBzbyBmYXIgbm8gT0FNLXNwZWNpZmljPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7bWV0YSBkYXRhIFRMViBoYXMgYmVlbiBkZWZpbmVkLiBUaHVzLCBp dCBhcHBlYXJzIHRoYXQgb25lIHdheTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Zvcndh cmQgY291bGQgYmUgdG8gbm90IGludm9sdmUgdGhlIE8gYml0IGluIHRoZSBhY3RpdmUgU0ZDIE9B TSBvcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0lPQU0gYWx0b2dldGhlci4gSW4gb3Ro ZXIgd29yZHMsIHRvIGRlcHJlY2F0ZSB0aGUgTlNIIE8gYml0Ljxicj4NCiZndDsgPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7SSBncmVhdGx5IGFwcHJlY2lhdGUgeW91ciBjb21tZW50cyBv biB0aGUgcHJvcG9zYWwgdG8gZGVwcmVjYXRlIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwO05TSCBPIGJpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1Jl Z2FyZHMsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7R3JlZzxicj4NCiZndDsgPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7T24gV2VkLCBGZWIgMiwgMjAyMiBhdCAxMDozNiBBTSBK YW1lcyBHdWljaGFyZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJt YWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+amFt ZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPC9hPjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2Vp LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTwvYT4m Z3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7SGkgV0c6X19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtfXyBfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtIYXZpbmcgcmV2aWV3ZWQgYWxsIG9mIHRoZSBPQU0gcmVs YXRlZCBkb2N1bWVudHMgaW4gb3VyIFdHLCB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2NoYWlycyB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgYSBmZXcgY29tbWVu dHMgdG8gaG9wZWZ1bGx5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtnZW5lcmF0ZSBkaXNjdXNzaW9uIGFuZCBmb3J3YXJkIHByb2dyZXNzIG9mIHRoaXMgd29yazpf X19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O19fIF9fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzEpIFRoZSBjaGFpcnMgaGF2ZSByZXZpZXdlZCB0aGUgTyBiaXQgZGVmaW5pdGlvbiBpbiBS RkMgODMwMC4gPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGF0 IGRlZmluaXRpb24gaXMgYXQgYmVzdCBvcGVuIHRvIGludGVycHJldGF0aW9uIGFuZCB0aGVyZWZv cmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luY29tcGxldGUu Jm5ic3A7IEZvciBleGFtcGxlLCB0aGUgY2xlYXIgaW50ZW50aW9uIGlzIG9ubHkgdG8gbWFyazxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGFja2V0cyB3aGljaCBh cmUgaW50ZW5kZWQgZm9yIFNGQyBPQU0gYXQgdGhlIFNGQyBzZXJ2aWNlPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsYXllci4mbmJzcDsgQnV0IHRoYXQgaXMgbm90 IHdoYXQgdGhlIGN1cnJlbnQgdGV4dCBzYXlzLiZuYnNwOyBUaGVyZSBpczxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWxzbywgdW5mb3J0dW5hdGVseSwgYW1iaWd1 aXR5IGFzIHRvIHdoYXQgY29uc3RpdHV0ZXMgYW4gT0FNPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtwYWNrZXQuJm5ic3A7IFNvIGl0IGlzIHJlYXNvbmFibGUgZm9y IGRvY3VtZW50cyB0byB1cGRhdGUgODMwMCB0bzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Y2xhcmlmeSB0aGUgZXhhY3QgYXBwbGljYWJpbGl0eSBhbmQgYWN0aW9u IGZvciB0aGUgTy1iaXQuX19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtfXyBfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsyKSBIb3dldmVyLCByZWxhdGVkIHRvIHBvaW50IDEpLCB3ZSBj YW4ndCBoYXZlIG11bHRpcGxlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtkb2N1bWVudHMgdXBkYXRpbmcgdGhlIGRlZmluaXRpb24gZGlmZmVyZW50bHkuJm5ic3A7 IEFzIHN1Y2gsIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 YXV0aG9ycyBvZiB0aGUgU0ZDIGlPQU0gZHJhZnQgYW5kIHRoZSBTRkMgbXVsdGktbGF5ZXItb2Ft IGRyYWZ0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtuZWVkIHRv IGNvbWUgdG9nZXRoZXIgYW5kIGZpZ3VyZSBvdXQgd2hhdCB0aGUgY2xhcmlmaWNhdGlvbiBpczxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9yIHRoZSBkZWZpbml0 aW9uIG9mIHRoYXQgYml0LiBXZSBkbyBub3QgYmVsaWV2ZSBhcyBjaGFpcnMgdGhhdDxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZWl0aGVyIG9mIHRoZXNlIGRvY3Vt ZW50cyBjYW4gbW92ZSBmb3J3YXJkIGZyb20gdGhlIFdHIHVudGlsPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzdWNoIGNsYXJpdHkgaGFzIGJlZW4gcmVhY2hlZC4g X19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtfXyBfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDszKSBSZWxhdGVkIHRvIHRoZSBTRkMgaU9BTSwgd2UgbmVlZCBhIGNsZWFyIGRlZmluaXRp b24gb2YgaU9BTS4gPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtU aGVyZSBzZWVtIHRvIGJlIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIGRlZmluaXRpb25zIGluPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwdWJsaXNoZWQgUkZDcywg dGhlIHVzYWdlICh3aGljaCBpcyBub3QgYSBkZWZpbml0aW9uKSBpbiB0aGUgU0ZDPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdCwgYW5kIHRoZSB2YXJpb3Vz IGlwcG0gZHJhZnRzLiZuYnNwOyBBbnkgc3VjaCBkZWZpbml0aW9uIHdpbGw8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO25lZWQgdG8gYmUgdmV0dGVkIHdpdGggdGhl IGlwcG0gd29ya2luZyBncm91cC5fX19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FnYWluLCBpdCB3b3VsZCBiZSBnb29kIGlmIG1lbWJl cnMgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgYmV5b25kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt0aGUgdHdvIGF1dGhvciB0ZWFtcyBzcG9rZSB1cCBhYm91dCB0aGVp ciByZWFkaW5ncyBvZiB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2RvY3VtZW50cywgYW5kIHRoZWlyIHVuZGVyc3RhbmRpbmdzIG9mIHdoYXQgd2UgbmVlZC5f X19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O19fIF9fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1lvdXJzLF9fX188YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7SmltIGFuZCBKb2VsX19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfXyBfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfXyBfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfXyBfXzxicj4NCiZndDsgPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7c2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNmY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYzwvYT4mZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3NmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+Jmd0Ozxicj4NCiZn dDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHA6 Ly93d3cudmVyaXpvbi5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy52ZXJpem9uLmNv bS88L2E+Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyAqR3lhbiBNaXNocmEqPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IC9OZXR3b3JrIFNvbHV0aW9ucyBBLy9yY2hpdGVjdCAvPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IC9FbWFpbCA8YSBocmVmPSJtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208L2E+ICZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20iIHRhcmdldD0iX2JsYW5r Ij5neWFuLnMubWlzaHJhQHZlcml6b24uY29tPC9hPiZndDsvLzxicj4NCiZndDsgLzxicj4NCiZn dDsgPGJyPg0KJmd0OyAvTSAzMDEgNTAyLTEzNDc8YnI+DQomZ3Q7IDxicj4NCiZndDsgLzxicj4N CiZndDsgPGJyPg0KJmd0OyA8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9i b2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933035494C12OPEXCAUBMA2corp_-- From nobody Wed Feb 16 05:30:12 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AC23A08B1 for ; Wed, 16 Feb 2022 05:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.978 X-Spam-Level: X-Spam-Status: No, score=-6.978 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, T_REMOTE_IMAGE=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 njxr0oO9-A1l for ; Wed, 16 Feb 2022 05:30:03 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2127.outbound.protection.outlook.com [40.107.93.127]) (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 821663A08AE for ; Wed, 16 Feb 2022 05:30:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EPfQGwXzCoO7CiARRROA6umFB87gOuXRtojJbYvYMTpGq6dTod9VtqfLZWrJnbmAEMUTYMxI2DkDFAOELzAODReuNWtFbM4tJqHrABewvHq174VZlwIDrErxBImiZBpAvaTFWpSgUbnbsjbhRF4IaFqu2blHjYbxle9sDfMosOPczaWrCie9D+4ZIuhJlkyaeRlDGffCKCxgWdK2nPbn44E5G/0zd05CG4ivUsTIT5qVZKW+WV0u3mqFEiFKOEXBX99Pijnd27wyMO88kR0Erxzgof7s0xj5UyMxjSiQCALc8JMfgOjV8/csQJDONS/91+Otrz3d/D8nEY2GjzZdfw== 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=8OnXDsz0LuHFFlCQJzrLkfdop9yARPA7wnibAOi4t4A=; b=n2jDHB4H+cgEIFvHIPdUj1EeT/9N7dNBOGtRFedIhLZsMj+nGAqEonDikAYN18HpDu73uoVicEzKH8iy30j2NEIo9l+v7amD0OLavHChrsksCILfwuWWT6UX8l03q1Xg/KJAGq3Xj4vMQQKaIewZD9eerOtn2F3ZOE5k8IEeElX0V3T7vKY/c+Mdx4xuOIzC4mpwT4YrLqeeb6a386RuL4VOa/JefIUmhtGN+V+kICRVY2IHwKsp/58TI3RRlqf7/xqFUKXkflKVeQD4vNHQtQZCRaBS9nGESKSMgSwQe2QK6ixGY8cRMAQCLOZOz74OOrffGRFzoR6wgzVGbWKCdw== 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=8OnXDsz0LuHFFlCQJzrLkfdop9yARPA7wnibAOi4t4A=; b=W6CT6BBi566vnwkOYZHdIsm6WMmID0iJN+VguPYGzBGPXfGL1XtG0nOJKspEjMbt5qygNqH70AyJVyfs2/wwbVExsj04+YK4hd1SeMyP/3yd22Cs12wCE/oPFKP+ppwoQ9IT79i2JqQOfLbw65k0IJmvJ2hjOwapa0PKCUj7ZsM= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by MN2PR13MB4053.namprd13.prod.outlook.com (2603:10b6:208:26c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.8; Wed, 16 Feb 2022 13:30:00 +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 13:30:00 +0000 From: James Guichard To: James Guichard , "Carlos Pignataro (cpignata)" CC: Greg Mirsky , Gyan Mishra , "sfc@ietf.org" Thread-Topic: [sfc] Progression of OAM work in the SFC WG Thread-Index: AdgYYtG+l/ju054uSCa0IEDodR5p4AAI1AYAAgogAwAADsqJgAAEeXQAAAD7PAAAFinEAAAVIwJwAAHkVoAAX/UxwAAA6o1Q Date: Wed, 16 Feb 2022 13:29:59 +0000 Message-ID: References: <3CDEE749-5A40-44FF-9E3A-8C8EBBA94849@cisco.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=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 51679984-0399-4b1a-4e25-08d9f1506e54 x-ms-traffictypediagnostic: MN2PR13MB4053:EE_ x-ms-exchange-atpmessageproperties: SA|SL 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: PddN7qdm4ke29daphI1CuZFlT2ccRZKbdUb6l8S+4wFi/vIxiNSWY1YTEppIKhbbeunqyhiM2UhMNu3uBompwmusiQkTGgg93awMMBhnmcYA63FKaH6KpInoXCUH1DZQlGc7NHl6AOjSF8nm4jRyXySAbENej5gvGWZkN856tPTiWJ27z+/9R1a6UzlOSXG8Gppf1udQuVfYvxDYRXYZGJfFOcAsqibJcL5DoYUQBkAQo5WrcFn/U4sl+sdjRfK/jFGFz8C3Sym2Uit6HeqaNngeCclFvpABWWL8NTb6iQlXYtLIa6AuYim+QUTOqIp1mEmRhFeol0XCjexsp8vMd/MLsy/m8ZN968PEgciLxXfNc0lfxVeLmLXai8aCYqsnHQDXn+niuoLU1B07xYql2JLckK9Fz7qZYJf96pi7Z3sLLn7qB7kQb35yoewREzSQohaiJ0e48XMvpezfH0mNY4auwhDvqLWlO5Xv0cXELdpK+iEqPZdoPs3daaPqRBYEq75PZxx02AYNuCvI5JdjDfG4WZQxfgG02WXry8RLqC5EpdHSSK45feppTLBstK1cecVOQ0oOlfyI/fiU9rO3tzb5zYIcmmvV2tJFDT+EuKj5/auG3DBYRsJ6MpUaVLYMAS54h2NdA+QcZbHAnXDt8dx/W2OuWnevaXiX/3XyTmK/eQt6wcKE3qpNgZ/B+nNeFLNrimMnA4mStmbm+v6D6S2qsxGIPDmWBDKJml5uO4KhjuMAEbkVA2VBmnLOeN204NJGINin5G9lqIha6Xh+MpiPRE5mnd3r1CdKAr6Cvr+aRbam2fnrGEfw5OVfkWkUQoZdQx3s+11g3+SWQWaEXg== 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)(66446008)(66556008)(66476007)(76116006)(66946007)(6506007)(7696005)(9686003)(2906002)(2940100002)(64756008)(8936002)(30864003)(110136005)(54906003)(316002)(508600001)(86362001)(33656002)(71200400001)(53546011)(186003)(966005)(40140700001)(38100700002)(83380400001)(122000001)(4326008)(8676002)(5660300002)(52536014)(166002)(38070700005)(55016003)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?MWsvSEhWODNTSmh3NzRSaDNFbm1MajFKNlRySlpNdUxQdEtta2JUNTVO?= =?iso-2022-jp?B?TzhrQWFWdUh6SDlUZkdaZ3RUcXpIQnFlODh3amppTXUwdDJ5V0twcXpl?= =?iso-2022-jp?B?dnhWek5FckxrSVFERUNZdzJJM1A4Mlp6a3NONTNFUi9xMlEyRFNCTjdV?= =?iso-2022-jp?B?aDMyMEUvdVMrN0U1R2ZnSU55cElxQkdXa0dUTnVHaHozVXpBZFV1aTBy?= =?iso-2022-jp?B?OGExMzRKQnJxTnF6MlQ4QzBFYmdHYzlwSTl4ZXpYWHBOczdKOWRaMjlk?= =?iso-2022-jp?B?czF3SkZDck14WlhxaTd1V0ZDeDZMR3pKRERqSkt5RnZuMFZPMVlXcXdn?= =?iso-2022-jp?B?LzZSZWpWZm9CU1dzeVdnYWZPYThEVldieWN2ell5bjhWaWZNcDdLbkxa?= =?iso-2022-jp?B?cWV2eDllWlQ1VURra2s0ZWxSYjM2d01STkgzUzlMK0h4dTRyK0Mwcysv?= =?iso-2022-jp?B?QWFsSDhLNzlPR3pVMlg1SDEzWnNxWVM1RUdJcWVKSlZXY3gwNUpuOFR2?= =?iso-2022-jp?B?QlVzSU5yMm94MTBjWjk3RW1zUDNFbTN6M3FnREpEbkxpSTVkZzlYV1ph?= =?iso-2022-jp?B?WlVxM2ZPdFBpME9HdWt1MThGTnBvOCtNUnBjZ0NySVZBNGZORWd1OWNz?= =?iso-2022-jp?B?dk1CUzdWSXZhTmFYbnZDcDIvdHFqRmhOWjV3TmlkeGpUdXk5T0FPKzVZ?= =?iso-2022-jp?B?MkM5cytYMS9yeW5tZmY5WEhQUm5wNWE3QTFiSDBtYXRGSzExZ3o0YXBB?= =?iso-2022-jp?B?RTVBVzdETVFyRFJYczA1ZGo2RWcyT29WaHF2b1lraTdwbUExNkwweCth?= =?iso-2022-jp?B?TStKYUt3TVlrUHRkS21tODJ1QlZCZFhqcG15Q1lpeWY4Wlh0MUdEcjhU?= =?iso-2022-jp?B?WWlmVDQvRHhDeGNDZ0R6ZXFYRE1saU96aXc3UE9OMHJ0ZjBpWEVXVEJk?= =?iso-2022-jp?B?bHdGQ2ZMeFNmdHNGeWYvcGFqSWthWDZtMmhkbWxpQllTRmdMUkpCTER4?= =?iso-2022-jp?B?NTQ2UEhERy9lMTI3MEJrTFhyeTE5MGtMUElRVGlQUXlLa24xK1FXT2ZV?= =?iso-2022-jp?B?VnNrSms2TlgwUEJwNXNaY3BZTHd0dVNML1hndUlZZkdzeFNxOTlVckp1?= =?iso-2022-jp?B?VlVvV2tDVEtTaGxSNWMzQTVidVp6NFlXWlJaVEFhcjk4bWNSZy81Yzhr?= =?iso-2022-jp?B?OWhaM3VLby9WM0JyakpjeTl6RFl6elNLNk12QVpmV1RQUHFtWXZGSlFo?= =?iso-2022-jp?B?Vi9uOEI5L09LWjd3QlgxdjROcmhxQkxBSmxCcTl2V1FQaDI2ejNCWU45?= =?iso-2022-jp?B?QkNBb2RWOUt4R2FDOHBlTGlxSUZVVHZLdXJ6RDh3ZEg3Q0MwRFRXQ2tT?= =?iso-2022-jp?B?YUU0Q1FJT3M1Zlg0aEVLZ3JBVXc4UTRUcDBPWkNHMHF3WlowMW5Pdmty?= =?iso-2022-jp?B?aXZNeXhBOFdtNXNjelNuU1BCK0tpeUNrVkFoSkVTREp3ak5nUjFzd3hh?= =?iso-2022-jp?B?RUUrVlJrYXN6bmZpNjNYQ2VZN2YxMytadjBSVmFWZkRuZnBVK2lmYUl2?= =?iso-2022-jp?B?Mk1pTlRZODU4NVJtYzZ6d0Q1bC83WXpRZ1BCNFkvekJwcnd0cUxvc2dL?= =?iso-2022-jp?B?NGdrOEc2QVdlSWV5UU15ZjBaSWhUbytvdlZoLytJWGlqQzQvVGZjaUFD?= =?iso-2022-jp?B?Ymw2OCs1Z25YRGt3MUF6VFZBQmx2QStQSnJwVHA2UFlyU1ZLS3pBQkFX?= =?iso-2022-jp?B?YkJYWDNtZmY2eDFidHJFczVCeDlneElBWllSREtlbDMvSHVLcnVFeGhr?= =?iso-2022-jp?B?V3hTRDdzVExSVG1TSHpQYWgzbXp3VE9zaldWNjJrdGZhRVYyeWVOenZF?= =?iso-2022-jp?B?UTVPS2JzNVVpSThLRUl1WmVOUW5obzE1cnk4ZmprMW4yK3lldnBxN21V?= =?iso-2022-jp?B?d1E2Nkp6ZjZaUTEvZzh2Z01aakFGRSt4RXg0cHlaa2tBdVN6dUFQYTh3?= =?iso-2022-jp?B?U1daR2VKZ2tDVEpxeXFSME15NS9RbDA3b2hHNFg1ajFjWWNHNElQM2xV?= =?iso-2022-jp?B?WjVXeWg1Yks1K2pxNnRZcUxTL3hubjYzdmpqclNmUGlIV0xQRE8rWGZ0?= =?iso-2022-jp?B?Mm5CVGpSUHVwaEZvZzlsZThNRFhySUxaR2xGUVBiUEl5MHVKaG1iY3V1?= =?iso-2022-jp?B?blZiUjZCcUNtcUtKNHRvd2dBdE5BQnJjTGV6dWh0RE9xSGFnLyt5MXBt?= =?iso-2022-jp?B?bWRFYUtmU1I5ZTM4TVJDWnd0bUQ4cUt5b2E3OFZkOVF3aU9Tc1kvMkUv?= =?iso-2022-jp?B?bXUvWG00YmVtZkU2YXJBU2FUeUkwSVBFeEgvWWVQWE15Tlhudzl4dk9B?= =?iso-2022-jp?B?emdIYTl6S1dBaUtwTjBmRTh1YlhocDlObXNoNTUrd0w2TUplU2xJeDMx?= =?iso-2022-jp?B?U3lvWGVQZUFpTVRmc29QT2RlUklvQkFja3pFPQ==?= Content-Type: multipart/alternative; boundary="_000_MN2PR13MB42069179D07E2E27D7467B88D2359MN2PR13MB4206namp_" 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: 51679984-0399-4b1a-4e25-08d9f1506e54 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2022 13:29:59.9082 (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: K086gjHDjV8EnwfB8DTj3JYQbN+qlbtyGVBYfyH2sxDsZi4pHR080F1pvXwjTSaFqPSHtXut28siRAswPIETSg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB4053 Archived-At: Subject: Re: [sfc] Progression of OAM work in the SFC WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 13:30:10 -0000 --_000_MN2PR13MB42069179D07E2E27D7467B88D2359MN2PR13MB4206namp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Dear WG: I should have clarified in my previous email that RFC 8300 as currently wri= tten says that the O-bit MUST be set for OAM packets. This means that for p= oint (2) both IOAM and multilayer-oam MUST have the O-bit set and this caus= es a conflict between the two as I previously pointed out based upon the cu= rrent text within the multilayer-oam document, and for point (3) there is n= othing in 8300 that suggests that OAM information MUST be in the context he= aders. Jim From: sfc On Behalf Of James Guichard Sent: Wednesday, February 16, 2022 8:08 AM To: Carlos Pignataro (cpignata) Cc: Greg Mirsky ; Gyan Mishra ; sfc@ietf.org Subject: Re: [sfc] Progression of OAM work in the SFC WG Hi Carlos, Thank you for the clarification. Your response highlights quite nicely the = issues that the chairs are trying to bring to the WGs attention - maybe res= ponses to the following questions will help settle this: 1. Should the O-bit be set ONLY for OAM packets that are specific to the= SFC service layer? 2. Should the O-bit be set in the cases where a solution uses the next p= rotocol field in the NSH header? In this case what is the purpose of the O-= bit given that the next protocol field already indicates the expected behav= ior? 3. If the O-bit is set is it the expected behavior to find relevant SFC = service layer OAM information in the context headers? Thanks! Jim From: Carlos Pignataro (cpignata) > Sent: Monday, February 14, 2022 10:06 AM To: James Guichard > Cc: Gyan Mishra >; Greg= Mirsky >; sfc@ietf.org= Subject: Re: [sfc] Progression of OAM work in the SFC WG Thanks - I=1B$B!G=1B(Bd expect SFC OAM layer packets only, and would also e= xpect a model that works equally with multilayer-oam approaches or with exi= sting OAMs. Thanks! Carlos. 2/14/22 =1B$B8aA0=1B(B9:28=1B$B!"=1B(BJames Guichard >=1B$B$N%a!<%k=1B(B: Hi Carlos, Some responses in-line =1B$B!D=1B(B From: sfc > On Behalf Of = Carlos Pignataro (cpignata) Sent: Sunday, February 13, 2022 11:07 PM To: Gyan Mishra > Cc: Greg Mirsky >; sfc@= ietf.org Subject: Re: [sfc] Progression of OAM work in the SFC WG Replying to this specific email in the thread, only because it is the lates= t one at this point in time, but bundling comments from various places on t= he thread. Please find some follow-up comments and questions marked =1B$B!H= =1B(BCMP=1B$B!I=1B(B, indicating the =1B$B!H=1B(BFrom=1B$B!I=1B(B, and orga= nized chronologically: James N Guichard >: 1) The chairs have reviewed the O bit definition in RFC 8300. That definit= ion is at best open to interpretation and therefore incomplete. For exampl= e, the clear intention is only to mark packets which are intended for SFC O= AM at the SFC service layer. But that is not what the current text says. = There is also, unfortunately, ambiguity as to what constitutes an OAM packe= t. So it is reasonable for documents to update 8300 to clarify the exact a= pplicability and action for the O-bit. CMP: It is unclear to me what exact issues the chairs are calling out. Ther= e are two issues mentioned: CMP: 1. "But that is not what the current text says.=1B$B!I=1B(B -> what do= es the text say precisely? Can you point to the specific RFC 8300 text tha= t is believed to be incomplete, and a detailed use case that showcases the = potential issue? An extrapolated counter-example just to make a point: the = text does not say what days of the week OAM packets can be marked, yet the= re=1B$B!G=1B(Bs an expectation that they will work Mondays and Saturdays al= l the same - even holidays. Jim> Currently RFC8300 says =1B$B!H=1B(BThe O bit MUST be set for OAM packe= ts and MUST NOT be set for non-OAM packets=1B$B!I=1B(B. The first issue is = does this mean the O bit should be set for ALL OAM packets regardless of wh= ether they belong to the NSH service plane? Or should it only be set for SF= C OAM packets? And what exactly is an SFC OAM packet as the earlier referen= ce to RFC6291 is just a generate set of guidelines for the use of the term = OAM. The second issue is that if that O bit is set then Greg=1B$B!G=1B(Bs d= ocument is in conflict with IOAM as both use the next protocol field and ev= en if the O bit is set it is meaningless as the protocol action is based so= lely on the setting of the next protocol field. So in this case can their s= olutions simply ignore what RFC 8300 says e.g. MUST set the O bit? Or if th= ey set the O bit to be conformant to what RFC 8300 says then do we need cle= arer rules stating what to do if the next protocol field is NOT an OAM next= protocol such as the context headers should then be examined? CMP: 2. What specifically is the ambiguity with what an OAM packet is? Plea= se grep the RFC series for =1B$B!H=1B(Boam packet=1B$B!I=1B(B, it is not a = new term. CMP: Net-net, O-bit=3D1, OAM packet. Jim> ambiguity is whether it is only SFC OAM packets that are being discuss= ed or ALL OAM packets nothing that some might be at the service layer and s= ome might not. Jim 2) However, related to point 1), we can't have multiple documents updating = the definition differently. As such, the authors of the SFC iOAM draft and= the SFC multi-layer-oam draft need to come together and figure out what th= e clarification is for the definition of that bit. We do not believe as cha= irs that either of these documents can move forward from the WG until such = clarity has been reached. CMP: If there is still believed to be an ambiguity or a clear opportunity f= or improving the definition, I agree with consolidating that update. I had = suggested before that if such new text or real clarification is agreed, a s= eparate document that only makes that O-bit clarification is the most clear= and clean way to go. That doc should be a one-pager or less. I=1B$B!G=1B(B= d be happy to contribute to that minimal doc, if it is shown to be needed. CMP: For completeness also, the "SFC multi-layer-oam=1B$B!I=1B(B document h= as many outstanding issues besides the O-bit. Greg Mirsky > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I unders= tand these documents, the Active SFC OAM and IOAM are identified by the res= pective values for the NSH Next Protocol field (to be assigned by IANA). CMP: There is a major issue with the sentence above. Active SFC OAM (as a c= ategory), as per RFC 8300, needs to be identified by setting the O-bit. No = way around that based on RFC 8300. However, the text "the Active SFC OAM=1B= $B!I=1B(B creates confusion since it refer to a specific OAM protocol which= has the same name as a the category as well. That name collision is quite = unfortunate in my opinion. At the same time, so far no OAM-specific meta data TLV has been defined. Th= us, it appears that one way forward could be to not involve the O bit in th= e active SFC OAM or IOAM altogether. In other words, to deprecate the NSH O= bit. CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM proto= cols. Those can be encapsulated in IP, in which the Next-Protocol indicates= IP - and (as per RFC 8300) the O-bit is set to indicate an OAM packet. CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols a= lready included in an RFC. CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM= . CMP: This expired I-D yet implemented in open source uses the O-bit: https:= //www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt Gyan Mishra > I agree that what makes sense to me as a path forward is to deprecate the O= bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC Multilayer= OAM and SFC IOAM are identified by the respective values for the NSH Next = Protocol field (to be assigned by IANA), as well as so far no OAM-specific = meta data TLV has been yet defined. CMP: What is the =1B$B!H=1B(BSFC Multilayer OAM=1B$B!I=1B(B? CMP: The O-bit (reading RFC 8300) does not indicate if there is OAM Metadat= a. It indicates an OAM packet. "Joel M. Halpern" > As far as I can tell, if we deprecate the O-bit and rely on the next protoc= ol field, we are saying that in practice (not by rule) NSH metadata can not= be used for OAM. That's fine with me as long as we agree on that. CMP: I do not fully follow this. Can you explain the relationship of the O-= bit with Metadata? CMP: Here=1B$B!G=1B(Bs an example: RFC 8924 shows ICMP as Active OAM. The S= FC next protocol is IP, the IP next protocol is ICMP, the O-bit needs to be= set. CMP: Consider the following document, independent submission and in the RFC= Publication queue already: CMP: https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timesta= mp/ CMP: Is a Timestamp in Metadata an OAM element? CMP: Consider this proposal https://datatracker.ietf.org/doc/draft-mirsky-s= fc-pmamm/ CMP: Where the base header borrows a bit for an OAM function. CMP: Neither of those have any impact on the O-bit. Greg Mirsky > I agree that, as we find SFC NSH now, no OAM metadata has been defined. It = appears to me that deprecating the O bit does not affect any of the already= defined mechanisms in the SFC NSH. CMP: It actually does, see my example above. I think that if a new, for example, MD Type =3D 2 TLV that is used for any = OAM functionality to be proposed in the future, deprecated the O bit would = not prevent using such NSH TLV. CMP: I agree with this - because there is no correlation between MD Type fi= eld and O-bit as defined. Best, Carlos. 2/13/22 =1B$B8a8e=1B(B12:32=1B$B!"=1B(BGyan Mishra >=1B$B$N%a!<%k=1B(B: Hi Joel I am in agreement as well with what you have stated that once the O bit is = deprecated that NSH metadata cannot be used for OAM and that we would have = to now from that point forward rely on the next protocol field as we will b= e doing for SFC Multilayer and SFC IOAM drafts as well as will have backwar= ds compatible with any already existing defined mechanisms in SFC NSH. I don=1B$B!G=1B(Bt see any issues or impact with moving forward. Kind Regards Gyan On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky > wrote: Hi Joel, I agree that, as we find SFC NSH now, no OAM metadata has been defined. It = appears to me that deprecating the O bit does not affect any of the already= defined mechanisms in the SFC NSH. I think that if a new, for example, MD = Type =3D 2 TLV that is used for any OAM functionality to be proposed in the= future, deprecated the O bit would not prevent using such NSH TLV. What do you think? Regards, Greg On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern > wrote: There is an implication of deprecating the O-bit that I would like to hear from more WG participants about. As far as I can tell, if we deprecate the O-bit and rely on the next protocol field, we are saying that in practice (not by rule) NSH metadata can not be used for OAM. That's fine with me as long as we agree on that. Yours, Joel On 2/13/2022 2:52 AM, Gyan Mishra wrote: > > Hi Jim, Joel & SFC WG, > > I agree that the RFC 8300 definition of O bit is incomplete and not > clear as to its intended use. > > That is a problem that I agree needs to be rectified. > > I understand that we need to get this resolved before we can progress > Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM. > > I agree that what makes sense to me as a path forward is to deprecate > the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC > Multilayer OAM and SFC IOAM are identified by the respective values for > the NSH Next Protocol field (to be assigned by IANA), as well as so far > no OAM-specific meta data TLV has been yet defined. > > So we have I believe solid solution and path forward and I support > deprecating the O bit. > > Kind Regards > > Gyan > > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky > >> wrote: > > Thank you, Jim and Joel, for guiding the SFC OAM work and pointing > out the issue that must be addressed. > > I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I > understand these documents, the Active SFC OAM and IOAM are > identified by the respective values for the NSH Next Protocol field > (to be assigned by IANA). At the same time, so far no OAM-specific > meta data TLV has been defined. Thus, it appears that one way > forward could be to not involve the O bit in the active SFC OAM or > IOAM altogether. In other words, to deprecate the NSH O bit. > > I greatly appreciate your comments on the proposal to deprecate the > NSH O bit. > > Regards, > Greg > > On Wed, Feb 2, 2022 at 10:36 AM James Guichard > > >> wrote: > > Hi WG:____ > > __ __ > > Having reviewed all of the OAM related documents in our WG, the > chairs would like to provide a few comments to hopefully > generate discussion and forward progress of this work:____ > > __ __ > > 1) The chairs have reviewed the O bit definition in RFC 8300. > That definition is at best open to interpretation and therefore > incomplete. For example, the clear intention is only to mark > packets which are intended for SFC OAM at the SFC service > layer. But that is not what the current text says. There is > also, unfortunately, ambiguity as to what constitutes an OAM > packet. So it is reasonable for documents to update 8300 to > clarify the exact applicability and action for the O-bit.____ > > __ __ > > 2) However, related to point 1), we can't have multiple > documents updating the definition differently. As such, the > authors of the SFC iOAM draft and the SFC multi-layer-oam draft > need to come together and figure out what the clarification is > for the definition of that bit. We do not believe as chairs that > either of these documents can move forward from the WG until > such clarity has been reached. ____ > > __ __ > > 3) Related to the SFC iOAM, we need a clear definition of iOAM. > There seem to be differences between the definitions in > published RFCs, the usage (which is not a definition) in the SFC > draft, and the various ippm drafts. Any such definition will > need to be vetted with the ippm working group.____ > > __ __ > > Again, it would be good if members of the working group beyond > the two author teams spoke up about their readings of the > documents, and their understandings of what we need.____ > > __ __ > > Yours,____ > > Jim and Joel____ > > __ __ > > __ __ > > __ __ > > _______________________________________________ > sfc mailing list > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > > -- > > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /Email gyan.s.mishra@verizon.com >// > / > > /M 301 502-1347 > > / > > -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_MN2PR13MB42069179D07E2E27D7467B88D2359MN2PR13MB4206namp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Dear WG:

 =

I should have clarified = in my previous email that RFC 8300 as currently written says that the O-bit= MUST be set for OAM packets. This means that for point (2) both IOAM and multilayer-oam MUST have the O-bit set and thi= s causes a conflict between the two as I previously pointed out based upon = the current text within the multilayer-oam document, and for point (3) ther= e is nothing in 8300 that suggests that OAM information MUST be in the context headers.

 =

Jim

 =

From: sfc <sfc-bounces@ietf.org&g= t; On Behalf Of James Guichard
Sent: Wednesday, February 16, 2022 8:08 AM
To: Carlos Pignataro (cpignata) <cpignata@cisco.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>; Gyan Mishra <hayab= usagsm@gmail.com>; sfc@ietf.org
Subject: Re: [sfc] Progression of OAM work in the SFC WG<= /span>

 

Hi Carlos,

 =

Thank you for the clarif= ication. Your response highlights quite nicely the issues that the chairs a= re trying to bring to the WGs attention – maybe responses to the following questions will help settle this:

 =

  1. Should the O-bit be set ONLY for OAM pack= ets that are specific to the SFC service layer?
  2. Should the O-bit be set in the cases where a s= olution uses the next protocol field in the NSH header? In this case what is the purpose of the O-bit given that the n= ext protocol field already indicates the expected behavior?
  3. If the O-bit is set is it the expe= cted behavior to find relevant SFC service layer OAM information in the context headers?

 =

Thanks!

 =

Jim

 =

From: Carlos Pignataro (cpignata) &l= t;cpignata@cisco.com>
Sent: Monday, February 14, 2022 10:06 AM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: Gyan Mishra <hayabus= agsm@gmail.com>; Greg Mirsky <gregimirsky@gmail.com>; sfc@ietf.org
Subject: Re: [sfc] Progression of OAM work in the SFC WG<= /span>

 

Thanks — I=1B$B!G=1B(Bd expect SFC OAM layer packets only, and wo= uld also expect a model that works equally with multilayer-oam approaches o= r with existing OAMs.

 

Thanks!

 

Carlos.

 

2/14/22 =1B$B8aA0=1B(B9:= 28=1B$B!"=1B(BJames Guichard <james.n.guichard@futurewei.com><= span lang=3D"ZH-CN">=1B$B$N%a!<%k=1B(B:

 

Hi Carlos,

 

Some responses in-line =1B$B!D=1B(B

 

From: sfc <sfc-bounces@ietf.org> On Behalf Of Carlos Pignataro (cpignata)
Sent: Sunday, Febr= uary 13, 2022 11:07 PM
To: Gyan Mishra &l= t;hayabusagsm@gmail.com> Cc: Greg Mirsky &l= t;gregimirsky@gmail.com>; sfc@ietf.org
Subject: Re: [sfc]= Progression of OAM work in the SFC WG

 

Replying to this specific email in the thread, only = because it is the latest one at this point in time, but bundling comments f= rom various places on the thread. Please find some follow-up comments and q= uestions marked =1B$B!H=1B(BCMP=1B$B!I=1B(= B, indicating the =1B$B!H=1B(BFrom=1B$B!I=1B(B, and organi= zed chronologically: 

 

James N Guichard <james.n.guichard@futurewei.com>:

 

1) The chairs have reviewed the O bit definition in= RFC 8300.  That definition is at best open to interpretation and ther= efore incomplete.  For example, the clear intention is only to mark packets which are intended for SFC OAM at the SFC service = layer.  But that is not what the current text says.  There is als= o, unfortunately, ambiguity as to what constitutes an OAM packet.  So = it is reasonable for documents to update 8300 to clarify the exact applicability and action for the O-bit.

 

CMP: It is unclear to me what exact issues the chair= s are calling out. There are two issues mentioned:

CMP: 1. "But that is not what the current text = says.=1B$B!I=1B(B —> what does the tex= t say precisely?  Can you point to the specific RFC 8300 text that is = believed to be incomplete, and a detailed use case that showcases the potential issue? An extrapolated counter-example just to make a point:= the text does not  say what days of the week OAM packets can be marke= d, yet there=1B$B!G=1B(Bs an expectation that t= hey will work Mondays and Saturdays all the same — even holidays.

 

Jim> Currently RFC8300 says =1B$B!H=1B(BThe O bit MUST be set for=
 OAM packets and MUST NOT be set for non-OAM packets=1B$B!I=1B(B. T=
he first issue is does this mean the O bit should be set for ALL OAM packet=
s regardless of whether they belong to the NSH service plane? Or should it =
only be set for SFC OAM packets? And what exactly is an SFC OAM packet as t=
he earlier reference to RFC6291 is just a generate set of guidelines for th=
e use of the term OAM. The second issue is that if that O bit is set then G=
reg=1B$B!G=1B(Bs document is in conflict with IOAM as both use the next pro=
tocol field and even if the O bit is set it is meaningless as the protocol =
action is based solely on the setting of the next protocol field. So in thi=
s case can their solutions simply ignore what RFC 8300 says e.g. MUST set t=
he O bit? Or if they set the O bit to be conformant to what RFC 8300 says t=
hen do we need clearer rules stating what to do if the next protocol field =
is NOT an OAM next protocol such as the context headers should then be exam=
ined?

 

 

CMP: 2. What specifically is the ambiguity with what= an OAM packet is? Please grep the RFC series for =1B$B!H=1B(Boam packet=1B$= B!I=1B(B, it is not a new term. 

CMP: Net-net, O-bit=3D1, OAM packet. 

 

Jim> ambiguity is whether it is only SFC OAM pac= kets that are being discussed or ALL OAM packets nothing that some might be= at the service layer and some might not.

 

Jim

 

2) However, related to point 1), we can't have mult= iple documents updating the definition differently.  As such, the auth= ors of the SFC iOAM draft and the SFC multi-layer-oam draft need to come together and figure out what the clarification is for t= he definition of that bit. We do not believe as chairs that either of these= documents can move forward from the WG until such clarity has been reached= .

 

CMP: If there is still believed to be an ambiguity o= r a clear opportunity for improving the definition, I agree with consolidat= ing that update. I had suggested before that if such new text or real clari= fication is agreed, a separate document that only makes that O-bit clarification is the most clear and clean way t= o go. That doc should be a one-pager or less. I=1B$B!G= =1B(Bd be happy to contribute to that minimal doc, if it is shown to= be needed.

 

CMP: For completeness also, the "SFC multi-laye= r-oam=1B$B!I=1B(B document has many outstanding= issues besides the O-bit.

 

Greg Mirsky <gregimirsky@gmail.com>

 

I've reviewed our SFC OAM documents and draft-ietf-s= fc-nsh-tlv. As I understand these documents, the Active SFC OAM and IOAM ar= e identified by the respective values for the NSH Next Protocol field (to b= e assigned by IANA).

 

CMP: There is a major issue with the sentence above.= Active SFC OAM (as a category), as per RFC 8300, needs to be identified by= setting the O-bit. No way around that based on RFC 8300. However, the text= "the Active SFC OAM=1B$B!I=1B(B creates confusion since it refer to a specific OAM protocol which has the = same name as a the category as well. That name collision is quite unfortuna= te in my opinion.

 

At the same time, so far no OAM-specific meta data T= LV has been defined. Thus, it appears that one way forward could be to not = involve the O bit in the active SFC OAM or IOAM altogether. In other words,= to deprecate the NSH O bit.

 

CMP: RFC 8924 already includes ICMP and BFD as examp= le SFC Action OAM protocols. Those can be encapsulated in IP, in which the = Next-Protocol indicates IP — and (as per RFC 8300) the O-bit is set = to indicate an OAM packet.

CMP: The proposal of deprecating the O-bit breaks th= ose SFC OAM protocols already included in an RFC.

CMP: That proposal of deprecating the O-bit also bre= aks Section 4.1 of IOAM.

CMP: This expired I-D yet implemented in open source= uses the O-bit: https://www.ietf.org/archive/id/dra= ft-penno-sfc-trace-03.txt 

 

 

Gyan Mishra <hayabusagsm@gmail.com>

 

I agree that what makes sense to me as a path forwar= d is to deprecate the O bit and not use in SFC Multilayer OAM and SFC IOAM,= as both SFC Multilayer OAM and SFC IOAM are identified by the re= spective values for the NSH Next Protocol field (to be assigned by IANA), as well as so far no OAM-specific meta data TLV = has been yet defined.

 

CMP: What is the =1B$B!H=1B(BSFC Multilayer OAM=1B$B!I=1B(B?=

CMP: The O-bit (reading RFC 8300) does not indicate = if there is OAM Metadata. It indicates an OAM packet.

 

 

"Joel M. Halpern" <jmh@joelhalpern.com>

 

As far as I can tell, if we deprecate the O-bit and = rely on the next protocol field, we are saying that in practice (not by rul= e) NSH metadata can not be used for OAM.  That's fine with me as long = as we agree on that.

 

CMP: I do not fully follow this. Can you explain the= relationship of the O-bit with Metadata?

CMP: Here=1B$B!G=1B(Bs a= n example: RFC 8924 shows ICMP as Active OAM. The SFC next protocol is IP, = the IP next protocol is ICMP, the O-bit needs to be set. 

 

CMP: Consider the following document, independent su= bmission and in the RFC Publication queue already:

CMP: Is a Timestamp in Metadata an OAM element? = ;

 

CMP: Where the base header borrows a bit for an OAM = function.

 

CMP: Neither of those have any impact on the O-bit.&= nbsp;

 

 

Greg Mirsky <gregimirsky@gmail.com>

 

I agree that, as we find SFC NSH now, no OAM metadat= a has been defined. It appears to me that deprecating the O bit does not af= fect any of the already defined mechanisms in the SFC NSH.

 

CMP: It actually does, see my example above.



I think that if a new, for example, MD Type =3D 2 TL= V that is used for any OAM functionality to be proposed in the future,= deprecated the O bit would not prevent using such NSH TLV.=

 

CMP: I agree with this — = because there is no correlation between MD Type field and O-bit as d= efined.

 

Best,

 

Carlos.

 

 



2/13/22 <= /span>=1B$B8a8e=1B(B12:32= =1B$B!"=1B(BGyan Mishra <hayabusagsm@gmail.com>=1B$B$N%a!<%k=1B(B:

 

Hi Joel

 

I am in agreement as well with what you have stated = that once the O bit is deprecated that NSH metadata cannot be used for OAM = and that we would have to now from that point forward rely on the next prot= ocol field as we will be doing for SFC Multilayer and SFC IOAM drafts as well as will have backwards compatib= le with any already existing defined mechanisms in SFC NSH.  

 

I don=1B$B!G=1B(Bt see a= ny issues or impact with moving forward.

 

Kind Regards 

 

Gyan

 

On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky <gregimirsky@gmail.com> wrote:<= o:p>

Hi Joel, =

I agree that, as we find SFC NSH now, no OAM metadat= a has been defined. It appears to me that deprecating the O bit does not af= fect any of the already defined mechanisms in the SFC NSH. I thin= k that if a new, for example, MD Type =3D 2 TLV that is used for any OAM functionality to be proposed in the future, = deprecated the O bit would not prevent using such NSH TLV.<= /p>

What do you think?

 

Regards,

Greg

 

On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:

There is an implication of deprecating the O-bit tha= t I would like to 
hear from more WG participants about.

As far as I can tell, if we deprecate the O-bit and rely on the next 
protocol field, we are saying that in practice (not by rule) NSH 
metadata can not be used for OAM.  That's fine with me as long as we 
agree on that.

Yours,
Joel

On 2/13/2022 2:52 AM, Gyan Mishra wrote:
> 
> Hi Jim, Joel & SFC WG,
> 
> I agree that the RFC 8300 definition of O bit is incomplete and not 
> clear as to its intended use.
> 
> That is a problem that I agree needs to be rectified.
> 
> I understand that we need to get this resolved before we can progress<= span class=3D"apple-converted-space"> 
> Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC IOAM.
> 
> I agree that what makes sense to me as a path forward is to deprecate<= span class=3D"apple-converted-space"> 
> the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC<= span class=3D"apple-converted-space"> 
> Multilayer OAM and SFC IOAM are identified by the respective values fo= r 
> the NSH Next Protocol field (to be assigned by IANA), as well as so fa= r 
> no OAM-specific meta data TLV has been yet defined.
> 
> So we have I believe solid solution and path forward and I support 
> deprecating the O bit.
> 
> Kind Regards
> 
> Gyan
> 
> On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky <gregimirsky@gmail.com 
> <mailto:= gregimirsky@gmail.com>> wrote:
> 
>     Thank you, Jim and Joel, for guiding the SFC OAM wo= rk and pointing
>     out the issue that must be addressed.
> 
>     I've reviewed our SFC OAM documents and draft-ietf-= sfc-nsh-tlv. As I
>     understand these documents, the Active SFC OAM and = IOAM are
>     identified by the respective values for the NSH Nex= t Protocol field
>     (to be assigned by IANA). At the same time, so far = no OAM-specific
>     meta data TLV has been defined. Thus, it appears th= at one way
>     forward could be to not involve the O bit in the ac= tive SFC OAM or
>     IOAM altogether. In other words, to deprecate the N= SH O bit.
> 
>     I greatly appreciate your comments on the proposal = to deprecate the
>     NSH O bit.
> 
>     Regards,
>     Greg
> 
>     On Wed, Feb 2, 2022 at 10:36 AM James Guichard
>     <james.n.guichard@futurewei.com
>     <mailto:james.n.guichard@futurewei.com>> wrot= e:
> 
>         Hi WG:____
> 
>         __ __
> 
>         Having reviewed all of the OAM relate= d documents in our WG, the
>         chairs would like to provide a few co= mments to hopefully
>         generate discussion and forward progr= ess of this work:____
> 
>         __ __
> 
>         1) The chairs have reviewed the O bit= definition in RFC 8300. =
>         That definition is at best open to in= terpretation and therefore
>         incomplete.  For example, the cl= ear intention is only to mark
>         packets which are intended for SFC OA= M at the SFC service
>         layer.  But that is not what the= current text says.  There is
>         also, unfortunately, ambiguity as to = what constitutes an OAM
>         packet.  So it is reasonable for= documents to update 8300 to
>         clarify the exact applicability and a= ction for the O-bit.____
> 
>         __ __
> 
>         2) However, related to point 1), we c= an't have multiple
>         documents updating the definition dif= ferently.  As such, the
>         authors of the SFC iOAM draft and the= SFC multi-layer-oam draft
>         need to come together and figure out = what the clarification is
>         for the definition of that bit. We do= not believe as chairs that
>         either of these documents can move fo= rward from the WG until
>         such clarity has been reached. ____ > 
>         __ __
> 
>         3) Related to the SFC iOAM, we need a= clear definition of iOAM. 
>         There seem to be differences between = the definitions in
>         published RFCs, the usage (which is n= ot a definition) in the SFC
>         draft, and the various ippm drafts.&n= bsp; Any such definition will
>         need to be vetted with the ippm worki= ng group.____
> 
>         __ __
> 
>         Again, it would be good if members of= the working group beyond
>         the two author teams spoke up about t= heir readings of the
>         documents, and their understandings o= f what we need.____
> 
>         __ __
> 
>         Yours,____
> 
>         Jim and Joel____
> 
>         __ __
> 
>         __ __
> 
>         __ __
> 
>         _____________________________________= __________
>         sfc mailing list
>         sfc@ietf.org <mailto:sfc@ietf.= org>
>         https://www.ietf.org= /mailman/listinfo/sfc
>         <https://www.ietf= .org/mailman/listinfo/sfc>
> 
>     _______________________________________________
>     sfc mailing list
>     s= fc@ietf.org <mailt= o:sfc@ietf.org> >     https://www.ietf.org/mailman/listi= nfo/sfc
>     <https://www.ietf.org/mailman/l= istinfo/sfc>
> 
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /Email gyan.s.mishra@verizon.com=  <mailto:gyan.s.mishra@veriz= on.com>//
> /
> 
> /M 301 502-1347
> 
> /
> 
> 

-- 

Gyan Mishra

Network Solutions Architect <= /p>

M 301 502-1347

 

_______________________________________________
sfc mailing list
sfc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/sfc

 

 

--_000_MN2PR13MB42069179D07E2E27D7467B88D2359MN2PR13MB4206namp_-- From nobody Wed Feb 16 06:14:07 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5983A132B for ; Wed, 16 Feb 2022 06:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 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, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.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 MWp7BJZnAcGg for ; Wed, 16 Feb 2022 06:13:58 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::723]) (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 AEF2D3A132C for ; Wed, 16 Feb 2022 06:13:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ntz99p1YY2nLiJyKPCgK9+0Cc/nJYIw5JHfRdkUFENgWNc2FjNVAyfI8xK24V4uYZ4xX6gAvE90pM6rABi0Vt+zhi6a7ll2t+29KIl6gcsC71QKvqBph/VYc3xQSgWA/LqMLJj0xefXhqc2wAgKoqJTFip372t/a3Kh0DtJQzCK86igIalwzuaEb0VQfx6QjpEN2i83Hr29NtjwE3HBk74qZERbp7JhZbJ2gQPYptMrxBAW5W1umGVs8sSNqwjCNPOO5o41lzOGPvU/GB/xZf4Ai+XW6EXSuviXp2GgSFQgoHwTqQonjjJiKT8JBwjaXbUkppLhysoTZGEMLb8P/Qg== 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=0hTncDGWbzXi8+QSGhjVLyWlVzgI9/MdNK7p5j1PWdM=; b=mF1+NbStvZgkkYQbHSroiP0AkPT894ZJeMa/0n3ER4jt+OqFm67E2n/k+J4cowjvRYENscHqeWhJKO4HO7QzG0NL02Rfh/8tJm6dyEZPeTzz2qc1fi1g/6wMVxTCJYs7lVZla6ZJMq+10kEHBbrWDe3fepUrDqpfOEVxniVdBbrkXrLFlMSlKJ0mu/h5/U5IY9dOk8TZanomnysG2FV0XUJ/TxB68nhAmX06uOwYiPJ/+vY3vcspKeyKqI5x4DsYOtOGy3A8NuAcT9ufvVAHUAc1Hqu6sgZKey++eyFlaT3crkBXyE3k26BaGm69Qk+KKx7J6BNU0pY9uZq/EEsKjA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0hTncDGWbzXi8+QSGhjVLyWlVzgI9/MdNK7p5j1PWdM=; b=QroVoU5F225dCwQEsvQPeXSu+eNTl4U7p3SjH2J++A1ivzR6SsfeP80m6Ljfv3PBOgwF5RfzJQL7l24nyX7okjovZd6sT5QOuaRQnAPmihaCl5sCu4bnJXgPobZSetfZd+ncimoR2NIYQZ8PN4AvNrewZG/e/4YVB8RzWl7nmYs= Received: from VE1PR06MB7150.eurprd06.prod.outlook.com (2603:10a6:800:1a5::19) by AM8PR06MB7491.eurprd06.prod.outlook.com (2603:10a6:20b:365::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.14; Wed, 16 Feb 2022 14:13:37 +0000 Received: from VE1PR06MB7150.eurprd06.prod.outlook.com ([fe80::a506:e6e5:976a:e0ff]) by VE1PR06MB7150.eurprd06.prod.outlook.com ([fe80::a506:e6e5:976a:e0ff%3]) with mapi id 15.20.4995.014; Wed, 16 Feb 2022 14:13:37 +0000 From: "Diego R. Lopez" To: Gyan Mishra , "Joel M. Halpern" CC: "sfc@ietf.org" Thread-Topic: [sfc] Future of SFC work Thread-Index: AQHYFHoOqlddSIMN6E+bVCBNrr/X46yVm/kAgADKnAA= Date: Wed, 16 Feb 2022 14:13:37 +0000 Message-ID: <5AB114DA-0064-48B8-8C92-F1F71535B7D3@telefonica.com> References: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=telefonica.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 15a80cf8-a7ed-423d-3119-08d9f1568644 x-ms-traffictypediagnostic: AM8PR06MB7491: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: 57JH2i/FX9Eo7Z0W6tzRCRcWlkK73kpTErzmEEBQ7K8Ohw9fjm80qhbg0GtaE3xWsOH21PKNd6KynPGbegtVrLIF2TGXNNFhN26+ysE3s4IWcWIaZ//o70DOhsFFRJofZGneK5x78AGBZlvOlS1jHIyrANjZ7NfJZTBwnwBHKuz2/PsaHqZ3seG8yln3v8cZeNXdBvUQZkCd1XS2O0Cc4+omFlpdSWYqMWSujMR5xW4Ev+a2eG1S7iQLZgLiK+G/lwYmI8rCibLRowFxz8h6VEIODWdtVG3VQAwsTzzvohx9DkJfZ+BKXMKesPB1Mo/c579O+l5RRf5yERimTZbIvV6ItyRcSqRXnCAGurUlr4vweTflmDThkBtwtZjXOkHdaMhNGkt5dqxMJXK2mtA6c0d5Zbb05fui1Zm03eZC2BNAfxVuoMK+nJ+dWQaweBUcJ0e7rhfcOqWLWInziKCT5fFUWX18q1aXuoPgerzt6natwlDvRS/wGaS5uaLtXIwQAj2gzmyCl8mbLZ0Xg4b5esVyYQJbSup2O0yqbLIVMu9c/ZE5SD7/TeCSGef3gN3jU2EqWQoRL0cxgsFNeX73OlVIJrbZi2+tFuONfuP1AhkhPfxPv7Twx16Qe1yq+UbdvgmZzdzze9udWLNFphJe5x768MNmw6oITwlTJuUn998V7oDGIOjMHG3j6uqiMD32XY5BpyWRY8oah4rM4vCzGLMpgWiWnICUNOLEgKY8oqb9wgOePuIpbd/0EOolL5yCVFQRe825nCW/FMDci1d1yNqX8Gk1T1LqT8ERgBI5GRN1FxURzTdKtOUXA+QQ/Jjlx3DZWzUIxSfuRbNcbBoxK/JAKM+lRzpZeD2aI/OYAjo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VE1PR06MB7150.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(4326008)(86362001)(83380400001)(82960400001)(76116006)(66946007)(8936002)(8676002)(316002)(2906002)(36756003)(6512007)(186003)(66574015)(5660300002)(91956017)(26005)(66556008)(66446008)(66476007)(64756008)(110136005)(38070700005)(6486002)(966005)(40140700001)(122000001)(53546011)(2616005)(166002)(6506007)(45080400002)(38100700002)(508600001)(33656002)(71200400001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eVBnT3pqQWlXNWtFcWNmRXdya2hRVjRZNVYwdXZ4bncwVHNKT1FOZGN4cTFY?= =?utf-8?B?cUxuajZOM0VIdEZ2K2Fab2JzS1psc0ZDMW1IeE1wVWNjWmZQSzJxZWM4ZXdi?= =?utf-8?B?dU80WGtzV3JZYTUvWmNWSVZHWVErR2dXSzJkby9oeXF6NVo3eHFIUldNdzNY?= =?utf-8?B?ZHpVZ2tpZmo2SDhVWnl2by8ranFIZCszYkJEY2UrOGh0ZEVsbFZ6SlBqR1Yw?= =?utf-8?B?Yy9Wb0NtRFVjNmQ5bXhlMHVBQnJEWDBMdE5oR29zVDFRSkIzUENoUDE1d09D?= =?utf-8?B?YlRJbGxGSGtEY1FDUDkrbHRJS3Qwam5QVjFpM0d4bUJhdVJsZ1ZtdG1ES1Fp?= =?utf-8?B?U0JGZGtjUUM1WE1kUVBVOUFCVkpYL0VIY0VrN1A0bEVsOUUzQU9Zc2VpN1Ju?= =?utf-8?B?WkVlWkNYTHJ0VXpzd2RCYmxaUkY5Qk1WR1dYbzYrR0ZzbjUrNnFOcVlLQlE3?= =?utf-8?B?TjdidEhKSDlrNUs3VHNxMnRJS3V4Q3d2NmRMV0VwQTV1VXhHT1JPRW9nQkVY?= =?utf-8?B?MVlpQ0Vua0tSQ040MzFCQzFsQnA1UGt4T1AyRnRFbVlaV0NjOVA1cmk1a3pQ?= =?utf-8?B?akpqcGh0MGQvemZkUjgxSnNFUGNuN3Fha0VJWVdpTU5wdlhGdm9oTjhxWXRT?= =?utf-8?B?Y0wvQ25kVlp5cjR6SG1MT0hrSVFsSXZPbjdySS9jUlpoZVhzWVRJMFFianF3?= =?utf-8?B?aXV5WkxxL0NmN2Q0ZkJhTFJEUE1ySThNVnVBYldGdnhIb0pEckVQcVFIRk4y?= =?utf-8?B?RVlhTUhDbERKTDNvTG5mYVNvWVlRZHEvWlFsSG5BK3hheStiUGdjdGswb1Fi?= =?utf-8?B?M3BKTXZxaldPdUMxODdLckFyajlrUm5VdklqQTU4T1RvVm5GQjdIQTRONm51?= =?utf-8?B?b3FjblpyWXE0UUd0aldXYVdMbkpLNUF1em5MUmpNNGFsU0VkY2FWRTFjZFdu?= =?utf-8?B?VkdKdnh0dXNpYjhvUE13bFl1SmJiZExMOHRCbXlWUDRlMW52TGkrNzRRaUU5?= =?utf-8?B?aHZPVHF2TFlCc3QwR0tpNkRlQXFNZTNZVElCRi9HcjUzN1ZJQXExajdRdGtr?= =?utf-8?B?dHhFVm8xcVBlSWE5bElJZHBXMnV4cHNubndHYWh1aUQwZ0k4UXB1eVhlVnQ1?= =?utf-8?B?QlRkNm1iQlVOQVhielVicXlVazRQRkFMWi95RE1FYkQ1UENIbmMzbC9yK1V1?= =?utf-8?B?eGc1ZWJCSVl3NzQyQVc1ZUNoNi82UFljNHFFV1pQWnRUTmdFNTdhU2ROc2ph?= =?utf-8?B?ZC9pNVF6c1FiUDZUblc1b1l1VllSSC9uQVdrclFlSWRlZjBUSWZYdTJkdEtH?= =?utf-8?B?a0Jad1F2SlhRQ2F3YitraC9ZMzVuNmJocDVHc1FnakJMb1d0eGlDN2JDNnRH?= =?utf-8?B?TWJFVElCaGRkdWw2bGNLeWJTZ2JOMFdxZFRxcUgwUXJ1Z1M2Z2FmY1RjRXdu?= =?utf-8?B?cW0wR2loVVBQQk9sSURJWFRsOE9CNGc3OWtzR1RybDBsSnJpbkFyT0I1dWEx?= =?utf-8?B?SDBRYjNHaUxmV3VYaWNMWVpyRVJrdlZqV2dNUiswM1BrdmxrTjZ5VXVnM0lk?= =?utf-8?B?NVJBQXROd01HeUtGUDBLNGtDSmNCcnJpZXZoMnNKdEt2enpwb20yTkNnNmJl?= =?utf-8?B?WVVBRlBER1hsZE0wV09EdDdYcTdwVWpPckZPbTZpMStQSjU0S0xwMHNpTmJt?= =?utf-8?B?RVVXOFFFTUtHVUxpSTdlQmJsSllPNEpWaTJkMGNzR2NKekptd0lyVy9SL3l3?= =?utf-8?B?YThUSmJ2SjRSVENRTzYvNU5uclNaYjYxN1ZhRXRnV2NCWkFKVzdyekFmZzEx?= =?utf-8?B?OURzNEh3UVpEdGxidjAzenlMcnN3eklRaEI2alMvUWRPdXVjWUc5Yk1nRU5z?= =?utf-8?B?WkRydkNrcnJvTFZIS1FIK3FtTDh1dTAvRW5DeXR0eGp2Tkd0REZyV3JkNTYv?= =?utf-8?B?MmhveC9Wd21yV0N0WEFrVzZUaURXdUw3SzhSQU9ya0orcWVuamRRczFPK1hV?= =?utf-8?B?ckVIdWtOblpETTJsY3NPL3djZGpQMU41aE40TmRXRFgvaXpTVFpWYzdvNU5B?= =?utf-8?B?SjhtN3A4ZWtiSXBxUCtuai9WY3RubDJERWh1c3pPYlVwTjd4enpjbHorOVhx?= =?utf-8?B?OGdSOGhoMVFTbVk2OGNjN2loKzl0UXkyVVd6RzhUNzZXS04yWG42M2pteVps?= =?utf-8?B?TFFOSC95RS9JaGFneE92bDFvWkxOZ0dYREYyUkNwejZJcUVaTU9pYWtlbWQ3?= =?utf-8?Q?d2wln6J6PFSpXBe2ZvBmzqzPDfIkTehdgTXHdLp0JM=3D?= Content-Type: multipart/alternative; boundary="_000_5AB114DA006448B88C92F1F71535B7D3telefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR06MB7150.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15a80cf8-a7ed-423d-3119-08d9f1568644 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2022 14:13:37.0795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 24yD+WQQXoCY4SHvLtgLkoQizuPAGZp9swHwLNuLXIAVzLgqhm5OgYqbtoTZGzDNFtbiMzCWCcCQJ8TXSo3iPp4Q+9TsKSwfhi6uTjMrvkc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR06MB7491 Archived-At: Subject: Re: [sfc] Future of SFC work X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 14:14:05 -0000 --_000_5AB114DA006448B88C92F1F71535B7D3telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBhZHZhbnRhZ2Ugb2Ygd2FpdGluZyBhIHdoaWxlIGJlZm9yZSBleHByZXNzaW5n IG15IG9waW5pb24gaXMgdGhlIEd5YW4gaGFzIHBlcmZlY3RseSBkb25lIHNvICh0aGFua3MhKS4g SSBmdWxseSBzdXBwb3J0IGhpcyBvcGluaW9uIGFib3V0IGNvbnRpbnVpbmcgU0ZDIHdvcmsuIEFu ZCBJIG11c3Qgc2F5IEkgaGF2ZSB0aGUgaW50ZW50aW9uIHRvIGNvbnRpbnVlIGJlaW5nIGRpcmVj dGx5IGludm9sdmVkIGluIHNvbWUgd29yayBvZiB0aGUgZ3JvdXAsIGFzIEkgd2FzIGluIHRoZSBj b21wb3NpdGlvbiBkcmFmdCBvciBpbiB0aGUgUG9UIGFjdGl2aXRpZXMuDQoNCkJlIGdvb2RlLA0K DQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGll Z28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwczovL3d3dy5saW5rZWRpbi5jb20vaW4v ZHIybG9wZXovDQoNCmUtbWFpbDogZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbTxtYWlsdG86 ZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbT4NCk1vYmlsZTogICszNCA2ODIgMDUxIDA5MQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpPbiAxNi8wMi8yMDIyLCAwNDow OSwgInNmYyBvbiBiZWhhbGYgb2YgR3lhbiBNaXNocmEiIDxzZmMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBoYXlhYnVzYWdzbUBnbWFp bC5jb208bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCkhpIEpvZWws IEppbSAmIGFsbA0KDQpJIHdvdWxkIHNheSB0aGF0IG9uZSBtZWFzdXJlIG9mIHN1Y2Nlc3Mgb2Yg YSBXRyBpcyB0aGF0IHdoZW4geW91IGRvIGEgZ29vZ2xlIHNlYXJjaCwgdGhlcmUgYXJlIG1hbnkg c2Nob2xhcmx5IGFydGljbGVzIHJlbGF0ZWQgdG8gU0ZDIHNlcnZpY2UgcGxhbmUgYmVuZWZpdHMg YXMgd2VsbCBhcyB2ZW5kb3IgaW1wbGVtZW50YXRpb25zIHRoYXQgSSBrbm93IG9mIHBlcnNvbmFs bHkgd2l0aCBDaXNjbyBhbmQgSnVuaXBlciBhbmQgdGhlcmUgbWF5YmUgb3RoZXIgdmVuZG9ycyBv dXQgdGhlcmUuDQoNCkkgdGhpbmsgdGhlIFNGQyBXRyBoYXMgZ2FybmVyZWQgb3ZlcmFsbCBpbnRl cmVzdCBpbiB0aGUgdGVjaG5vbG9neSBpbmR1c3RyeSB3aWRlIGFuZCBpdOKAmXMgaW1wb3J0YW5j ZSBvZiBhIHNlcnZpY2UgcGxhbmUuDQoNCk92ZXJhbGwgSSB3b3VsZCBzYXkgaGF0cyBvZmYgdG8g dGhlIGNoYWlycyBhbmQgV0cgbWVtYmVycyBhbmQgYWxsIHRoZSBoYXJkIHdvcmsgIGFzIHRvIHRo ZSBzdWNjZXNzISEhDQoNCkFzIGZhciBhcyBjb21tZW50YXJ5IGFuZCBpbnZvbHZlbWVudCBpbiBk cmFmdHMsIHRoYXQgaXNzdWUgZXhpc3RzIGFjcm9zcyB0aGUgYm9hcmQgYXMgSSBhbSBhIG1lbWJl ciBvZiBldmVyeSBSb3V0aW5nIEFyZWEgV0csIDU0IFdHcyBpbiB0b3RhbCBJIHdvdWxkIHNheSB0 aGUgaW50ZXJlc3QgYW5kIGludm9sdmVtZW50IGhhcyBiZWVuIGFzIHdlbGwgd2l0aCBvdGhlciBX R3MgcmVsYXRlZCB0byBwZXJzb25hbCBkcmFmdHMgYmVpbmcgcHJvZ3Jlc3NlZCBieSBpbmRpdmlk dWFscyBzbyBJIGRvbuKAmXQgdGhpbmsgaXTigJlzIGp1c3QgYW4gaXNzdWUgd2l0aCBTRkMgV0cu ICBNeSBvYnNlcnZhdGlvbiBoYXMgYmVlbiB0aGF0IHdoZW5ldmVyIG11bHRpcGxlICB2ZW5kb3Jz IGhhdmUgY29tcGV0aW5nIHNvbHV0aW9ucyB0aGV5IHdhbnQgdG8gZ2V0IHRvIFdHIGFkb3B0aW9u IGFuZCBwcm9ncmVzc2lvbiwgIHRob3NlIGFyZSB0aGUgaG90IG9uZXMgdGhhdCBoYXZlIHRyZW1l bmRvdXMgaW50ZXJlc3QuICAgQXMgd2VsbCB0aGVyZSBhcmUgaG90IHRvcGljcyBhbmQgdGhlIGhv dCB0b3BpY3Mgd2l0aCBkcmFmdHMgdGhhdCBoYXZlIGFsbCB0aGUgbWFqb3IgdmVuZG9ycyBpbnZv bHZlbWVudCBnZXQgdGhlIG1vc3QgZmVlZGJhY2sgYW5kIG9mIGNvdXJzZSBwcm9ncmVzcyBxdWlj a2x5LiAgVGhlIGtleSBpcyBnYXJuZXJpbmcgbXVsdGkgdmVuZG9yIGludGVyZXN0IGFuZCBzdXBw b3J0IHRvIHByb2dyZXNzIGFuIGlkZWEgd2hpY2ggZ29lcyBmb3IgU0ZDIGFuZCBhbnkgV0cuDQoN CkluIG15IG1pbmQgTkZWIGJyb3VnaHQgYWJvdXQgdGhlIGNvbmNlcHQgb2YgdGhlIG5lZWQgZm9y IHNlcnZpY2UgY2hhaW5pbmcgb2YgVk5GIGluc3RhbmNlcyBhbmQgbm93IFNGQyBoYXMgYnJvYWRl bmVkIHRoZSB1c2UgY2FzZSB3aXRoIE5TSCBzZXJ2aWNlIHBsYW5lIGJleW9uZCBORlYgd2l0aCBw aHlzaWNhbCBoYXJkd2FyZSBlbmRwb2ludHMgYW5kIGFueSB2aXJ0dWFsaXphdGlvbiBtb2RlbC4N Cg0KSSBhbSBpbiBmYXZvciBvZiBleHBhbmRpbmcgdGhlIHNjb3BlIG9mIHRoZSBXRyB0byBpbmNs dWRlIGluIHRoZSBjaGFydGVyIGFueSBuZXR3b3JraW5nIGFyZWEgdGhhdCBpbnZvbHZlcyB2aXJ0 dWFsaXphdGlvbiBzdWNoIGFzIERDIE5WTyBlbmNhcHN1bGF0aW9uIG92ZXJsYXlzIHN1Y2ggYXMg VlhMQU4gd2hlcmUgSSBzZWUgQ2lzY28gYW5kIEp1bmlwZXIgYXJlIHByb3ZpZGluZyB0aGVpciBv d24gb24gc3RhbmRhcmRpemVkIG1ldGhvZHMgc2VydmljZSBjaGFpbmluZyB0aGF0IGlzIFNGQyBh bmQgU0ZDIE5TSCBpbmRlcGVuZGVudCB3aGVyZSBJIHRoaW5rIHRoZWlyIGNhbiBiZSB0cmVtZW5k b3VzIGJlbmVmaXRzIGFzIHdlbGwgYXMgd2hlbiBleHRlbmRpbmcgdGhlIGZhYnJpYyB0byB0aGUg aG9zdCBiZWluZyBhYmxlIHRvIHVzZSBTRkMgTlNIIHNlcnZpY2UgcGxhbmUgdG8gbGluayB0aGUg U0ZGIGluc3RhbmNlcy4gICBJIHRoaW5rIGFzIHdlbGwgbWF5YmUgZm9yIFRFQVMgbmV0d29yayBz bGljaW5nIHdpdGggNUcgdmlydHVhbGl6YXRpb24gdGhlIHVuZGVybGF5IG5ldHdvcmsgc2xpY2Ug YW5kIG5vdyBpbmNvcnBvcmF0aW5nIFNGQyBOU0ggc2VydmljZSBwbGFuZSBpbnRvIDVHIFVFIHNl cnZpY2VzIG5ldHdvcmsgc2xpY2luZyBOU0Mgc2xpY2UgY29udHJvbGxlci4gIFRoZXJlICBtYXli ZSBhcyB3ZWxsIGZvciBPVE4gTDFWUE4gYW5kIENDQU1QIFdHcyBtYXliZSBhIHBvc3NpYmlsaXR5 IG9mIFdHIGNoYXJ0ZXIgZXhwYW5zaW9uIGludG8gdGhhdCBhcmVuYSBTRkMgTlNIIHBvc3NpYmxl IGNvbnNpZGVyYXRpb25zLg0KDQpTcHJpbmcgV0cgU2VnbWVudCBSb3V0aW5nIGluIG15IG1pbmQg YXMgaXTigJlzIGFsbG93cyB0aGUgYWJpbGl0eSBmb3IgdmlydHVhbGl6YXRpb24gYW5kIGFic3Ry YWN0aW9uIG9mIHRoZSB1bmRlcmxheSB3aXRoIFNSLVRFIG1pY3JvIGZsb3cgYW5kIG1hY3JvIGZs b3cgcGF0aCBzdGVlcmluZyBhbmQgaXQgbGVuZHMgaXRzZWxmIHRvICBiZSBhIGNyaXRpY2FsIGNv bXBvbmVudCBvZiBURUFTIG5ldHdvcmsgc2xpY2luZywgSSBiZWxpZXZlIHRoYXQgU0ZDIE5TSCBz ZXJ2aWNlIHBsYW5lIGNhbiByZWFsbHkgdGFrZSBvZmYgaW4gdGhhdCBhcmVhIHdpdGggYSBteXJp YWQgb2YgdXNlIGNhc2VzIGFjcm9zcyB0aGUgYm9hcmQuICBJIGJlbGlldmUgd2l0aCB0aGUgYWR2 ZW50IG9mIFNSIHJlYWxseSBicmluZ3MgdG8gbGlnaHQgdGhlIGNyaXRpY2FsaXR5IG9mIFNGQyBO U0ggc2VydmljZSBwbGFuZS4NCg0KDQpJIHdvdWxkIGJlIGhhcHB5IHRvIHdvcmsgb24gYWxsIGV4 aXN0aW5nIGRvY3VtZW50cyBiZWluZyBwcm9ncmVzc2VkIHRoYXQgSSBhbSBpbnZvbHZlZCBhcyB3 ZWxsIGFzIHdvcmtpbmcgb24gYW55IEkgYW0gbm90IGludm9sdmVkLCBhcyB3ZWxsIGFzIHdpdGgg dGhlIHJlY2hhcmdlciBleHBhbnNpb24sIGFueSBmdXR1cmUgZGV2ZWxvcG1lbnQgbmV3IHdvcmsu DQoNCktpbmQgUmVnYXJkcw0KDQpHeWFuDQoNCk9uIEZyaSwgSmFuIDI4LCAyMDIyIGF0IDI6MDUg UE0gSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tPj4gd3JvdGU6DQpTRkMgV29ya2luZyBHcm91cDoNCg0KICAgICBBcyBwYXJ0IG9m IGRpc2N1c3NpbmcgdGhlIE9BTSBlbGF0ZWQgZHJhZnRzIGluIFNGQywgdGhlIGNoYWlycyBoYXZl DQpiZWVuIGxvb2tpbmcgYXQgdGhlIG92ZXJhbGwgd29ya2luZyBncm91cCBwYXJ0aWNpcGF0aW9u LiAgV2Ugbm90ZSB0aGF0DQp2ZXJ5IGZldyBwZW9wbGUgaGF2ZSBzcG9rZW4gdXAgYWJvdXQgdGhl IGlzc3VlcyBiZWluZyBkaXNjdXNzZWQuICBGb3INCm1vc3QgcmVjZW50IGRyYWZ0cyB3ZSBoYXZl IGJlZW4gd29ya2luZyB0byBhZHZhbmNlLCBpdCBoYXMgYmVlbiBhIGxvdCBvZg0Kd29yayB0byBn ZXQgZW5vdWdoIGNvbW1lbnRzIHRvIGp1c3RpZnkgYWR2YW5jZW1lbnQgKGFuZCBmb2xrcyBjb3Vs ZA0KYXJndWUgdGhhdCB3ZSBkaWQgbm90IHN1Y2NlZWQuKQ0KDQogICAgIFdlIGFyZSBjb25zaWRl cmluZyB2YXJpb3VzIGFsdGVybmF0aXZlcy4gIFdlIGNvdWxkLCBmb3IgZXhhbXBsZSwNCmp1c3Qg Y2xvc2UgdGhlIHdvcmtpbmcgZ3JvdXAuDQpPbmUgcG9zc2liaWxpdHkgaXMgdG8gcmVjaGFydGVy IHRoZSB3b3JraW5nIGdyb3VwIHRvIGV4cGFuZCB0aGUgc2NvcGUuDQpUaGVyZSBhcmUgdHdvIHJl bGF0ZWQgcXVlc3Rpb25zIHRoYXQgd2Ugd291bGQgbGlrZSB0byBoZWFyIGZyb20gdGhlDQp3b3Jr aW5nIGdyb3VwIGFib3V0IHRoaXMuDQoNCjEpIElmIHdlIHdlcmUgdG8gY29uc2lkZXIgZXhwYW5k aW5nIHRoZSBjaGFydGVyLCB3aGF0IHRoaW5ncyB3b3VsZCB5b3UNCmxpa2UgdG8gc2VlIGluY2x1 ZGVkIGluIGl0Pw0KDQoyKSBJZiB3ZSBkbyByZWNoYXJ0ZXIgd2lsbCB5b3Ugd29yayBvbiB0aGUg ZXhpc3RpbmcgZG9jdW1lbnRzLCBhbmQgd2lsbA0KeW91IGVuZ2FnZSBvbiBkb2N1bWVudHMgb3Ro ZXIgdGhhbiB0aGUgb25lIG9yIHR3byB5b3UgcGVyc29uYWxseSB3b3VsZA0KbGlrZSB0byBzZWUg aW5jbHVkZWQ/DQoNClRoYW5rIHlvdSwNCkpvZWwgYW5kIEppbQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KLS0NCg0KW0ltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLl08aHR0cDovL3d3 dy52ZXJpem9uLmNvbS8+DQoNCkd5YW4gTWlzaHJhDQoNCk5ldHdvcmsgU29sdXRpb25zIEFyY2hp dGVjdA0KDQpFbWFpbCBneWFuLnMubWlzaHJhQHZlcml6b24uY29tPG1haWx0bzpneWFuLnMubWlz aHJhQHZlcml6b24uY29tPg0KDQpNIDMwMSA1MDItMTM0Nw0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2Vu IGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1h Y2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZv IGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBk ZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEs IHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBw dWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRl LiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBu b3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9j ZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgdHJhbnNtaXNzaW9uIGlzIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBu YW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lv biBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0 aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVy cm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNl IGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVy IGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28g ZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZv c3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRl IHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNl bSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xh w6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9z LWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlh IGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== --_000_5AB114DA006448B88C92F1F71535B7D3telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2VvcmdpYTsN CglwYW5vc2UtMToyIDQgNSAyIDUgNCA1IDIgMyAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tRVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIGFkdmFu dGFnZSBvZiB3YWl0aW5nIGEgd2hpbGUgYmVmb3JlIGV4cHJlc3NpbmcgbXkgb3BpbmlvbiBpcyB0 aGUgR3lhbiBoYXMgcGVyZmVjdGx5IGRvbmUgc28gKHRoYW5rcyEpLiBJIGZ1bGx5IHN1cHBvcnQg aGlzIG9waW5pb24gYWJvdXQgY29udGludWluZyBTRkMgd29yay4gQW5kDQogSSBtdXN0IHNheSBJ IGhhdmUgdGhlIGludGVudGlvbiB0byBjb250aW51ZSBiZWluZyBkaXJlY3RseSBpbnZvbHZlZCBp biBzb21lIHdvcmsgb2YgdGhlIGdyb3VwLCBhcyBJIHdhcyBpbiB0aGUgY29tcG9zaXRpb24gZHJh ZnQgb3IgaW4gdGhlIFBvVCBhY3Rpdml0aWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CZSBnb29kZSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj4mcXVvdDtFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8mcXVvdDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+RHIgRGllZ28gUi4gTG9wZXo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPlRlbGVmb25pY2EgSStEPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy5saW5r ZWRpbi5jb20vaW4vZHIybG9wZXovIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6 Ly93d3cubGlua2VkaW4uY29tL2luL2RyMmxvcGV6Lzwvc3Bhbj48L2E+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmUtbWFp bDombmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJtYWlsdG86ZGllZ28uci5sb3Bl ekB0ZWxlZm9uaWNhLmNvbSI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5k aWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pk1vYmlsZTogJm5ic3A7KzM0IDY4MiAwNTEgMDkxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMTYvMDIvMjAyMiwgMDQ6MDks ICZxdW90O3NmYyBvbiBiZWhhbGYgb2YgR3lhbiBNaXNocmEmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJl aGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbSI+aGF5YWJ1c2Fn c21AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5IaSBKb2VsLCBKaW0gJmFtcDsgYWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPkkgd291bGQgc2F5IHRoYXQgb25lIG1lYXN1cmUgb2Ygc3VjY2Vz cyBvZiBhIFdHIGlzIHRoYXQgd2hlbiB5b3UgZG8gYSBnb29nbGUgc2VhcmNoLCB0aGVyZSBhcmUg bWFueSBzY2hvbGFybHkgYXJ0aWNsZXMgcmVsYXRlZCB0byBTRkMgc2VydmljZSBwbGFuZSBiZW5l Zml0cyBhcyB3ZWxsIGFzIHZlbmRvciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBJIGtub3cgb2YgcGVy c29uYWxseQ0KIHdpdGggQ2lzY28gYW5kIEp1bmlwZXIgYW5kIHRoZXJlIG1heWJlIG90aGVyIHZl bmRvcnMgb3V0IHRoZXJlLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+SSB0aGluayB0aGUgU0ZDIFdHIGhhcyBnYXJuZXJlZCBvdmVyYWxs IGludGVyZXN0IGluIHRoZSB0ZWNobm9sb2d5IGluZHVzdHJ5IHdpZGUgYW5kIGl04oCZcyBpbXBv cnRhbmNlIG9mIGEgc2VydmljZSBwbGFuZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk92ZXJhbGwgSSB3b3VsZCBzYXkgaGF0cyBvZmYg dG8gdGhlIGNoYWlycyBhbmQgV0cgbWVtYmVycyBhbmQgYWxsIHRoZSBoYXJkIHdvcmsgJm5ic3A7 YXMgdG8gdGhlIHN1Y2Nlc3MhISE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+QXMgZmFyIGFzIGNvbW1lbnRhcnkgYW5kIGludm9sdmVtZW50IGluIGRy YWZ0cywgdGhhdCBpc3N1ZSBleGlzdHMgYWNyb3NzIHRoZSBib2FyZCBhcyBJIGFtIGEgbWVtYmVy IG9mIGV2ZXJ5IFJvdXRpbmcgQXJlYSBXRywgNTQgV0dzIGluIHRvdGFsIEkgd291bGQgc2F5IHRo ZSBpbnRlcmVzdCBhbmQgaW52b2x2ZW1lbnQgaGFzIGJlZW4gYXMgd2VsbCB3aXRoIG90aGVyDQog V0dzIHJlbGF0ZWQgdG8gcGVyc29uYWwgZHJhZnRzIGJlaW5nIHByb2dyZXNzZWQgYnkgaW5kaXZp ZHVhbHMgc28gSSBkb27igJl0IHRoaW5rIGl04oCZcyBqdXN0IGFuIGlzc3VlIHdpdGggU0ZDIFdH LiZuYnNwOyBNeSBvYnNlcnZhdGlvbiBoYXMgYmVlbiB0aGF0IHdoZW5ldmVyIG11bHRpcGxlICZu YnNwO3ZlbmRvcnMgaGF2ZSBjb21wZXRpbmcgc29sdXRpb25zIHRoZXkgd2FudCB0byBnZXQgdG8g V0cgYWRvcHRpb24gYW5kIHByb2dyZXNzaW9uLCAmbmJzcDt0aG9zZSBhcmUgdGhlDQogaG90IG9u ZXMgdGhhdCBoYXZlIHRyZW1lbmRvdXMgaW50ZXJlc3QuICZuYnNwOyBBcyB3ZWxsIHRoZXJlIGFy ZSBob3QgdG9waWNzIGFuZCB0aGUgaG90IHRvcGljcyB3aXRoIGRyYWZ0cyB0aGF0IGhhdmUgYWxs IHRoZSBtYWpvciB2ZW5kb3JzIGludm9sdmVtZW50IGdldCB0aGUgbW9zdCBmZWVkYmFjayBhbmQg b2YgY291cnNlIHByb2dyZXNzIHF1aWNrbHkuJm5ic3A7IFRoZSBrZXkgaXMgZ2FybmVyaW5nIG11 bHRpIHZlbmRvciBpbnRlcmVzdCBhbmQgc3VwcG9ydA0KIHRvIHByb2dyZXNzIGFuIGlkZWEgd2hp Y2ggZ29lcyBmb3IgU0ZDIGFuZCBhbnkgV0cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPkluIG15IG1pbmQgTkZWIGJyb3VnaHQgYWJvdXQgdGhlIGNv bmNlcHQgb2YgdGhlIG5lZWQgZm9yIHNlcnZpY2UgY2hhaW5pbmcgb2YgVk5GIGluc3RhbmNlcyBh bmQgbm93IFNGQyBoYXMgYnJvYWRlbmVkIHRoZSB1c2UgY2FzZSB3aXRoIE5TSCBzZXJ2aWNlIHBs YW5lIGJleW9uZCBORlYgd2l0aCBwaHlzaWNhbCBoYXJkd2FyZSBlbmRwb2ludHMgYW5kIGFueSB2 aXJ0dWFsaXphdGlvbg0KIG1vZGVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5JIGFtIGluIGZhdm9yIG9mIGV4cGFuZGluZyB0aGUgc2NvcGUgb2Yg dGhlIFdHIHRvIGluY2x1ZGUgaW4gdGhlIGNoYXJ0ZXIgYW55IG5ldHdvcmtpbmcgYXJlYSB0aGF0 IGludm9sdmVzIHZpcnR1YWxpemF0aW9uIHN1Y2ggYXMgREMgTlZPIGVuY2Fwc3VsYXRpb24gb3Zl cmxheXMgc3VjaCBhcyBWWExBTiB3aGVyZSBJIHNlZSBDaXNjbyBhbmQgSnVuaXBlciBhcmUgcHJv dmlkaW5nDQogdGhlaXIgb3duIG9uIHN0YW5kYXJkaXplZCBtZXRob2RzIHNlcnZpY2UgY2hhaW5p bmcgdGhhdCBpcyBTRkMgYW5kIFNGQyBOU0ggaW5kZXBlbmRlbnQgd2hlcmUgSSB0aGluayB0aGVp ciBjYW4gYmUgdHJlbWVuZG91cyBiZW5lZml0cyBhcyB3ZWxsIGFzIHdoZW4gZXh0ZW5kaW5nIHRo ZSBmYWJyaWMgdG8gdGhlIGhvc3QgYmVpbmcgYWJsZSB0byB1c2UgU0ZDIE5TSCBzZXJ2aWNlIHBs YW5lIHRvIGxpbmsgdGhlIFNGRiBpbnN0YW5jZXMuICZuYnNwOyBJIHRoaW5rDQogYXMgd2VsbCBt YXliZSBmb3IgVEVBUyBuZXR3b3JrIHNsaWNpbmcgd2l0aCA1RyB2aXJ0dWFsaXphdGlvbiB0aGUg dW5kZXJsYXkgbmV0d29yayBzbGljZSBhbmQgbm93IGluY29ycG9yYXRpbmcgU0ZDIE5TSCBzZXJ2 aWNlIHBsYW5lIGludG8gNUcgVUUgc2VydmljZXMgbmV0d29yayBzbGljaW5nIE5TQyBzbGljZSBj b250cm9sbGVyLiZuYnNwOyBUaGVyZSAmbmJzcDttYXliZSBhcyB3ZWxsIGZvciBPVE4gTDFWUE4g YW5kIENDQU1QIFdHcyBtYXliZSBhIHBvc3NpYmlsaXR5DQogb2YgV0cgY2hhcnRlciBleHBhbnNp b24gaW50byB0aGF0IGFyZW5hIFNGQyBOU0ggcG9zc2libGUgY29uc2lkZXJhdGlvbnMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlNwcmluZyBXRyBT ZWdtZW50IFJvdXRpbmcgaW4gbXkgbWluZCBhcyBpdOKAmXMgYWxsb3dzIHRoZSBhYmlsaXR5IGZv ciB2aXJ0dWFsaXphdGlvbiBhbmQgYWJzdHJhY3Rpb24gb2YgdGhlIHVuZGVybGF5IHdpdGggU1It VEUgbWljcm8gZmxvdyBhbmQgbWFjcm8gZmxvdyBwYXRoIHN0ZWVyaW5nIGFuZCBpdCBsZW5kcyBp dHNlbGYgdG8gJm5ic3A7YmUgYSBjcml0aWNhbCBjb21wb25lbnQNCiBvZiBURUFTIG5ldHdvcmsg c2xpY2luZywgSSBiZWxpZXZlIHRoYXQgU0ZDIE5TSCBzZXJ2aWNlIHBsYW5lIGNhbiByZWFsbHkg dGFrZSBvZmYgaW4gdGhhdCBhcmVhIHdpdGggYSBteXJpYWQgb2YgdXNlIGNhc2VzIGFjcm9zcyB0 aGUgYm9hcmQuJm5ic3A7IEkgYmVsaWV2ZSB3aXRoIHRoZSBhZHZlbnQgb2YgU1IgcmVhbGx5IGJy aW5ncyB0byBsaWdodCB0aGUgY3JpdGljYWxpdHkgb2YgU0ZDIE5TSCBzZXJ2aWNlIHBsYW5lLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgd291bGQgYmUgaGFwcHkgdG8gd29yayBvbiBhbGwgZXhp c3RpbmcgZG9jdW1lbnRzIGJlaW5nIHByb2dyZXNzZWQgdGhhdCBJIGFtIGludm9sdmVkIGFzIHdl bGwgYXMgd29ya2luZyBvbiBhbnkgSSBhbSBub3QgaW52b2x2ZWQsIGFzIHdlbGwgYXMgd2l0aCB0 aGUgcmVjaGFyZ2VyIGV4cGFuc2lvbiwgYW55IGZ1dHVyZSBkZXZlbG9wbWVudCBuZXcgd29yay48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+S2luZCBS ZWdhcmRzJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPkd5YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5PbiBGcmksIEphbiAyOCwgMjAyMiBhdCAyOjA1IFBNIEpvZWwgTS4gSGFscGVybiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlNGQyBXb3JraW5nIEdy b3VwOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7QXMgcGFydCBvZiBkaXNjdXNzaW5n IHRoZSBPQU0gZWxhdGVkIGRyYWZ0cyBpbiBTRkMsIHRoZSBjaGFpcnMgaGF2ZSA8YnI+DQpiZWVu IGxvb2tpbmcgYXQgdGhlIG92ZXJhbGwgd29ya2luZyBncm91cCBwYXJ0aWNpcGF0aW9uLiZuYnNw OyBXZSBub3RlIHRoYXQgPGJyPg0KdmVyeSBmZXcgcGVvcGxlIGhhdmUgc3Bva2VuIHVwIGFib3V0 IHRoZSBpc3N1ZXMgYmVpbmcgZGlzY3Vzc2VkLiZuYnNwOyBGb3IgPGJyPg0KbW9zdCByZWNlbnQg ZHJhZnRzIHdlIGhhdmUgYmVlbiB3b3JraW5nIHRvIGFkdmFuY2UsIGl0IGhhcyBiZWVuIGEgbG90 IG9mIDxicj4NCndvcmsgdG8gZ2V0IGVub3VnaCBjb21tZW50cyB0byBqdXN0aWZ5IGFkdmFuY2Vt ZW50IChhbmQgZm9sa3MgY291bGQgPGJyPg0KYXJndWUgdGhhdCB3ZSBkaWQgbm90IHN1Y2NlZWQu KTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7V2UgYXJlIGNvbnNpZGVyaW5nIHZhcmlv dXMgYWx0ZXJuYXRpdmVzLiZuYnNwOyBXZSBjb3VsZCwgZm9yIGV4YW1wbGUsIDxicj4NCmp1c3Qg Y2xvc2UgdGhlIHdvcmtpbmcgZ3JvdXAuPGJyPg0KT25lIHBvc3NpYmlsaXR5IGlzIHRvIHJlY2hh cnRlciB0aGUgd29ya2luZyBncm91cCB0byBleHBhbmQgdGhlIHNjb3BlLiA8YnI+DQpUaGVyZSBh cmUgdHdvIHJlbGF0ZWQgcXVlc3Rpb25zIHRoYXQgd2Ugd291bGQgbGlrZSB0byBoZWFyIGZyb20g dGhlIDxicj4NCndvcmtpbmcgZ3JvdXAgYWJvdXQgdGhpcy48YnI+DQo8YnI+DQoxKSBJZiB3ZSB3 ZXJlIHRvIGNvbnNpZGVyIGV4cGFuZGluZyB0aGUgY2hhcnRlciwgd2hhdCB0aGluZ3Mgd291bGQg eW91IDxicj4NCmxpa2UgdG8gc2VlIGluY2x1ZGVkIGluIGl0Pzxicj4NCjxicj4NCjIpIElmIHdl IGRvIHJlY2hhcnRlciB3aWxsIHlvdSB3b3JrIG9uIHRoZSBleGlzdGluZyBkb2N1bWVudHMsIGFu ZCB3aWxsIDxicj4NCnlvdSBlbmdhZ2Ugb24gZG9jdW1lbnRzIG90aGVyIHRoYW4gdGhlIG9uZSBv ciB0d28geW91IHBlcnNvbmFsbHkgd291bGQgPGJyPg0KbGlrZSB0byBzZWUgaW5jbHVkZWQ/PGJy Pg0KPGJyPg0KVGhhbmsgeW91LDxicj4NCkpvZWwgYW5kIEppbTxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5z ZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyIj48YSBocmVmPSJodHRwOi8vd3d3LnZlcml6b24u Y29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyO3RleHQtZGVj b3JhdGlvbjpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6IzExNTVDQztib3JkZXI6c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSI4MSIgaGVp Z2h0PSIxOCIgc3R5bGU9IndpZHRoOi44NDM3aW47aGVpZ2h0Oi4xODc1aW4iIGlkPSJfeDAwMDBf aTEwMjUiIHNyYz0iY2lkOn5XUkQwMDA1LmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRl ci4iPjwvc3Bhbj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTowY207 bWFyZ2luLWxlZnQ6MzYuMHB0O21zby1saW5lLWhlaWdodC1hbHQ6OS43NXB0Ij4NCjxiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5HeWFuIE1pc2hyYTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6MzYuMHB0O21zby1saW5lLWhlaWdodC1hbHQ6OS43 NXB0Ij4NCjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNl cmlmO2NvbG9yOmJsYWNrIj5OZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRlY3QmbmJzcDs8L3NwYW4+ PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206MGNtO21hcmdpbi1sZWZ0OjM2LjBwdDttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+ DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtHZW9y Z2lhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5FbWFpbCA8YSBocmVmPSJtYWlsdG86Z3lhbi5z Lm1pc2hyYUB2ZXJpem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KZ3lhbi5zLm1pc2hyYUB2ZXJp em9uLmNvbTwvYT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4t cmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2LjBwdDttc28tbGlu ZS1oZWlnaHQtYWx0OjkuNzVwdCI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+TSAzMDEgNTAyLTEzNDc8L3NwYW4+PC9p PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxocj4N Cjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+PGJyPg0KRXN0ZSBtZW5z YWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5h dGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRl bmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUg ZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEg bm90aWZpY2FkbyBkZSBxdWUgbGENCiBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOz biB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZp cnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5z YWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFt ZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi48YnI+ DQo8YnI+DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlz IGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhl IHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlv dSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sDQogZGlzdHJpYnV0 aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBu b3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVs ZXRlIGl0Ljxicj4NCjxicj4NCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2Vt IGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1h w6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2 byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5o b3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYQ0K IGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRv cml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28g dmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBx dWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJv Y2VkYSBhIHN1YSBkZXN0cnVpw6fDo288YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5AB114DA006448B88C92F1F71535B7D3telefonicacom_-- From nobody Wed Feb 16 06:19:57 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795933A09E3 for ; Wed, 16 Feb 2022 06:19:16 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham 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 igr4V-FaOWFS for ; Wed, 16 Feb 2022 06:19:11 -0800 (PST) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 954A73A0A01 for ; Wed, 16 Feb 2022 06:19:10 -0800 (PST) Received: by mail-ej1-x62e.google.com with SMTP id d10so4909455eje.10 for ; Wed, 16 Feb 2022 06:19:10 -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=0fna/yo+QzoKqWRSn+HsppKTOrAup7uGPitznv4Wq9Q=; b=l6IixMYo7d7mpw7Qi+mub78sCAgGNgdNt7ek6rz6eCWkNmEU8//6/knckRrmMx9MNW /rlqN5OWHdqJr3QtKaxMiHwUsyaTTvsv1WlSmH1M1Rz55usV0SztUSqJh1WkEm7kNMz8 NU2r6Jh8JeeU3lNU7KDN5CrJkmF109IaBZ0LyfRWiHxEVeR2+i9qgsErRtkQOZf/fdJ0 PArQ3D5qesrlrqrK2Jm9fGYHRPBTalEFsGLPuk9tTVdEykr8cjpSYDaHj+NEde+TPgq+ UdVdtnrMQA0Tbh2eIHvwUehKp7mWGTRwMJ2aq416v4pdWuPmmj7UEDehmPgzUbZfynmp VwDA== 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=0fna/yo+QzoKqWRSn+HsppKTOrAup7uGPitznv4Wq9Q=; b=w228NqWBMrBJZ72o+EJu8l6I2grix7zY2c0yMih3oHw3A2JNnxlNKHV3o39acQ5KUP Rc91KppqLZj1My+/rNwQFPx6AutNwF4TpD38Waru8FkaUvhjuwqNfBBiqAP4SueZqMLR ujbCAYwFCKqgMgV07ghPvWQkHu28wnfBRx+BZom+JDHPA2i2xF2a3U/OqQcjqtBG0u6s JIfIy2GWHqGr47xjh2Saf3CG74mIAqLLY2pI/dG86b4DFSFMBrmNogWYth2N5LuOQM6H Ud7gWh3E3zzU7kCIdLDzBCm4r5BncakL0K4eV3lJFq55azQ5I8N9XDokraOnv74MHDq/ ShzQ== X-Gm-Message-State: AOAM531cT+JwyG3aAjWWnbXIwmpjooq3b2MFbrKx1QThYs8M3zOXRPMz ma6HTnY+oNiBJG30pRT4H9AFlR3NaZjmnPBf0qkWnQISlcs= X-Google-Smtp-Source: ABdhPJw7l0H7aLZb6tRIjOc/OB9Ttqy5ljwXsIuzrZWRUUBFQaIugDc09bSnixqK+EQDeZ949gQlSsedUtkDIskK+7M= X-Received: by 2002:a17:907:766e:b0:6cf:d1d1:db1d with SMTP id kk14-20020a170907766e00b006cfd1d1db1dmr2466940ejc.503.1645021144913; Wed, 16 Feb 2022 06:19:04 -0800 (PST) MIME-Version: 1.0 References: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> <5AB114DA-0064-48B8-8C92-F1F71535B7D3@telefonica.com> In-Reply-To: <5AB114DA-0064-48B8-8C92-F1F71535B7D3@telefonica.com> From: CARLOS JESUS BERNARDOS CANO Date: Wed, 16 Feb 2022 15:18:48 +0100 Message-ID: To: "Diego R. Lopez" Cc: Gyan Mishra , "Joel M. Halpern" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fdbae105d82354a1" Archived-At: Subject: Re: [sfc] Future of SFC work X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 14:19:17 -0000 --000000000000fdbae105d82354a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I also support extending the scope of the charter and continuing the work. I'm interested in looking at how to extend SFC also to the end-terminal devices, how to integrate SFC with RAW/DETNET and potential implications of mobility on the control plane, just as examples. Thanks! Carlos On Wed, Feb 16, 2022 at 3:14 PM Diego R. Lopez wrote: > Hi, > > > > The advantage of waiting a while before expressing my opinion is the Gyan > has perfectly done so (thanks!). I fully support his opinion about > continuing SFC work. And I must say I have the intention to continue bein= g > directly involved in some work of the group, as I was in the composition > draft or in the PoT activities. > > > > Be goode, > > > > -- > > "Esta vez no fallaremos, Doctor Infierno" > > > > Dr Diego R. Lopez > > Telefonica I+D > > https://www.linkedin.com/in/dr2lopez/ > > > > e-mail: diego.r.lopez@telefonica.com > > Mobile: +34 682 051 091 > > ---------------------------------- > > > > On 16/02/2022, 04:09, "sfc on behalf of Gyan Mishra" on behalf of hayabusagsm@gmail.com> wrote: > > > > > > Hi Joel, Jim & all > > > > I would say that one measure of success of a WG is that when you do a > google search, there are many scholarly articles related to SFC service > plane benefits as well as vendor implementations that I know of personall= y > with Cisco and Juniper and there maybe other vendors out there. > > > > I think the SFC WG has garnered overall interest in the technology > industry wide and it=E2=80=99s importance of a service plane. > > > > Overall I would say hats off to the chairs and WG members and all the har= d > work as to the success!!! > > > > As far as commentary and involvement in drafts, that issue exists across > the board as I am a member of every Routing Area WG, 54 WGs in total I > would say the interest and involvement has been as well with other WGs > related to personal drafts being progressed by individuals so I don=E2=80= =99t think > it=E2=80=99s just an issue with SFC WG. My observation has been that whe= never > multiple vendors have competing solutions they want to get to WG adoptio= n > and progression, those are the hot ones that have tremendous interest. > As well there are hot topics and the hot topics with drafts that have all > the major vendors involvement get the most feedback and of course progres= s > quickly. The key is garnering multi vendor interest and support to > progress an idea which goes for SFC and any WG. > > > > In my mind NFV brought about the concept of the need for service chaining > of VNF instances and now SFC has broadened the use case with NSH service > plane beyond NFV with physical hardware endpoints and any virtualization > model. > > > > I am in favor of expanding the scope of the WG to include in the charter > any networking area that involves virtualization such as DC NVO > encapsulation overlays such as VXLAN where I see Cisco and Juniper are > providing their own on standardized methods service chaining that is SFC > and SFC NSH independent where I think their can be tremendous benefits as > well as when extending the fabric to the host being able to use SFC NSH > service plane to link the SFF instances. I think as well maybe for TEAS > network slicing with 5G virtualization the underlay network slice and now > incorporating SFC NSH service plane into 5G UE services network slicing N= SC > slice controller. There maybe as well for OTN L1VPN and CCAMP WGs maybe= a > possibility of WG charter expansion into that arena SFC NSH possible > considerations. > > > > Spring WG Segment Routing in my mind as it=E2=80=99s allows the ability f= or > virtualization and abstraction of the underlay with SR-TE micro flow and > macro flow path steering and it lends itself to be a critical component = of > TEAS network slicing, I believe that SFC NSH service plane can really tak= e > off in that area with a myriad of use cases across the board. I believe > with the advent of SR really brings to light the criticality of SFC NSH > service plane. > > > > > > I would be happy to work on all existing documents being progressed that = I > am involved as well as working on any I am not involved, as well as with > the recharger expansion, any future development new work. > > > > Kind Regards > > > > Gyan > > > > On Fri, Jan 28, 2022 at 2:05 PM Joel M. Halpern > wrote: > > SFC Working Group: > > As part of discussing the OAM elated drafts in SFC, the chairs have > been looking at the overall working group participation. We note that > very few people have spoken up about the issues being discussed. For > most recent drafts we have been working to advance, it has been a lot of > work to get enough comments to justify advancement (and folks could > argue that we did not succeed.) > > We are considering various alternatives. We could, for example, > just close the working group. > One possibility is to recharter the working group to expand the scope. > There are two related questions that we would like to hear from the > working group about this. > > 1) If we were to consider expanding the charter, what things would you > like to see included in it? > > 2) If we do recharter will you work on the existing documents, and will > you engage on documents other than the one or two you personally would > like to see included? > > Thank you, > Joel and Jim > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > -- > > [image: Image removed by sender.] > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > > ------------------------------ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener informaci=C3=B3n privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilizaci=C3= =B3n, > divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en= virtud de > la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le ro= gamos > que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a s= u > destrucci=C3=B3n. > > The information contained in this transmission is confidential and > privileged information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution o= r > copying of this communication is strictly prohibited. If you have receive= d > this transmission in error, do not read it. Please immediately reply to t= he > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3= =A1rio, > pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 pa= ra uso exclusivo > da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa senhoria o des= tinat=C3=A1rio > indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga= =C3=A7=C3=A3o e/ou > c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da le= gisla=C3=A7=C3=A3o vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --000000000000fdbae105d82354a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I also support extending the scope = of the charter and continuing the work. I'm interested in looking at ho= w to extend SFC also to the end-terminal devices, how to integrate SFC with= RAW/DETNET and potential implications of mobility on the control plane, ju= st as examples.

Thanks!

C= arlos

On Wed, Feb 16, 2022 at 3:14 PM Diego R. Lopez <diego.r.lopez@telefonica.com> wro= te:

Hi,

= =C2=A0

The ad= vantage of waiting a while before expressing my opinion is the Gyan has per= fectly done so (thanks!). I fully support his opinion about continuing SFC = work. And I must say I have the intention to continue being directly involved in som= e work of the group, as I was in the composition draft or in the PoT activi= ties.

=C2=A0

Be goo= de,

=C2=A0

--=

"Est= a vez no fallaremos, Doctor Infierno"

=C2=A0=

Dr Diego = R. Lopez

Telefonic= a I+D

https://www.linkedin.com/in/dr2lopez/=C2= =A0

=C2=A0=

e-mail:= =C2=A0diego.r.lopez@telefonica.com

Mobile= : =C2=A0+34 682 051 091

---------------------= -------------

=C2=A0<= /span>

On 16/02/2022, 04:09, &qu= ot;sfc on behalf of Gyan Mishra" <sfc-bounces@ietf.org on behalf of hayabusagsm@gmai= l.com> wrote:

=C2=A0

=C2=A0

Hi Joel, Jim & all=

=C2=A0

I would say that one meas= ure of success of a WG is that when you do a google search, there are many = scholarly articles related to SFC service plane benefits as well as vendor = implementations that I know of personally with Cisco and Juniper and there maybe other vendors out there. =C2=A0<= /u>

=C2=A0

I think the SFC WG has ga= rnered overall interest in the technology industry wide and it=E2=80=99s im= portance of a service plane. =C2=A0

=C2=A0

Overall I would say hats = off to the chairs and WG members and all the hard work =C2=A0as to the succ= ess!!!

=C2=A0

As far as commentary and = involvement in drafts, that issue exists across the board as I am a member = of every Routing Area WG, 54 WGs in total I would say the interest and invo= lvement has been as well with other WGs related to personal drafts being progressed by individuals so I don=E2= =80=99t think it=E2=80=99s just an issue with SFC WG.=C2=A0 My observation = has been that whenever multiple =C2=A0vendors have competing solutions they= want to get to WG adoption and progression, =C2=A0those are the hot ones that have tremendous interest. =C2=A0 As well there are hot topic= s and the hot topics with drafts that have all the major vendors involvemen= t get the most feedback and of course progress quickly.=C2=A0 The key is ga= rnering multi vendor interest and support to progress an idea which goes for SFC and any WG.

=C2=A0

In my mind NFV brought ab= out the concept of the need for service chaining of VNF instances and now S= FC has broadened the use case with NSH service plane beyond NFV with physic= al hardware endpoints and any virtualization model.

=C2=A0

I am in favor of expandin= g the scope of the WG to include in the charter any networking area that in= volves virtualization such as DC NVO encapsulation overlays such as VXLAN w= here I see Cisco and Juniper are providing their own on standardized methods service chaining that is SFC and SFC NSH= independent where I think their can be tremendous benefits as well as when= extending the fabric to the host being able to use SFC NSH service plane t= o link the SFF instances. =C2=A0 I think as well maybe for TEAS network slicing with 5G virtualization the underlay= network slice and now incorporating SFC NSH service plane into 5G UE servi= ces network slicing NSC slice controller.=C2=A0 There =C2=A0maybe as well f= or OTN L1VPN and CCAMP WGs maybe a possibility of WG charter expansion into that arena SFC NSH possible considerations.

=C2=A0

Spring WG Segment Routing= in my mind as it=E2=80=99s allows the ability for virtualization and abstr= action of the underlay with SR-TE micro flow and macro flow path steering a= nd it lends itself to =C2=A0be a critical component of TEAS network slicing, I believe that SFC NSH service plane can really t= ake off in that area with a myriad of use cases across the board.=C2=A0 I b= elieve with the advent of SR really brings to light the criticality of SFC = NSH service plane.

=C2=A0

=C2=A0

I would be happy to work = on all existing documents being progressed that I am involved as well as wo= rking on any I am not involved, as well as with the recharger expansion, an= y future development new work.

=C2=A0

Kind Regards=C2=A0=

=C2=A0

Gyan

=C2=A0

On Fri, Jan 28, 2022 at 2= :05 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

SFC Working Group:

=C2=A0 =C2=A0 =C2=A0As part of discussing the OAM elated drafts in SFC, the= chairs have
been looking at the overall working group participation.=C2=A0 We note that=
very few people have spoken up about the issues being discussed.=C2=A0 For =
most recent drafts we have been working to advance, it has been a lot of work to get enough comments to justify advancement (and folks could
argue that we did not succeed.)

=C2=A0 =C2=A0 =C2=A0We are considering various alternatives.=C2=A0 We could= , for example,
just close the working group.
One possibility is to recharter the working group to expand the scope.
There are two related questions that we would like to hear from the
working group about this.

1) If we were to consider expanding the charter, what things would you
like to see included in it?

2) If we do recharter will you work on the existing documents, and will you engage on documents other than the one or two you personally would
like to see included?

Thank you,
Joel and Jim

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

--

3D"Image

Gyan Mishra<= /u>

Network Solutions = Architect=C2=A0

Ema= il gyan.s.mishra@verizon.com

M 301 502-1347

=C2=A0



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is confidential and privileg= ed information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--000000000000fdbae105d82354a1-- From nobody Wed Feb 16 06:40:20 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82DC3A0B42 for ; Wed, 16 Feb 2022 06:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL=1.31, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 VWTHOWdQBZOQ for ; Wed, 16 Feb 2022 06:40:14 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 7591F3A0ADF for ; Wed, 16 Feb 2022 06:40:14 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) (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 opfedar25.francetelecom.fr (ESMTP service) with ESMTPS id 4JzLGN420Rz8t5f for ; Wed, 16 Feb 2022 15:40:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645022412; bh=5qPntSQ8D9Hlbz8dHnLdgM5YEkATO0+lH94OTn2Sg7M=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=JliNTzElGxkeUXZ5dQaKhaIzJ3suWE2hqrixQnHKg1Qwf5vb7QgvHxV010q6p0AMq ahJovTEn884h9PCMgwYtXU2GUwRFBnHshFhyiELqJb/p1tsnPqTtN+IS7Pogj20M6H OqYORgHffME6fHX0uaR7807qi3jUt4RhHbEmTOelWM6cFewbGNYJbWoweya29azewO xWvpkm8UwlTe090WZaA27BTd9Ehs2A7CuLgpHd4fy4vKE+EkVYJ4zgS9MYboIbVN+S xkdCgEoX4VeqfMo6KGdwRcIovJPGZTbB4OMeSPiDq0z8LQ6hLMfKLKtVVAZozcsGjh +9sGvS8xJG+ig== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar01.francetelecom.fr (ESMTP service) with ESMTPS id 4JzLGN3HdQzBrLP for ; Wed, 16 Feb 2022 15:40:12 +0100 (CET) From: To: "sfc@ietf.org" Thread-Topic: I-D Action: draft-boucadair-sfc-oam-packet-00.txt Thread-Index: AQHYI0LOqTeC5k5EYkSp4mi5aRUmyqyWP10g Content-Class: Date: Wed, 16 Feb 2022 14:40:11 +0000 Message-ID: <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> In-Reply-To: <164502226599.23621.11371897310173936133@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_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-16T14:39:15Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=880ee5c3-e153-4213-a5db-f9442afc57d7; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 14:40:19 -0000 Hi all,=20 A proposal to clarify the intent of SFC OAM packet. Comments are welcome. Cheers, Med -----Message d'origine----- De=A0: I-D-Announce De la part de internet-= drafts@ietf.org Envoy=E9=A0: mercredi 16 f=E9vrier 2022 15:38 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-sfc-oam-packet-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Clarifying Ambiguity related to Network Service H= eader (NSH) OAM Packet Author : Mohamed Boucadair Filename : draft-boucadair-sfc-oam-packet-00.txt Pages : 5 Date : 2022-02-16 Abstract: This document clarifies an ambiguity in the Network Service Header (NSH) specification related to the handling of O-bit. In particular, this document clarifies the meaning of "OAM packet". This document updates RFC8300. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam-packet/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-packet-00 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 ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Feb 16 06:47:28 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5576D3A1357 for ; Wed, 16 Feb 2022 06:47:26 -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, 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 JFD3KJCsPU6y for ; Wed, 16 Feb 2022 06:47:21 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe59::718]) (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 8107F3A1352 for ; Wed, 16 Feb 2022 06:47:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RYP7fZQ49nmtOKlD74MWmttjGdn25tPz4q5SRvTtuk95UP4+//BdZIIfGBVLYes5kg7BytfxU3deWWg5sn/AFQlwaQtNfDx8+x+jvpa8lQ0i0IItGwRbBrfqeVptwb6JjoPB/Cg2TGmRjc65m7/+06H68Ei20KBtMpfngX4jn0bmyYpIo3OO2oqcwEbZ78/1sLTKjWuOt//kZcUbmd6lOmqm5CojFRWX+mrhQD5bzYo9qRtCH/01jgqULKe3a7Cs3T4yWkY4X6hXTPp2XOT6RTi0jWq8hjbuv85yv0TYBMj8d6nqrC4mdJZ3LsIObEsOIBKvv7WdVcdoN42tLfxqSQ== 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=IJBbiicxXXGwsCsK3o3mTswYFSFKr9xsPMljBgnzHKs=; b=VUCGEKc+4W6cojoqwqmvES1MGT1XfwbjoHgA5QqPjfMcMC5j9uG0EdKG+UBZ5MB/c4oQA58EANdvebc7+z3gHkXQNB1VbQiR1N7P1PjbjmPuWc1kJScxvFggplK0a6aAjYB8M914s22JY3taVQN8LWo6AH0hz+nOs+j6fKA9a5VSfnYy8bnwAeZk5o/1wdGMYUr8xmrAGvYEmCKxeATgT2cGBkmRS05c5vpZZbygOUJ8qc+/Tx9lRACO/AH0M7t7Hf75NRyqEeoUmu3ErNs34eJaXQsqAAZEFi4+Yx3d9zLHLEtZcMqvcxIuWZe3X3q0a0/MzBPOrpubF9LaYdSUQg== 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=IJBbiicxXXGwsCsK3o3mTswYFSFKr9xsPMljBgnzHKs=; b=MlLyxSOtmPiQZVEEjQ8vC20iVoR+3fR5L30Vz3QfEqi+Wmqd5SFGqnaILsDQOluHrKYTBJuIfXzVuOPUky1M24g8/KVvEM9LCK6n3/Tz0VBhA+1wrI8xtTK1rqEoOz3Kq76iezf6HwReXsQYXIDL+jkdb6EptLkDwCkWMKDri4A= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by MN2PR13MB3871.namprd13.prod.outlook.com (2603:10b6:208:1ea::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.6; Wed, 16 Feb 2022 14:47:13 +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 14:47:13 +0000 From: James Guichard To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: I-D Action: draft-boucadair-sfc-oam-packet-00.txt Thread-Index: AQHYI0LSswu8MOJJHEygtT8ueJ10O6yWP62A///+fqA= Date: Wed, 16 Feb 2022 14:47:13 +0000 Message-ID: References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-16T14:39:15Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=880ee5c3-e153-4213-a5db-f9442afc57d7; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 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: a3b4ae1a-edde-4abb-3a09-08d9f15b37e8 x-ms-traffictypediagnostic: MN2PR13MB3871: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: vkvRi7Zsz1ZugsxPPlZYAzdxnFxoTqGr50e+3NByhalt9miURC2CvhIwUqcZ/mMD2NIuPLWw/a3yZfuO5YHRee7ZGxGhBasQxt2a9DGe8BGZ1CopZVQ6lkgIgpxrr6w/vdFJMEGtV4GXBHg0vfwffecJA0913LepQrHLLOw1Jqjzh8q1iBZtJ2G6SWsqMigW4pdBgz/ng/rGWQmVc8CCyS175wSXQqbAmscBqfrYhWpU0yG2Z6rJge2yTlvLmWNKYuAcIxAjBGQjfrebgZAYv+xbBus6gWjHVEn6htBveN7LyzqCJq5PcgoYjqthHWvR8raKrR5gqKplQectrz7rdeAKVIsqxbBRQAcKZ9SCr42aPhzssg4nbOdD/FzLhG4U12AmYjj5XtEGcs4f83xENpjzibIijM6BNacmgYkPQeozS5wFaQ+SOoClk6m+YZRN+I0OotiP4TPobNNHZ1jxQOU5jzEipLKKO7NNbWAA+Ck3Nq2tPdt/L+o2nGM8e7GgI/VXizxJ4gMyJWAeZg+3QhctYV8MPPEBCTn7UW8mdgZfjBXUk499yO8mHfIqN+wQFaRumOn+fcQSTFbvZFZjljJJC6BvowceufLYBRb9hXfA6PxWmRjgsYzGBw6X9f1sFSue5mGgBuBWa8nH3A1cl26VvTylqXAIknq3pZecJwebnZHv7f8isjEbA8vnux2vmZ2fpiCuDutZiZoCSjv8RiD26YCG3Vn8gw/yCaeapIzAJNAOSCVdf5+ZoA5pMie6NdxeAAXza8vpzyDBN9LdpDT76yvk4S+u52nEpGQqwBCLUYzMoyX0W9onGTsRg10zb7dR5QnNHC34xP34O/SDCg== 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)(76116006)(38100700002)(186003)(6506007)(7696005)(52536014)(38070700005)(110136005)(66476007)(66556008)(64756008)(66446008)(66946007)(122000001)(71200400001)(316002)(86362001)(53546011)(9686003)(83380400001)(966005)(508600001)(8676002)(45080400002)(2906002)(33656002)(55016003)(5660300002)(66574015)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?vD6D06xkg/3mMdvDxNd4EFESn+Q5/Mu/XB8Q5mRFOK25nc43rpw5KyyEoo?= =?iso-8859-1?Q?1TeN3edNWSjyGjTPebx1NeP9wAFsUtXVhehHwYxros8GoQZGPCSIVPQDqn?= =?iso-8859-1?Q?+EK2nFLp25AKmWt4YQM98L5FGPRLIMU4BNCthbPgnbBmw4GqGeA/CTMJjW?= =?iso-8859-1?Q?T9STs42BKc1YCFEALfFP+9+FGbhemFnrqL5eit9AUROaZpAndZDC3Y3qZc?= =?iso-8859-1?Q?A/SPvlTPlevF8g4lj2/IPOLuMo4buoLhpPYEti+pI2lpYaLO3stls354ST?= =?iso-8859-1?Q?Q6dh/E8uw1qCEXCaKXpA/0sIbg91qf/7mjgCLAuwmEzKxeZJGGcIzO+z/v?= =?iso-8859-1?Q?NxmlJiCDoF54WBY8461ATmTBID7FbOUf2RE4azh2ubB76YJV3hypGj5PlM?= =?iso-8859-1?Q?Hc8+ophwEl8crzenBy+UMx/t4Cx9u438z6IiVb5bSWFa3z3pLEoRRK3lwh?= =?iso-8859-1?Q?YZz81u41vGKdeNAVT6EM4owxyr0fkQPUeabhXH8WZYD+fo4ydoCnwbSAnS?= =?iso-8859-1?Q?DcmOpdqcb4YRt8USFtcUUFbVTYrRwMfCHMCgHVBAboiPebDwn7FjlozNr1?= =?iso-8859-1?Q?ffE7hSW6w9+113y5zCwa0BgKYO27P3RTTeppru/gGbOfIOdePlYm8RCDmz?= =?iso-8859-1?Q?N6KNd606WP2CK6e4Sk+of4nxLnvYvGcGs2qSAY3mwcYcU28QxWybwIpkVx?= =?iso-8859-1?Q?O8DYUHOL4DmoX76kGFykbhuwCYIxETFQkaHuHZdjJdLahsUvsOtrIia+Fg?= =?iso-8859-1?Q?vbQUFRQR+ZzVvmTd0hmbKNtW+12QrM0FfQjt9AQvZhDXrcufEd0niFBk79?= =?iso-8859-1?Q?9qoe+wuRQV8DqJIwSrWCZ+pPfY1VKu2gt0PbB/neFygHUmIndrNZEYVv02?= =?iso-8859-1?Q?vLN8fkh125bIiTOmZVmnFDlDGgbMt7fXq7qvRn41ZsVyos3Bcb9cH5h9JU?= =?iso-8859-1?Q?Z2ailJQBQMWOz11XXIiSkXymbYauW+LDqZ3QUAxf2VvpyKO0affmMH0yxv?= =?iso-8859-1?Q?0m+K75ERRK8PviCFQhtJgWtghmyeLgiPuH0w2JtPh8ukI/iinLtkLiTDtX?= =?iso-8859-1?Q?bSon1Ur4toyTIy2EDf4ZZqjmvlUWEy4l1kugZX/6CdfYFkBIIvOjeIJWC7?= =?iso-8859-1?Q?2c6sVXF75/vayTHqlPIR3wuMB+otG3dLxdmjxYaIENF5vtNDwZAYJY3u9G?= =?iso-8859-1?Q?hFtxvG4wYDfIVEQ1xv6bQBLbqeObzcoaGXx44lP2iI/Wwkq6BX5BHob935?= =?iso-8859-1?Q?KTVorlQoWSr6DcMLvXnZHcRqWNJAMbbVNjXTxMK9gxinN/mr0SwydeCVnn?= =?iso-8859-1?Q?ONv/KQyTC+PDgnQ9QrKJoKEh2XKwXPEjosMMG0tA+YnF3tMG+Vwt+IGaNu?= =?iso-8859-1?Q?nY9NtaSWodNPyao1PvGJye8W0YTRjpW1vuVBGn/YIS+v1hWJBnmpVzNFND?= =?iso-8859-1?Q?8ybIHsdFuwoexgdzzVhML72KL49NMGBOfLS9scWju21hnu7i5dK+no5Kpl?= =?iso-8859-1?Q?b57p8PU2vXDareGOXaK9xJfkmQLwQ3ZSl56UIlKX1Mp5KJcQmRY6XLornF?= =?iso-8859-1?Q?2V1ZWaLOFJejKRXq1wmelkMUAixZ4pZdLM+RO0zN3B91jAAk70esEaudR+?= =?iso-8859-1?Q?OQHf0ODJ4uR5xsje8j6Xc5o/f6Y4Er7BdVYZRrjzZU6gSA+x/IE4nAsgnh?= =?iso-8859-1?Q?/vNUJ+tlzq/oIgnjWF9sAaAVknsLnyMhFfmGjlvZexU2MDdE6oVPCL+bIM?= =?iso-8859-1?Q?jtKf1Fz2LkD7y9Vryr3xS5vBw=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: a3b4ae1a-edde-4abb-3a09-08d9f15b37e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2022 14:47:13.0357 (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: qkJbvIX+rMHu7HuPaW4x9iAor9enE9tP0GVspk07Lm97cl6MQ4LG+MKJUyQtHDp4dhel4irvMO9DboqIgIJctg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3871 Archived-At: Subject: Re: [sfc] I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 14:47:26 -0000 Hi Med, Thank you for doing this! I think the following questions are relevant and should be clarified as par= t of the draft text: (1) Should the O-bit be set ONLY for OAM packets that are specific to the S= FC service layer? (2) Should the O-bit be set in the cases where a solution uses the next pro= tocol field in the NSH header? In this case what is the purpose of the O-bi= t given that the next protocol field already indicates the expected behavio= r? (3) If the O-bit is set is it the expected behavior to find relevant SFC se= rvice layer OAM information ONLY in the context headers? (4) If the answer to (3) is no then what is the sequence of behavior to fin= d the OAM information? (1) look in context headers and then next protocol?,= (2) look at next protocol and if not an OAM protocol look in context heade= rs?, (3) some other sequence? Jim -----Original Message----- From: sfc On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 16, 2022 9:40 AM To: sfc@ietf.org Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt Hi all,=20 A proposal to clarify the intent of SFC OAM packet. Comments are welcome. Cheers, Med -----Message d'origine----- De=A0: I-D-Announce De la part de internet-= drafts@ietf.org Envoy=E9=A0: mercredi 16 f=E9vrier 2022 15:38 =C0=A0: i-d-a= nnounce@ietf.org Objet=A0: I-D Action: draft-boucadair-sfc-oam-packet-00.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Clarifying Ambiguity related to Network Service H= eader (NSH) OAM Packet Author : Mohamed Boucadair Filename : draft-boucadair-sfc-oam-packet-00.txt Pages : 5 Date : 2022-02-16 Abstract: This document clarifies an ambiguity in the Network Service Header (NSH) specification related to the handling of O-bit. In particular, this document clarifies the meaning of "OAM packet". This document updates RFC8300. 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-boucadair-sfc-oam-packet%2F&data=3D04%7C01%= 7Cjames.n.guichard%40futurewei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fe= e8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%= 7C3000&sdata=3DInMITh%2FD%2FNkAnNh0rvL5EeeshzdTbrxXeGKwOCVNyAA%3D&r= eserved=3D0 There is also an htmlized version available at: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Fdraft-boucadair-sfc-oam-packet-00&data=3D0= 4%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413e4d7f0ded08d9f15a462= e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806192321886192%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C3000&sdata=3DXzLwiIMGzlBD0rM6Q%2Bf4v68iFYlcee3Kegm08FVcUmw%3D&= amp;reserved=3D0 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://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fi-d-announce&data=3D04%7C01%7Cjames.n.guic= hard%40futurewei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189= c753a1d5591fedc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIj= oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sda= ta=3DW3MJq4OJvBesWQg5t6FS%2FJQH7BSK7GQqAQzQV5rT2gY%3D&reserved=3D0 Internet-Draft directories: https://nam11.safelinks.protection.outlook.com/= ?url=3Dhttp%3A%2F%2Fwww.ietf.org%2Fshadow.html&data=3D04%7C01%7Cjames.n= .guichard%40futurewei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b2= 40189c753a1d5591fedc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8e= yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am= p;sdata=3D8fnzdUA6tJApFT%2FhR3fgCImL7TNZen3Qox4%2FAWEqknU%3D&reserved= =3D0 or https://nam11.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Ff= tp.ietf.org%2Fietf%2F1shadow-sites.txt&data=3D04%7C01%7Cjames.n.guichar= d%40futurewei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c75= 3a1d5591fedc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM= C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata= =3DHGYz6%2BCCQ%2Bnv7ZTVibxMJgujKFpHcXMj0XpmOEba0Ww%3D&reserved=3D0 ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ sfc mailing list sfc@ietf.org https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fsfc&data=3D04%7C01%7Cjames.n.guichard%40fu= turewei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d55= 91fedc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA= wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DQ6Wl= s3Pms3n4YDK1Ert9f1GRoiFaaX2kVPgUlmjTm8A%3D&reserved=3D0 From nobody Wed Feb 16 06:57:19 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBAA3A0D05 for ; Wed, 16 Feb 2022 06:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 VSkloIooNUHo for ; Wed, 16 Feb 2022 06:57:13 -0800 (PST) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 160873A135D for ; Wed, 16 Feb 2022 06:57:13 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id v13-20020a17090ac90d00b001b87bc106bdso6652008pjt.4 for ; Wed, 16 Feb 2022 06:57:13 -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=f5SqnjXsty2VXpyv7+xzEm7DPhxPDqqdXRSyiAPy8To=; b=MHwnEWk1TNtPIRhAm73yEO1mIfbvX3CT/jDY7SIFDs5RPWYck6URG0B7dX2NL+uv6n E69Lf0er6wCSiZ+j3dzdCW/27i0A3ypVckYDBPh8FBdzXaFEbHIEDYqWrsn4dpLJCET4 cp8KYWCsdKoQ6NOdCcrtYuTS0jWV2LVDCtJPe2HQBteCdqHUPd+xiEd80Xilsv5RPVd8 m43GPHWhrrJqtck09xs/b7ZLmYqKz73MpYaU3lK55KoIrtBl3vvubQ4urg/anbYJCE1e bFwBuGbGoIDcSFhK7pd7hv83Ij9gaAC7PNGP7fmoGCdJOTNVTLLaJhnsyPbBWW1SoG/r OBuw== 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=f5SqnjXsty2VXpyv7+xzEm7DPhxPDqqdXRSyiAPy8To=; b=yozY5ZhC8jzjnQhurt4dU7BDaTi8NRi5gS7MCjbcaIC9opkKAj/sg8RPDCV6msPwbc kkGLw1tt71xj+jLM9gm+DNZgFqBIQiesPLGX97EnOJywlCuD+ZpOfItEHbTyAilquOng glKVcNFN17OW2QaBVezbUJ/mlFgVSaDJj/IjHzugrJ8n4ESL/ocKZRRNkDWunS28KqrP /In5SOy2g35Dk2n5lKsSShC+yFSWqBQYqOUdwHq7BKaRtcJtsMAtG65Ef2xtqHBCaEsU ZSdorYtLA0ousFxXAYyMpWvZbNS30gKYofAjep5e4J4cwszVKWtzOqX5vegRRw/Smscy mgXA== X-Gm-Message-State: AOAM5333HVzh7Qf0E/jPUBpl1ER9zWJmnT6lL9QiDPmVAhs1iwlco3Tj BjRUmNaZhxGnZtVkQQLt/LZdWXqHte/wbQ4wG7ESTpYn X-Google-Smtp-Source: ABdhPJwiifIjbownWn44eC86zPmLSvXJFZr9Rn6pEcEXfU+WxPJwk1CQCJaF9j0BXWLUwO3ALKMYaIm1jse+azQe/4Y= X-Received: by 2002:a17:903:2288:b0:14d:7f2d:a39d with SMTP id b8-20020a170903228800b0014d7f2da39dmr2932656plh.80.1645023428367; Wed, 16 Feb 2022 06:57:08 -0800 (PST) MIME-Version: 1.0 References: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> <5AB114DA-0064-48B8-8C92-F1F71535B7D3@telefonica.com> In-Reply-To: <5AB114DA-0064-48B8-8C92-F1F71535B7D3@telefonica.com> From: Gyan Mishra Date: Wed, 16 Feb 2022 09:56:57 -0500 Message-ID: To: "Diego R. Lopez" Cc: "Joel M. Halpern" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000018582d05d823dd0f" Archived-At: Subject: Re: [sfc] Future of SFC work X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 14:57:18 -0000 --00000000000018582d05d823dd0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Diego! One other thought is as to closing the WG versus expanding the scope of the WG charter. In the original email my thoughts were that maybe the chairs believe not enough input and overall interest on SFC thus the idea of closing the WG. However I think the intention of the chairs may have been that the WG charter goals have all been met meaning a successful WG with the key RFC=E2= =80=99s for SFC being developed with the following RFC=E2=80=99s to name a few as w= ell as implemented by vendors: RFC 7438 SFC Problem Statement RFC RFC 7665 SFC Architecture RFC 8300 NSH RFC 8924 SFC OAM And with wrapping up OAM and once that is completed and if all goals of the initial charter have been met then without expanding the charter goals the WG could then be deemed successful as all goals have been met and close as many other WGs have closed after the Charter goals have been met. My thoughts on that is just as there are critical bread and butter Routing Area WGs that with the SFC charter keep it as =E2=80=9Congoing=E2=80=9D as = there is always continuing development work such as the big ones BESS, IDR, LSR, LSVR, TEAS, Spring, MPLS, RTGWG, BIER, PCE, CCAMP, PIM, RIFT and smaller ones WGs PALS, BFD, NVO3, BABEL, LISP. I think SFC being a smaller WG that does not have time slot at each IETF as other smaller WGs, however the work is still very important to the industry to continue on and expanding the charter to keep the development work going= . Kind Regards Gyan On Wed, Feb 16, 2022 at 9:13 AM Diego R. Lopez wrote: > Hi, > > > > The advantage of waiting a while before expressing my opinion is the Gyan > has perfectly done so (thanks!). I fully support his opinion about > continuing SFC work. And I must say I have the intention to continue bein= g > directly involved in some work of the group, as I was in the composition > draft or in the PoT activities. > > > > Be goode, > > > > -- > > "Esta vez no fallaremos, Doctor Infierno" > > > > Dr Diego R. Lopez > > Telefonica I+D > > https://www.linkedin.com/in/dr2lopez/ > > > > e-mail: diego.r.lopez@telefonica.com > > Mobile: +34 682 051 091 > > ---------------------------------- > > > > On 16/02/2022, 04:09, "sfc on behalf of Gyan Mishra" on behalf of hayabusagsm@gmail.com> wrote: > > > > > > Hi Joel, Jim & all > > > > I would say that one measure of success of a WG is that when you do a > google search, there are many scholarly articles related to SFC service > plane benefits as well as vendor implementations that I know of personall= y > with Cisco and Juniper and there maybe other vendors out there. > > > > I think the SFC WG has garnered overall interest in the technology > industry wide and it=E2=80=99s importance of a service plane. > > > > Overall I would say hats off to the chairs and WG members and all the har= d > work as to the success!!! > > > > As far as commentary and involvement in drafts, that issue exists across > the board as I am a member of every Routing Area WG, 54 WGs in total I > would say the interest and involvement has been as well with other WGs > related to personal drafts being progressed by individuals so I don=E2=80= =99t think > it=E2=80=99s just an issue with SFC WG. My observation has been that whe= never > multiple vendors have competing solutions they want to get to WG adoptio= n > and progression, those are the hot ones that have tremendous interest. > As well there are hot topics and the hot topics with drafts that have all > the major vendors involvement get the most feedback and of course progres= s > quickly. The key is garnering multi vendor interest and support to > progress an idea which goes for SFC and any WG. > > > > In my mind NFV brought about the concept of the need for service chaining > of VNF instances and now SFC has broadened the use case with NSH service > plane beyond NFV with physical hardware endpoints and any virtualization > model. > > > > I am in favor of expanding the scope of the WG to include in the charter > any networking area that involves virtualization such as DC NVO > encapsulation overlays such as VXLAN where I see Cisco and Juniper are > providing their own on standardized methods service chaining that is SFC > and SFC NSH independent where I think their can be tremendous benefits as > well as when extending the fabric to the host being able to use SFC NSH > service plane to link the SFF instances. I think as well maybe for TEAS > network slicing with 5G virtualization the underlay network slice and now > incorporating SFC NSH service plane into 5G UE services network slicing N= SC > slice controller. There maybe as well for OTN L1VPN and CCAMP WGs maybe= a > possibility of WG charter expansion into that arena SFC NSH possible > considerations. > > > > Spring WG Segment Routing in my mind as it=E2=80=99s allows the ability f= or > virtualization and abstraction of the underlay with SR-TE micro flow and > macro flow path steering and it lends itself to be a critical component = of > TEAS network slicing, I believe that SFC NSH service plane can really tak= e > off in that area with a myriad of use cases across the board. I believe > with the advent of SR really brings to light the criticality of SFC NSH > service plane. > > > > > > I would be happy to work on all existing documents being progressed that = I > am involved as well as working on any I am not involved, as well as with > the recharger expansion, any future development new work. > > > > Kind Regards > > > > Gyan > > > > On Fri, Jan 28, 2022 at 2:05 PM Joel M. Halpern > wrote: > > SFC Working Group: > > As part of discussing the OAM elated drafts in SFC, the chairs have > been looking at the overall working group participation. We note that > very few people have spoken up about the issues being discussed. For > most recent drafts we have been working to advance, it has been a lot of > work to get enough comments to justify advancement (and folks could > argue that we did not succeed.) > > We are considering various alternatives. We could, for example, > just close the working group. > One possibility is to recharter the working group to expand the scope. > There are two related questions that we would like to hear from the > working group about this. > > 1) If we were to consider expanding the charter, what things would you > like to see included in it? > > 2) If we do recharter will you work on the existing documents, and will > you engage on documents other than the one or two you personally would > like to see included? > > Thank you, > Joel and Jim > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > -- > > [image: Image removed by sender.] > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > > ------------------------------ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener informaci=C3=B3n privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilizaci=C3= =B3n, > divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en= virtud de > la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le ro= gamos > que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a s= u > destrucci=C3=B3n. > > The information contained in this transmission is confidential and > privileged information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution o= r > copying of this communication is strictly prohibited. If you have receive= d > this transmission in error, do not read it. Please immediately reply to t= he > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3= =A1rio, > pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 pa= ra uso exclusivo > da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa senhoria o des= tinat=C3=A1rio > indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga= =C3=A7=C3=A3o e/ou > c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da le= gisla=C3=A7=C3=A3o vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000018582d05d823dd0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Thank you= Diego!

One other though= t is as to closing the WG versus expanding the scope of the WG charter.

In the original email my th= oughts were that maybe the chairs believe not enough input and overall inte= rest =C2=A0on SFC thus the idea of closing the WG. =C2=A0

However I think the intention of the chai= rs may have been that the WG charter goals have all been met meaning a succ= essful WG with the key RFC=E2=80=99s for SFC being developed with the follo= wing RFC=E2=80=99s to name a few as well as implemented by vendors:

RFC 7438 SFC Problem Statement= =C2=A0
RFC RFC 7665 SFC Architecture
RFC 8300 NSH
RFC 8924 SFC OAM
<= div>

And with wrapping up OAM = and once that is completed and if all goals of the initial charter have bee= n met then without expanding the charter goals the WG could then be deemed = successful as all goals have been met and close as many other WGs have clos= ed after the Charter goals have been met.

=
My thoughts on that is just as there are critical bread a= nd butter Routing Area WGs that with the SFC charter keep it as =E2=80=9Con= going=E2=80=9D as there is always continuing development work such as the b= ig ones BESS, IDR, LSR, LSVR, TEAS, Spring, MPLS, RTGWG, BIER, PCE, CCAMP, = PIM, RIFT and smaller ones WGs PALS, BFD, NVO3, BABEL, LISP. =C2=A0

I think SFC being a smaller WG = that does not have time slot at each IETF as other smaller WGs, however the= work is still very important to the industry to continue on and expanding = the charter to keep the development work going.

=
Kind Regards=C2=A0

Gyan
On Wed, Feb 16, 2022 at 9:13 AM Diego R. Lope= z <die= go.r.lopez@telefonica.com> wrote:

Hi,

= =C2=A0

The ad= vantage of waiting a while before expressing my opinion is the Gyan has per= fectly done so (thanks!). I fully support his opinion about continuing SFC = work. And I must say I have the intention to continue being directly involved in som= e work of the group, as I was in the composition draft or in the PoT activi= ties.

=C2=A0

Be goo= de,

=C2=A0

--=

"Est= a vez no fallaremos, Doctor Infierno"

=C2=A0=

Dr Diego = R. Lopez

Telefonic= a I+D

https://www.linkedin.com/in/dr2lopez/=C2= =A0

=C2=A0=

e-mail:= =C2=A0diego.r.lopez@telefonica.com

Mobile= : =C2=A0+34 682 051 091

---------------------= -------------

=C2=A0<= /span>

On 16/02/2022, 04:09, &qu= ot;sfc on behalf of Gyan Mishra" <sfc-bounces@ietf.org on behalf of hayabusagsm@gmai= l.com> wrote:

=C2=A0

=C2=A0

Hi Joel, Jim & all=

=C2=A0

I would say that one meas= ure of success of a WG is that when you do a google search, there are many = scholarly articles related to SFC service plane benefits as well as vendor = implementations that I know of personally with Cisco and Juniper and there maybe other vendors out there. =C2=A0<= /u>

=C2=A0

I think the SFC WG has ga= rnered overall interest in the technology industry wide and it=E2=80=99s im= portance of a service plane. =C2=A0

=C2=A0

Overall I would say hats = off to the chairs and WG members and all the hard work =C2=A0as to the succ= ess!!!

=C2=A0

As far as commentary and = involvement in drafts, that issue exists across the board as I am a member = of every Routing Area WG, 54 WGs in total I would say the interest and invo= lvement has been as well with other WGs related to personal drafts being progressed by individuals so I don=E2= =80=99t think it=E2=80=99s just an issue with SFC WG.=C2=A0 My observation = has been that whenever multiple =C2=A0vendors have competing solutions they= want to get to WG adoption and progression, =C2=A0those are the hot ones that have tremendous interest. =C2=A0 As well there are hot topic= s and the hot topics with drafts that have all the major vendors involvemen= t get the most feedback and of course progress quickly.=C2=A0 The key is ga= rnering multi vendor interest and support to progress an idea which goes for SFC and any WG.

=C2=A0

In my mind NFV brought ab= out the concept of the need for service chaining of VNF instances and now S= FC has broadened the use case with NSH service plane beyond NFV with physic= al hardware endpoints and any virtualization model.

=C2=A0

I am in favor of expandin= g the scope of the WG to include in the charter any networking area that in= volves virtualization such as DC NVO encapsulation overlays such as VXLAN w= here I see Cisco and Juniper are providing their own on standardized methods service chaining that is SFC and SFC NSH= independent where I think their can be tremendous benefits as well as when= extending the fabric to the host being able to use SFC NSH service plane t= o link the SFF instances. =C2=A0 I think as well maybe for TEAS network slicing with 5G virtualization the underlay= network slice and now incorporating SFC NSH service plane into 5G UE servi= ces network slicing NSC slice controller.=C2=A0 There =C2=A0maybe as well f= or OTN L1VPN and CCAMP WGs maybe a possibility of WG charter expansion into that arena SFC NSH possible considerations.

=C2=A0

Spring WG Segment Routing= in my mind as it=E2=80=99s allows the ability for virtualization and abstr= action of the underlay with SR-TE micro flow and macro flow path steering a= nd it lends itself to =C2=A0be a critical component of TEAS network slicing, I believe that SFC NSH service plane can really t= ake off in that area with a myriad of use cases across the board.=C2=A0 I b= elieve with the advent of SR really brings to light the criticality of SFC = NSH service plane.

=C2=A0

=C2=A0

I would be happy to work = on all existing documents being progressed that I am involved as well as wo= rking on any I am not involved, as well as with the recharger expansion, an= y future development new work.

=C2=A0

Kind Regards=C2=A0=

=C2=A0

Gyan

=C2=A0

On Fri, Jan 28, 2022 at 2= :05 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

SFC Working Group:

=C2=A0 =C2=A0 =C2=A0As part of discussing the OAM elated drafts in SFC, the= chairs have
been looking at the overall working group participation.=C2=A0 We note that=
very few people have spoken up about the issues being discussed.=C2=A0 For =
most recent drafts we have been working to advance, it has been a lot of work to get enough comments to justify advancement (and folks could
argue that we did not succeed.)

=C2=A0 =C2=A0 =C2=A0We are considering various alternatives.=C2=A0 We could= , for example,
just close the working group.
One possibility is to recharter the working group to expand the scope.
There are two related questions that we would like to hear from the
working group about this.

1) If we were to consider expanding the charter, what things would you
like to see included in it?

2) If we do recharter will you work on the existing documents, and will you engage on documents other than the one or two you personally would
like to see included?

Thank you,
Joel and Jim

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

--

3D"Image=

Gyan Mishra

Network Solutions = Architect=C2=A0

Ema= il gyan.s.mishra@verizon.com

M 301 502-1347

=C2=A0



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is confidential and privileg= ed information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
--

=

Gyan Mishra

Network Solutions Architect=C2=A0<= /p>

Email gyan.s.mishra@ver= izon.com<= br>

M 301 502-1347


--00000000000018582d05d823dd0f-- From nobody Wed Feb 16 07:08:42 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A753A136D for ; Wed, 16 Feb 2022 07:08:39 -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, 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] 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 i31uB7NsAAta for ; Wed, 16 Feb 2022 07:08:35 -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 46CA03A136C for ; Wed, 16 Feb 2022 07:08:35 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) (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 opfedar21.francetelecom.fr (ESMTP service) with ESMTPS id 4JzLv51csWz7trK; Wed, 16 Feb 2022 16:08:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645024113; bh=xKHrWVy7yBk0hCI7YxDcIyjvF1Amap2C/SDyqbmag/M=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=iJB2mIrX6sO9z3Z8fFCrLL4mNMiRyxUfQemigUe/uEK1kijz8UpETJc/xTj/pvEwE 1Gg1XInXoFBId0qaMJ5Nw6HXFWLFT4E5DqCD2NF2AkRh7sGF43ltJnEIRDe+DghQje PowhWPEutIikZ7fX/zIn29fjM9bazahRxer0irb8ov5Pf8A6ABrUAWhNfkUwJhT8gh KzYn185fMhzDIGni9SeKlPETeb6WkunqAzR7XXJdSr2Y54dUq8gLVKYXpZmxw5GiXX SNh8NOJTba/uTwjPo/jN/CgNwAo8JitsVX/8S+1VeP9ewDXclUVUN+XWRKBSrNe80m +DsACcqD0HU2Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar06.francetelecom.fr (ESMTP service) with ESMTPS id 4JzLv50mVXz3wbJ; Wed, 16 Feb 2022 16:08:33 +0100 (CET) From: To: James Guichard , "sfc@ietf.org" Thread-Topic: I-D Action: draft-boucadair-sfc-oam-packet-00.txt Thread-Index: AQHYI0LOqTeC5k5EYkSp4mi5aRUmyqyWP62A///+fqCAAATzUA== Content-Class: Date: Wed, 16 Feb 2022 15:08:31 +0000 Message-ID: <21823_1645024113_620D1371_21823_465_1_787AE7BB302AE849A7480A190F8B933035494D9C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-16T14:53:13Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=5899aa03-3936-45a9-bf70-0492ae0d80a7; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 15:08:40 -0000 Hi Jim,=20 Great questions and I hope to hear more from the WG.=20 Please see inline my current thoughts on this. Cheers, Med > -----Message d'origine----- > De=A0: sfc De la part de James Guichard > Envoy=E9=A0: mercredi 16 f=E9vrier 2022 15:47 > =C0=A0: BOUCADAIR Mohamed INNOV/NET ; > sfc@ietf.org > Objet=A0: Re: [sfc] I-D Action: draft-boucadair-sfc-oam-packet-00.txt >=20 > Hi Med, >=20 > Thank you for doing this! >=20 > I think the following questions are relevant and should be clarified as > part of the draft text: >=20 > (1) Should the O-bit be set ONLY for OAM packets that are specific to the > SFC service layer? [Med] The proposed update less restrictive as it allows to include an OAM c= ommand/data even in the inner packet.=20 > (2) Should the O-bit be set in the cases where a solution uses the next > protocol field in the NSH header? In this case what is the purpose of the > O-bit given that the next protocol field already indicates the expected > behavior? [Med] The proposed update allows for this. Setting the O-bit allows to make= sure that all traversed SFC elements supports that OAM functionality. The = packet will get dropped if so. This is deterministic if we want the OAM ou= tcome to be reliable, otherwise there is a risk that the OAM data does not = reflect the full path.=20 > (3) If the O-bit is set is it the expected behavior to find relevant SFC > service layer OAM information ONLY in the context headers? [Med] The proposed update is less restrictive as it allows to have it in co= ntext headers or even the payload. The next-protocol will help interpreting= the data. The O-bit is allowed to be unset only when the OAM data is joint= ly sent with the user data.=20=20 > (4) If the answer to (3) is no then what is the sequence of behavior to > find the OAM information? (1) look in context headers and then next > protocol?, (2) look at next protocol and if not an OAM protocol look in > context headers?, (3) some other sequence? [Med] The exact sequence will depend on the definition of the context heade= r and the data identified by the next-protocol. I'm not sure we can impose = a generic sequence here, but I may be wrong.=20 >=20 > Jim >=20 > -----Original Message----- > From: sfc On Behalf Of mohamed.boucadair@orange.com > Sent: Wednesday, February 16, 2022 9:40 AM > To: sfc@ietf.org > Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt >=20 > Hi all, >=20 > A proposal to clarify the intent of SFC OAM packet. Comments are welcome. >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De=A0: I-D-Announce De la part de interne= t- > drafts@ietf.org Envoy=E9=A0: mercredi 16 f=E9vrier 2022 15:38 =C0=A0: i-d- > announce@ietf.org Objet=A0: I-D Action: draft-boucadair-sfc-oam-packet-00= .txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Clarifying Ambiguity related to Network Service > Header (NSH) OAM Packet > Author : Mohamed Boucadair > Filename : draft-boucadair-sfc-oam-packet-00.txt > Pages : 5 > Date : 2022-02-16 >=20 > Abstract: > This document clarifies an ambiguity in the Network Service Header > (NSH) specification related to the handling of O-bit. In particular, > this document clarifies the meaning of "OAM packet". >=20 > This document updates RFC8300. >=20 >=20 > The IETF datatracker status page for this draft is: > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fdraft-boucadair-sfc-oam- > packet%2F&data=3D04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be= 3413 > e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806= 19 > 2321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JB > TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DInMITh%2FD%2FNkAnNh0rvL5Eee= shzd > TbrxXeGKwOCVNyAA%3D&reserved=3D0 >=20 > There is also an htmlized version available at: > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fhtml%2Fdraft-boucadair-sfc-oam-packet- > 00&data=3D04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413e4d= 7f0d > ed08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6378061923218= 86 > 192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I= k1 > haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DXzLwiIMGzlBD0rM6Q%2Bf4v68iFYlcee3K= egm0 > 8FVcUmw%3D&reserved=3D0 >=20 >=20 > Internet-Drafts are also available by rsync at rsync.ietf.org::internet- > drafts >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Fmailman%2Flistinfo%2Fi-d- > announce&data=3D04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3= 413e > 4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6378061= 92 > 321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ= BT > iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DW3MJq4OJvBesWQg5t6FS%2FJQH7B= SK7G > QqAQzQV5rT2gY%3D&reserved=3D0 > Internet-Draft directories: > https://nam11.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.ie= tf.o > rg%2Fshadow.html&data=3D04%7C01%7Cjames.n.guichard%40futurewei.com%7C= a348 > 4be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7= C6 > 37806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l= uM > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D8fnzdUA6tJApFT%2FhR3= fgCI > mL7TNZen3Qox4%2FAWEqknU%3D&reserved=3D0 or > https://nam11.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.iet= f.or > g%2Fietf%2F1shadow- > sites.txt&data=3D04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be= 3413 > e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806= 19 > 2321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JB > TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DHGYz6%2BCCQ%2Bnv7ZTVibxMJgu= jKFp > HcXMj0XpmOEba0Ww%3D&reserved=3D0 >=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'alteratio= n, > 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 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Fmailman%2Flistinfo%2Fsfc&data=3D04%7C01%7Cjames.n.guichard%40fu= ture > wei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591= fe > dc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM= DA > iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DQ6Wls3= Pms3 > n4YDK1Ert9f1GRoiFaaX2kVPgUlmjTm8A%3D&reserved=3D0 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Feb 16 07:13:33 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454A63A1373 for ; Wed, 16 Feb 2022 07:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-TgfBvp0xoH for ; Wed, 16 Feb 2022 07:13:26 -0800 (PST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 803023A136E for ; Wed, 16 Feb 2022 07:13:26 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id w3so4440710edu.8 for ; Wed, 16 Feb 2022 07:13:26 -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=SjPMSLUSQ4ArOLRbw0P8AbSZmnPYaj/6fhBZCxm7LvQ=; b=Ebenhw5VtHckC3pI1FdSU6vT/xqFyUSdCeK1vMiQagxlAgkDlLB+Y6eeVidZn1NRFS G2B0wL/bNV/GOAvB5+eeFsUA6gtjytrwKnZxj4Dt1jggSCWmZ8GWuhn5ojrNe3JYr+4L BCT40Sts7K1J4UOedqBgx+RNMWr8ptWpwkTpuKTskF+ebGQEUs5qB7OxZeawSteVFyBV 24Tho5QOWsKSbySHksgoWF5kP/+VTINX+KvTeiXlCxDeDL6CYqINNGiBBjcvJQ5crjQv plZK4LVU0JD03U7U2HUdPmGo/vOyeRr+n06L248U2F4WXYyr2m3pBNCENHGk54oHlTBo rrzQ== 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=SjPMSLUSQ4ArOLRbw0P8AbSZmnPYaj/6fhBZCxm7LvQ=; b=VJsiokapAbhiQVXWpG/xQ64xBMWFxAvCV+JpZIWqAJedpclp4EZ0eGaBYnSgaF/GnV G9w97Eq7D+cs82/Yan/JH5/R0adAkdzL6iPPlW2w2frOPmNEhGDvgneOtk4R+KCzt0xm aMbVl+LvpEKOgb1/V9S/mb1o/F8IBXUhsqcQnKWxWsRUG1dtgpipnaGRA7JO5rJ2NjRL gT0heGy9Ivdc0zCQJ2BokPgzpwtgC+Pd1YZl/ATtHgfgfXsoFWjDx1dem8pUOiB/8F7E 7ON5HpGwo4+EO3QcYdGRJ+J6jZ0Dt1uX0l1F7MM5Asb1a8Ek+R1s+hix2U2pUGtf7hid /HtQ== X-Gm-Message-State: AOAM531wSW/vD6rjJ/N4FxGoRC/sr73y1tBWPAMh/MbqtzB3Gcn6Pgff A2WX9EWiKVnGx7YOG9xqHYhr32aFJR6Xmh+buQIU1+Uo0ks= X-Google-Smtp-Source: ABdhPJy20dRUvXsSptoofPu8SJ7rAbIiJCQvSsItphuGW7+IEp09UwXuVEg8Ghj4ttRE47E2KzT2HsKS56+ORsOo09A= X-Received: by 2002:a05:6402:51cb:b0:409:e99f:bc1c with SMTP id r11-20020a05640251cb00b00409e99fbc1cmr3493864edd.68.1645024403814; Wed, 16 Feb 2022 07:13:23 -0800 (PST) MIME-Version: 1.0 References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Greg Mirsky Date: Wed, 16 Feb 2022 07:13:12 -0800 Message-ID: To: Med Boucadair Cc: "sfc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003c7c6605d8241732" Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 15:13:32 -0000 --0000000000003c7c6605d8241732 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, many thanks for taking the lead and putting the proposal on the table. I have a question on the proposed new text for the O bit and its possible effect on IOAM: O bit: Setting this bit indicates an SFC OAM packet. Such a packet is any NSH-encapasulated packet that exclusively includes an OAM command and/or OAM data. My understanding of the new definition of the O bit is that the NSH includes and/or encapsulates only OAM command and/or data. IOAM, as I understand its application in NSH, may follow the NSH and have user payload after the IOAM data. And another scenario, if Flow ID TLV is used to influence user data through SFP, OAM will apply the same Flow ID value. Would such packet still be considered as "exclusively includes OAM command and/or data"? Regards, Greg On Wed, Feb 16, 2022 at 6:40 AM wrote: > Hi all, > > A proposal to clarify the intent of SFC OAM packet. Comments are welcome. > > Cheers, > Med > > -----Message d'origine----- > De : I-D-Announce De la part de > internet-drafts@ietf.org > Envoy=C3=A9 : mercredi 16 f=C3=A9vrier 2022 15:38 > =C3=80 : i-d-announce@ietf.org > Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Clarifying Ambiguity related to Network Service > Header (NSH) OAM Packet > Author : Mohamed Boucadair > Filename : draft-boucadair-sfc-oam-packet-00.txt > Pages : 5 > Date : 2022-02-16 > > Abstract: > This document clarifies an ambiguity in the Network Service Header > (NSH) specification related to the handling of O-bit. In particular, > this document clarifies the meaning of "OAM packet". > > This document updates RFC8300. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam-packet/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-packet-00 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > _______________________________________________ > 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.ietf.org/ietf/1shadow-sites.txt > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --0000000000003c7c6605d8241732 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Med,
many thanks for taking the le= ad and putting the proposal on the table.
I have a question on th= e proposed new text for the O bit and its possible effect on IOAM:
=C2=A0 =C2=A0O bit:=C2=A0 Setting this bit indicates an SFC OAM pack= et.=C2=A0 Such a packet
=C2=A0 =C2=A0 =C2=A0 is any NSH-encapasul= ated packet that exclusively includes an OAM
=C2=A0 =C2=A0 =C2=A0= command and/or OAM data.
My understanding of the new defin= ition of the O bit is that the NSH includes and/or encapsulates only OAM co= mmand and/or data. IOAM, as I understand its application in NSH, may follow= the NSH and have user payload after the IOAM data.
And another s= cenario, if Flow ID TLV is used to influence user data through SFP, OAM wil= l apply the same Flow ID value. Would such packet still be considered as &q= uot;exclusively includes OAM command and/or data"?

Regards,
Greg

On Wed, Feb 16, 2022 at 6:40 AM &l= t;mohamed.boucadair@orange.= com> wrote:
Hi all,

A proposal to clarify the intent of SFC OAM packet. Comments are welcome.
Cheers,
Med

-----Message d'origine-----
De=C2=A0: I-D-Announce <i-d-announce-bounces@ietf.org> De la part de internet-drafts@i= etf.org
Envoy=C3=A9=C2=A0: mercredi 16 f=C3=A9vrier 2022 15:38
=C3=80=C2=A0: i-= d-announce@ietf.org
Objet=C2=A0: I-D Action: draft-boucadair-sfc-oam-packet-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Clarifying Ambiguity related to Network Service Header (NSH) OAM Packet =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Moha= med Boucadair
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-bou= cadair-sfc-oam-packet-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2022-02-16

Abstract:
=C2=A0 =C2=A0This document clarifies an ambiguity in the Network Service He= ader
=C2=A0 =C2=A0(NSH) specification related to the handling of O-bit.=C2=A0 In= particular,
=C2=A0 =C2=A0this document clarifies the meaning of "OAM packet".=

=C2=A0 =C2=A0This document updates RFC8300.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-boucadair-sfc-oam-packet/

There is also an htmlized version available at:
https://datatracker.ietf.org/= doc/html/draft-boucadair-sfc-oam-packet-00


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


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___________________________________________________________________________= ______________________________________________

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.

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--0000000000003c7c6605d8241732-- From nobody Wed Feb 16 07:30:44 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF053A0D5D for ; Wed, 16 Feb 2022 07:30:42 -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_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] 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 TX73gpu8p10z for ; Wed, 16 Feb 2022 07:30:38 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 E10263A0D41 for ; Wed, 16 Feb 2022 07:30:37 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) (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 opfedar26.francetelecom.fr (ESMTP service) with ESMTPS id 4JzMNW3YMXzFpxy; Wed, 16 Feb 2022 16:30:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645025435; bh=sKbub1Y6ENIrPWMHqsHOhVV73IJc4GjfHkSbaG7g6yM=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=jixujmh2FUZbYXeFFYtsTHLjUJNGph4xVr9ou1Q6+TdD6s5u9cGov/hyXNX39JzwJ YpaN9UYvXC+2XSvaiXPrCZN7lAnQRWhybVE22ghSFFX5nwrvVhjZNcTkTMqhscKl0k ocvuR1Pkkd3z6s9XLVlGkWf+63hORT7D5gvtgSqGiQDamZ73bKCAJwgPMo8JZOg3tb QA8wQgQQoQmPodvtmOwm5f6JdjAJrXnlxf2gQLmwA6t7A0b79OGzzz0pN7AYGPP4eL nGKuvYPsKoB5MfN8xZozhgtaIIUic8k68KR1m47ReN5drK8yMMlu597Ca8nr0PJUwp HRMmZxS2USfEQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar02.francetelecom.fr (ESMTP service) with ESMTPS id 4JzMNW2gFszCqkP; Wed, 16 Feb 2022 16:30:35 +0100 (CET) From: To: Greg Mirsky CC: "sfc@ietf.org" Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt Thread-Index: AQHYI0LOqTeC5k5EYkSp4mi5aRUmyqyWSPcMgAAATbA= Content-Class: Date: Wed, 16 Feb 2022 15:30:34 +0000 Message-ID: <30956_1645025435_620D189B_30956_353_1_787AE7BB302AE849A7480A190F8B933035494DD5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-16T15:14:44Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=987ee2e2-cf38-4928-a9f9-08e755e58c40; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933035494DD5OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 15:30:43 -0000 --_000_787AE7BB302AE849A7480A190F8B933035494DD5OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IEdy ZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20+DQpFbnZvecOpIDogbWVyY3JlZGkgMTYg ZsOpdnJpZXIgMjAyMiAxNjoxMw0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTk5PVi9ORVQgPG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpDYyA6IHNmY0BpZXRmLm9yZw0KT2JqZXQgOiBS ZTogW3NmY10gVFI6IEktRCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC0w MC50eHQNCg0KSGkgTWVkLA0KbWFueSB0aGFua3MgZm9yIHRha2luZyB0aGUgbGVhZCBhbmQgcHV0 dGluZyB0aGUgcHJvcG9zYWwgb24gdGhlIHRhYmxlLg0KSSBoYXZlIGEgcXVlc3Rpb24gb24gdGhl IHByb3Bvc2VkIG5ldyB0ZXh0IGZvciB0aGUgTyBiaXQgYW5kIGl0cyBwb3NzaWJsZSBlZmZlY3Qg b24gSU9BTToNCiAgIE8gYml0OiAgU2V0dGluZyB0aGlzIGJpdCBpbmRpY2F0ZXMgYW4gU0ZDIE9B TSBwYWNrZXQuICBTdWNoIGEgcGFja2V0DQogICAgICBpcyBhbnkgTlNILWVuY2FwYXN1bGF0ZWQg cGFja2V0IHRoYXQgZXhjbHVzaXZlbHkgaW5jbHVkZXMgYW4gT0FNDQogICAgICBjb21tYW5kIGFu ZC9vciBPQU0gZGF0YS4NCk15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIG5ldyBkZWZpbml0aW9uIG9m IHRoZSBPIGJpdCBpcyB0aGF0IHRoZSBOU0ggaW5jbHVkZXMgYW5kL29yIGVuY2Fwc3VsYXRlcyBv bmx5IE9BTSBjb21tYW5kIGFuZC9vciBkYXRhLiBJT0FNLCBhcyBJIHVuZGVyc3RhbmQgaXRzIGFw cGxpY2F0aW9uIGluIE5TSCwgbWF5IGZvbGxvdyB0aGUgTlNIIGFuZCBoYXZlIHVzZXIgcGF5bG9h ZCBhZnRlciB0aGUgSU9BTSBkYXRhLg0KDQpbTWVkXSBQYWNrZXRzIHRoYXQgaW5jbHVkZSBhbHNv IHVzZXIgZGF0YSBhcmUgbm90IGNvbnNpZGVyZWQgYXMg4oCcT0FNIHBhY2tldHPigJ0gYXMgcGVy IHRoZSBuZXcgZGVmaW5pdGlvbi4NCg0KQW5kIGFub3RoZXIgc2NlbmFyaW8sIGlmIEZsb3cgSUQg VExWIGlzIHVzZWQgdG8gaW5mbHVlbmNlIHVzZXIgZGF0YSB0aHJvdWdoIFNGUCwgT0FNIHdpbGwg YXBwbHkgdGhlIHNhbWUgRmxvdyBJRCB2YWx1ZS4gV291bGQgc3VjaCBwYWNrZXQgc3RpbGwgYmUg Y29uc2lkZXJlZCBhcyAiZXhjbHVzaXZlbHkgaW5jbHVkZXMgT0FNIGNvbW1hbmQgYW5kL29yIGRh dGEiPw0KDQpbTWVkXSBZZXMsIHRoZXkgYXJlLiBGbG93IGlkIGlzIGp1c3QgYSBjb25zdHJhaW50 LCBpZiB5b3Ugd2lsbCwgdGhhdCBpcyB1c2VkIHRvIGluZmx1ZW5jZSBob3cgT0FNIGNvbW1hbmRz IHdpbGwgYmUgZXhlY3V0ZWQuDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFdlZCwgRmViIDE2LCAy MDIyIGF0IDY6NDAgQU0gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIGFsbCwNCg0KQSBwcm9wb3NhbCB0 byBjbGFyaWZ5IHRoZSBpbnRlbnQgb2YgU0ZDIE9BTSBwYWNrZXQuIENvbW1lbnRzIGFyZSB3ZWxj b21lLg0KDQpDaGVlcnMsDQpNZWQNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZSA6 IEktRC1Bbm5vdW5jZSA8aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmktZC1h bm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPj4gRGUgbGEgcGFydCBkZSBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCkVudm95w6kgOiBtZXJj cmVkaSAxNiBmw6l2cmllciAyMDIyIDE1OjM4DQrDgCA6IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxt YWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KT2JqZXQgOiBJLUQgQWN0aW9uOiBkcmFmdC1i b3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQtMDAudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz Lg0KDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogQ2xhcmlmeWluZyBBbWJpZ3VpdHkgcmVs YXRlZCB0byBOZXR3b3JrIFNlcnZpY2UgSGVhZGVyIChOU0gpIE9BTSBQYWNrZXQNCiAgICAgICAg QXV0aG9yICAgICAgICAgIDogTW9oYW1lZCBCb3VjYWRhaXINCiAgICAgICAgRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAwLnR4dA0KICAgICAgICBQYWdl cyAgICAgICAgICAgOiA1DQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMjItMDItMTYNCg0K QWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGNsYXJpZmllcyBhbiBhbWJpZ3VpdHkgaW4gdGhl IE5ldHdvcmsgU2VydmljZSBIZWFkZXINCiAgIChOU0gpIHNwZWNpZmljYXRpb24gcmVsYXRlZCB0 byB0aGUgaGFuZGxpbmcgb2YgTy1iaXQuICBJbiBwYXJ0aWN1bGFyLA0KICAgdGhpcyBkb2N1bWVu dCBjbGFyaWZpZXMgdGhlIG1lYW5pbmcgb2YgIk9BTSBwYWNrZXQiLg0KDQogICBUaGlzIGRvY3Vt ZW50IHVwZGF0ZXMgUkZDODMwMC4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC8NCg0KVGhlcmUgaXMgYWxzbyBhbiBodG1saXpl ZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAwDQoNCg0KSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSByc3luYyBhdCByc3luYy5pZXRmLm9yZzo6aW50ZXJu ZXQtZHJhZnRzDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZzxt YWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRw Oi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFz aGFkb3ctc2l0ZXMudHh0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBs aXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_787AE7BB302AE849A7480A190F8B933035494DD5OPEXCAUBMA2corp_ 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 bC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEdyZWcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5QbGVhc2Ugc2VlIGlubGluZS4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hlZXJzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5EZSZuYnNwOzo8 L2I+IEdyZWcgTWlyc2t5ICZsdDtncmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7IDxicj4NCjxiPkVu dm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAxNiBmw6l2cmllciAyMDIyIDE2OjEzPGJyPg0KPGI+ w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTk5PVi9ORVQgJmx0O21vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBzZmNAaWV0Zi5vcmc8 YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjogZHJhZnQt Ym91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBNZWQsPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWFueSB0aGFua3MgZm9yIHRha2luZyB0aGUgbGVhZCBh bmQgcHV0dGluZyB0aGUgcHJvcG9zYWwgb24gdGhlIHRhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGEgcXVlc3Rpb24gb24gdGhl IHByb3Bvc2VkIG5ldyB0ZXh0IGZvciB0aGUgTyBiaXQgYW5kIGl0cyBwb3NzaWJsZSBlZmZlY3Qg b24gSU9BTTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7TyBiaXQ6Jm5ic3A7IFNldHRpbmcgdGhpcyBiaXQgaW5k aWNhdGVzIGFuIFNGQyBPQU0gcGFja2V0LiZuYnNwOyBTdWNoIGEgcGFja2V0PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyBpcyBhbnkgTlNILWVuY2FwYXN1bGF0ZWQgcGFja2V0IHRoYXQgZXhjbHVzaXZlbHkgaW5j bHVkZXMgYW4gT0FNPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBjb21tYW5kIGFuZC9vciBPQU0gZGF0YS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgbmV3IGRlZmluaXRpb24gb2YgdGhlIE8gYml0IGlzIHRo YXQgdGhlIE5TSCBpbmNsdWRlcyBhbmQvb3IgZW5jYXBzdWxhdGVzIG9ubHkgT0FNIGNvbW1hbmQg YW5kL29yIGRhdGEuIElPQU0sIGFzIEkgdW5kZXJzdGFuZCBpdHMgYXBwbGljYXRpb24gaW4gTlNI LCBtYXkgZm9sbG93IHRoZSBOU0ggYW5kIGhhdmUgdXNlciBwYXlsb2FkIGFmdGVyIHRoZSBJT0FN IGRhdGEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNZWRdIFBhY2tldHMgdGhhdCBpbmNs dWRlIGFsc28gdXNlciBkYXRhIGFyZSBub3QgY29uc2lkZXJlZCBhcyDigJxPQU0gcGFja2V0c+KA nSBhcyBwZXIgdGhlIG5ldyBkZWZpbml0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+QW5kIGFub3RoZXIgc2NlbmFyaW8sIGlmIEZsb3cgSUQgVExWIGlz IHVzZWQgdG8gaW5mbHVlbmNlIHVzZXIgZGF0YSB0aHJvdWdoIFNGUCwgT0FNIHdpbGwgYXBwbHkg dGhlIHNhbWUgRmxvdyBJRCB2YWx1ZS4NCjwvc3Bhbj5Xb3VsZCBzdWNoIHBhY2tldCBzdGlsbCBi ZSBjb25zaWRlcmVkIGFzICZxdW90O2V4Y2x1c2l2ZWx5IGluY2x1ZGVzIE9BTSBjb21tYW5kIGFu ZC9vciBkYXRhJnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bTWVkXSBZZXMsIHRo ZXkgYXJlLiBGbG93IGlkIGlzIGp1c3QgYSBjb25zdHJhaW50LCBpZiB5b3Ugd2lsbCwgdGhhdCBp cyB1c2VkIHRvIGluZmx1ZW5jZSBob3cgT0FNIGNvbW1hbmRzIHdpbGwgYmUgZXhlY3V0ZWQuICZu YnNwOzwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMTYsIDIwMjIgYXQgNjo0 MCBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCwgPGJyPg0K PGJyPg0KQSBwcm9wb3NhbCB0byBjbGFyaWZ5IHRoZSBpbnRlbnQgb2YgU0ZDIE9BTSBwYWNrZXQu IENvbW1lbnRzIGFyZSB3ZWxjb21lLjxicj4NCjxicj4NCkNoZWVycyw8YnI+DQpNZWQ8YnI+DQo8 YnI+DQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQpEZSZuYnNwOzogSS1ELUFubm91 bmNlICZsdDs8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5pLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IERlIGxh IHBhcnQgZGUNCjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PGJyPg0KRW52b3nDqSZuYnNw OzogbWVyY3JlZGkgMTYgZsOpdnJpZXIgMjAyMiAxNTozODxicj4NCsOAJm5ic3A7OiA8YSBocmVm PSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aS1kLWFubm91 bmNlQGlldGYub3JnPC9hPjxicj4NCk9iamV0Jm5ic3A7OiBJLUQgQWN0aW9uOiBkcmFmdC1ib3Vj YWRhaXItc2ZjLW9hbS1wYWNrZXQtMDAudHh0PGJyPg0KPGJyPg0KPGJyPg0KQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRp cmVjdG9yaWVzLjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBU aXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBDbGFyaWZ5aW5n IEFtYmlndWl0eSByZWxhdGVkIHRvIE5ldHdvcmsgU2VydmljZSBIZWFkZXIgKE5TSCkgT0FNIFBh Y2tldDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBdXRob3ImbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogTW9oYW1lZCBCb3VjYWRhaXI8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBk cmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQtMDAudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFBhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs6IDU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAyMi0wMi0xNjxicj4NCjxicj4NCkFic3Ry YWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGNsYXJpZmllcyBhbiBhbWJpZ3Vp dHkgaW4gdGhlIE5ldHdvcmsgU2VydmljZSBIZWFkZXI8YnI+DQombmJzcDsgJm5ic3A7KE5TSCkg c3BlY2lmaWNhdGlvbiByZWxhdGVkIHRvIHRoZSBoYW5kbGluZyBvZiBPLWJpdC4mbmJzcDsgSW4g cGFydGljdWxhciw8YnI+DQombmJzcDsgJm5ic3A7dGhpcyBkb2N1bWVudCBjbGFyaWZpZXMgdGhl IG1lYW5pbmcgb2YgJnF1b3Q7T0FNIHBhY2tldCZxdW90Oy48YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7VGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzgzMDAuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91Y2FkYWlyLXNmYy1v YW0tcGFja2V0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC88L2E+PGJyPg0KPGJyPg0KVGhlcmUg aXMgYWxzbyBhbiBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWJvdWNhZGFpci1zZmMt b2FtLXBhY2tldC0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAwPC9hPjxicj4NCjxi cj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgcnN5bmMgYXQg cnN5bmMuaWV0Zi5vcmc6OmludGVybmV0LWRyYWZ0czxicj4NCjxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSS1ELUFubm91bmNl IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5JLUQtQW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5v dW5jZTwvYT48YnI+DQpJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogPGEgaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5p ZXRmLm9yZy9zaGFkb3cuaHRtbDwvYT4gb3IgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ll dGYvMXNoYWRvdy1zaXRlcy50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmZ0cDovL2Z0cC5pZXRmLm9y Zy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+ DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmM8YnI+DQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcjxicj4NCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPGJyPg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLjxicj4NCjxicj4NClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7PGJyPg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPGJyPg0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPGJyPg0KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxicj4NClRoYW5rIHlvdS48 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933035494DD5OPEXCAUBMA2corp_-- From nobody Wed Feb 16 07:52:08 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CFE3A0D7E for ; Wed, 16 Feb 2022 07:52: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, 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 T3c1CL2v_Jks for ; Wed, 16 Feb 2022 07:51:59 -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 B69043A0D77 for ; Wed, 16 Feb 2022 07:51:58 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id x5so4599434edd.11 for ; Wed, 16 Feb 2022 07:51: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=mSbpMoInx8HaOoqJbPNg3sLbTy6PrPDGferdWiPmqQw=; b=hfcwitRW//JjDsNfsUplvU0OrRScF6yVpCHwz0xvtwEqQyHDikZyEXAhBci7bC+HzQ S4S7RBLQQOlI7EzyfMaMbcZigZBuYVLsy/iPyPcykQyenQlCF2Eq9TgIBNw3kA0SztGX L52f/BRkwB/6tm3g+anVXU66uVqS/RNOSxfJiW3Bb6IYU0TSSffL2L5AO/N/teqPbUqH mHvdmTUsgB+vusLm1n0gmVJ4L8oHwANosFR6rwQgX5V6x9DiNaXqq5G4X2wPYbwIM1Fy PT1PyQZcQJgxDMIduIGZjzifuiO8/sevmXr87bRtpTN3lGCMVTUWmAdrlbpmrurt7Bcw dFIQ== 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=mSbpMoInx8HaOoqJbPNg3sLbTy6PrPDGferdWiPmqQw=; b=XMZpL8wn9qfEv88MO1MOE7H+ObA36NbbmhRJf5aako+tqzK+MgkKBboc5koRjqF+Wd HT6OQFoXUsOwifobazd9Cywka1kX5EUtxtzzx3zMqBQ6AAAUb+XPzNGZoGWSK3yiZt3L 81eQTP/rrxqzrfqNBZ5oFOD4GzAFwadCFXv+ccEB9NdaYGiWWwOARFJUb6b+Wbom2zAm yfMhpbk+yHU6o+Ls3FdOHHGvekIi/ktf13Lrk/1rvFSIoAG+SDEtNcATbuTkUhL7JbxV Me/zwC6S59JeXTOIb2ADLf4PHE5hue9dwA8/cYfEAMAFe/btlbGhXi9ZE4ov4XQR8ufy mtDw== X-Gm-Message-State: AOAM532PsPolK4G5CzYdK8MIdJ1qrj50Y2U4oqDS+rATV0trXWcPFOMx ucVPN1QvrtK3kQYfOEMoTefply+ELgpurYf/CQLOuf4d X-Google-Smtp-Source: ABdhPJzAdUQKmAj5ppEkIhxOUb4GNtDFTU5cSODmT8rIOJOAPRC3MaefxDBth0OImjUU4ZiypZPqbSI9A9J2Fdmu94s= X-Received: by 2002:a05:6402:d0d:b0:410:5e47:e013 with SMTP id eb13-20020a0564020d0d00b004105e47e013mr3774935edb.97.1645026715474; Wed, 16 Feb 2022 07:51:55 -0800 (PST) MIME-Version: 1.0 References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <30956_1645025435_620D189B_30956_353_1_787AE7BB302AE849A7480A190F8B933035494DD5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <30956_1645025435_620D189B_30956_353_1_787AE7BB302AE849A7480A190F8B933035494DD5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Greg Mirsky Date: Wed, 16 Feb 2022 07:51:44 -0800 Message-ID: To: Med Boucadair Cc: "sfc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000059d6805d824a135" Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 15:52:05 -0000 --000000000000059d6805d824a135 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, thank you for your expedient response. I have a follow-up question: How does one determine the nature, OAM or not-OAM, of data elements in the NSH Context header? As I understand it, draft-ietf-sfc-nsh-tlv does not provide that. Do we need to add it? Appreciate your thoughts on that. Regards, Greg On Wed, Feb 16, 2022 at 7:30 AM wrote: > Hi Greg, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Greg Mirsky > *Envoy=C3=A9 :* mercredi 16 f=C3=A9vrier 2022 16:13 > *=C3=80 :* BOUCADAIR Mohamed INNOV/NET > *Cc :* sfc@ietf.org > *Objet :* Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt > > > > Hi Med, > > many thanks for taking the lead and putting the proposal on the table. > > I have a question on the proposed new text for the O bit and its possible > effect on IOAM: > > O bit: Setting this bit indicates an SFC OAM packet. Such a packet > > is any NSH-encapasulated packet that exclusively includes an OAM > > command and/or OAM data. > > My understanding of the new definition of the O bit is that the NSH > includes and/or encapsulates only OAM command and/or data. IOAM, as I > understand its application in NSH, may follow the NSH and have user paylo= ad > after the IOAM data. > > > > *[Med] Packets that include also user data are not considered as =E2=80= =9COAM > packets=E2=80=9D as per the new definition.* > > > > And another scenario, if Flow ID TLV is used to influence user data > through SFP, OAM will apply the same Flow ID value. Would such packet > still be considered as "exclusively includes OAM command and/or data"? > > > > *[Med] Yes, they are. Flow id is just a constraint, if you will, that is > used to influence how OAM commands will be executed. * > > > > Regards, > > Greg > > > > On Wed, Feb 16, 2022 at 6:40 AM wrote: > > Hi all, > > A proposal to clarify the intent of SFC OAM packet. Comments are welcome. > > Cheers, > Med > > -----Message d'origine----- > De : I-D-Announce De la part de > internet-drafts@ietf.org > Envoy=C3=A9 : mercredi 16 f=C3=A9vrier 2022 15:38 > =C3=80 : i-d-announce@ietf.org > Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Clarifying Ambiguity related to Network Service > Header (NSH) OAM Packet > Author : Mohamed Boucadair > Filename : draft-boucadair-sfc-oam-packet-00.txt > Pages : 5 > Date : 2022-02-16 > > Abstract: > This document clarifies an ambiguity in the Network Service Header > (NSH) specification related to the handling of O-bit. In particular, > this document clarifies the meaning of "OAM packet". > > This document updates RFC8300. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam-packet/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-packet-00 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > _______________________________________________ > 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.ietf.org/ietf/1shadow-sites.txt > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _________________________________________________________________________= ________________________________________________ > > 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. > > --000000000000059d6805d824a135 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Med,
thank you for your expedient=C2=A0response. I = have a follow-up question:
How does one determine the nature, OAM or no= t-OAM, of data elements in the NSH Context header?
As I u= nderstand it, draft-ietf-sfc-nsh-tlv does not provide that. Do we need to a= dd it? Appreciate your thoughts on that.

Regards,<= /div>
Greg

On Wed, Feb 16, 2022 at 7:30 AM <mohamed.boucadair@orange.com> wrote:

Hi Greg,

=C2=A0

Please see inline.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Greg Mirsky <gregimirsky@gmail.com>
Envoy=C3=A9=C2=A0: mercredi 16 f=C3=A9vrier 2022 16:13
=C3=80=C2=A0: BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
Cc=C2=A0: sfc@ietf= .org
Objet=C2=A0: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packe= t-00.txt

=C2=A0

Hi Med,

many thanks for taking the lead and putting the prop= osal on the table.

I have a question on the proposed new text for the O= bit and its possible effect on IOAM:

=C2=A0 =C2=A0O bit:=C2=A0 Setting this bit indicates= an SFC OAM packet.=C2=A0 Such a packet

=C2=A0 =C2=A0 =C2=A0 is any NSH-encapasulated packet= that exclusively includes an OAM

=C2=A0 =C2=A0 =C2=A0 command and/or OAM data.=

My understanding of the new definition of the O bit = is that the NSH includes and/or encapsulates only OAM command and/or data. = IOAM, as I understand its application in NSH, may follow the NSH and have u= ser payload after the IOAM data.

=C2=A0

[Med] Packets that include also user da= ta are not considered as =E2=80=9COAM packets=E2=80=9D as per the new defin= ition.

=C2=A0

And another scenario, if Flow I= D TLV is used to influence user data through SFP, OAM will apply the same F= low ID value. Would such packet still be considered as "exclusively includes = OAM command and/or data"?

=C2=A0

[Med] Yes, they are. Flow id is just a = constraint, if you will, that is used to influence how OAM commands will be= executed. =C2=A0

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Feb 16, 2022 at 6:40 AM <mohamed.boucadair@orange.= com> wrote:

Hi all,

A proposal to clarify the intent of SFC OAM packet. Comments are welcome.
Cheers,
Med

-----Message d'origine-----
De=C2=A0: I-D-Announce <i-d-announce-bounces@ietf.org> De la part de internet-draf= ts@ietf.org
Envoy=C3=A9=C2=A0: mercredi 16 f=C3=A9vrier 2022 15:38
=C3=80=C2=A0: i-= d-announce@ietf.org
Objet=C2=A0: I-D Action: draft-boucadair-sfc-oam-packet-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Clarifying Ambiguity related to Network Service Header (NSH) OAM Packet =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Moha= med Boucadair
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-bou= cadair-sfc-oam-packet-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2022-02-16

Abstract:
=C2=A0 =C2=A0This document clarifies an ambiguity in the Network Service He= ader
=C2=A0 =C2=A0(NSH) specification related to the handling of O-bit.=C2=A0 In= particular,
=C2=A0 =C2=A0this document clarifies the meaning of "OAM packet".=

=C2=A0 =C2=A0This document updates RFC8300.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-sfc-oa= m-packet/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-bouc= adair-sfc-oam-packet-00


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


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___________________________________________________________________________= ______________________________________________

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.

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

______________________________________________________________________=
___________________________________________________

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.
--000000000000059d6805d824a135-- From nobody Wed Feb 16 08:22:11 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A513A13AB for ; Wed, 16 Feb 2022 08:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.786 X-Spam-Level: X-Spam-Status: No, score=-5.786 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL=1.31, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 VBd_GJ-vrPhX for ; Wed, 16 Feb 2022 08:22:02 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 5E1663A13A5 for ; Wed, 16 Feb 2022 08:22:02 -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 opfedar22.francetelecom.fr (ESMTP service) with ESMTPS id 4JzNWr1Ygfz2xjW; Wed, 16 Feb 2022 17:22:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645028520; bh=m6t1grMN9JfTvOKHS+Dh45X0DwahU6x1TbO9OOv3j6E=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=do0d+LW0UDbiOUE/JNWNCjCzeAsVBW5LvrIpQ0z8tmtc0L/wKSmENrorlRJDLzUpA kJkpNQ7V7xtv4/XvFqJqULMxP7Z6pcMyXcypBnwilgImcMQObDagBiHF39jTOqKyGJ naD7fuCrUS4hKWJTvEpSACWIFTFeL0lOizeaeDhLFbfkDSBFt9rAgFGbwI21gQ3jCP OqIOQFr1bxvWDBUVshExscX+7CY0FxAjfvH5XzBuaKJTbn1O3pbPPrHCKe//cCQ5D+ 4I3Kp9I7ngbvs9L/FDrHNr8kkxwCh+41hinsQltiqGJaNI+DxTGr6iLOvfO0tHDHCm WFUN17pVlbG6A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar03.francetelecom.fr (ESMTP service) with ESMTPS id 4JzNWr0dWlzCql3; Wed, 16 Feb 2022 17:22:00 +0100 (CET) From: To: Greg Mirsky CC: "sfc@ietf.org" Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt Thread-Index: AQHYI0LOqTeC5k5EYkSp4mi5aRUmyqyWU7t4gAAC4mA= Content-Class: Date: Wed, 16 Feb 2022 16:21:58 +0000 Message-ID: <3535_1645028520_620D24A8_3535_225_1_787AE7BB302AE849A7480A190F8B933035494EAE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <30956_1645025435_620D189B_30956_353_1_787AE7BB302AE849A7480A190F8B933035494DD5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-16T16:14:06Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=b051793a-d182-45db-9a24-060633606a25; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933035494EAEOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 16:22:08 -0000 --_000_787AE7BB302AE849A7480A190F8B933035494EAEOPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpUaGlzIGlzIGRldGVybWluZWQgYnkgdGhlIGVudGl0eSB0aGF0IGlzc3VlcyB0aGUg T0FNIHBhY2tldC4gVGhpcyBpcyB0eXBpY2FsbHkgYSBkZWRpY2F0ZWQgT0FNIGNvbnRyb2xsZXIg b3IgYW4gU0ZDIGVsZW1lbnQgKGNsYXNzaWZpZXIgZm9yIHRoZSBpb2FtIGNhc2UsIGZvciBleGFt cGxlKS4NCg0KDQpCVFcsIEkgdXBkYXRlZCB0aGUgZHJhZnQgdG8gcmVmbGVjdCB5b3VyIGNvbW1l bnRzIGFuZCBhbHNvIHRob3NlIGZyb20gSmltOiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAxDQoNCkNoZWVycywNCk1lZA0K DQpEZSA6IEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20+DQpFbnZvecOpIDogbWVy Y3JlZGkgMTYgZsOpdnJpZXIgMjAyMiAxNjo1Mg0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTk5P Vi9ORVQgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpDYyA6IHNmY0BpZXRmLm9yZw0K T2JqZXQgOiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFpci1zZmMtb2Ft LXBhY2tldC0wMC50eHQNCg0KSGkgTWVkLA0KdGhhbmsgeW91IGZvciB5b3VyIGV4cGVkaWVudCBy ZXNwb25zZS4gSSBoYXZlIGEgZm9sbG93LXVwIHF1ZXN0aW9uOg0KSG93IGRvZXMgb25lIGRldGVy bWluZSB0aGUgbmF0dXJlLCBPQU0gb3Igbm90LU9BTSwgb2YgZGF0YSBlbGVtZW50cyBpbiB0aGUg TlNIIENvbnRleHQgaGVhZGVyPw0KQXMgSSB1bmRlcnN0YW5kIGl0LCBkcmFmdC1pZXRmLXNmYy1u c2gtdGx2IGRvZXMgbm90IHByb3ZpZGUgdGhhdC4gRG8gd2UgbmVlZCB0byBhZGQgaXQ/IEFwcHJl Y2lhdGUgeW91ciB0aG91Z2h0cyBvbiB0aGF0Lg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBXZWQs IEZlYiAxNiwgMjAyMiBhdCA3OjMwIEFNIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQpIaSBHcmVnLA0KDQpQ bGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogR3JlZyBNaXJza3kgPGdy ZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4NCkVudm95 w6kgOiBtZXJjcmVkaSAxNiBmw6l2cmllciAyMDIyIDE2OjEzDQrDgCA6IEJPVUNBREFJUiBNb2hh bWVkIElOTk9WL05FVCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+DQpDYyA6IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KT2JqZXQgOiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFp ci1zZmMtb2FtLXBhY2tldC0wMC50eHQNCg0KSGkgTWVkLA0KbWFueSB0aGFua3MgZm9yIHRha2lu ZyB0aGUgbGVhZCBhbmQgcHV0dGluZyB0aGUgcHJvcG9zYWwgb24gdGhlIHRhYmxlLg0KSSBoYXZl IGEgcXVlc3Rpb24gb24gdGhlIHByb3Bvc2VkIG5ldyB0ZXh0IGZvciB0aGUgTyBiaXQgYW5kIGl0 cyBwb3NzaWJsZSBlZmZlY3Qgb24gSU9BTToNCiAgIE8gYml0OiAgU2V0dGluZyB0aGlzIGJpdCBp bmRpY2F0ZXMgYW4gU0ZDIE9BTSBwYWNrZXQuICBTdWNoIGEgcGFja2V0DQogICAgICBpcyBhbnkg TlNILWVuY2FwYXN1bGF0ZWQgcGFja2V0IHRoYXQgZXhjbHVzaXZlbHkgaW5jbHVkZXMgYW4gT0FN DQogICAgICBjb21tYW5kIGFuZC9vciBPQU0gZGF0YS4NCk15IHVuZGVyc3RhbmRpbmcgb2YgdGhl IG5ldyBkZWZpbml0aW9uIG9mIHRoZSBPIGJpdCBpcyB0aGF0IHRoZSBOU0ggaW5jbHVkZXMgYW5k L29yIGVuY2Fwc3VsYXRlcyBvbmx5IE9BTSBjb21tYW5kIGFuZC9vciBkYXRhLiBJT0FNLCBhcyBJ IHVuZGVyc3RhbmQgaXRzIGFwcGxpY2F0aW9uIGluIE5TSCwgbWF5IGZvbGxvdyB0aGUgTlNIIGFu ZCBoYXZlIHVzZXIgcGF5bG9hZCBhZnRlciB0aGUgSU9BTSBkYXRhLg0KDQpbTWVkXSBQYWNrZXRz IHRoYXQgaW5jbHVkZSBhbHNvIHVzZXIgZGF0YSBhcmUgbm90IGNvbnNpZGVyZWQgYXMg4oCcT0FN IHBhY2tldHPigJ0gYXMgcGVyIHRoZSBuZXcgZGVmaW5pdGlvbi4NCg0KQW5kIGFub3RoZXIgc2Nl bmFyaW8sIGlmIEZsb3cgSUQgVExWIGlzIHVzZWQgdG8gaW5mbHVlbmNlIHVzZXIgZGF0YSB0aHJv dWdoIFNGUCwgT0FNIHdpbGwgYXBwbHkgdGhlIHNhbWUgRmxvdyBJRCB2YWx1ZS4gV291bGQgc3Vj aCBwYWNrZXQgc3RpbGwgYmUgY29uc2lkZXJlZCBhcyAiZXhjbHVzaXZlbHkgaW5jbHVkZXMgT0FN IGNvbW1hbmQgYW5kL29yIGRhdGEiPw0KDQpbTWVkXSBZZXMsIHRoZXkgYXJlLiBGbG93IGlkIGlz IGp1c3QgYSBjb25zdHJhaW50LCBpZiB5b3Ugd2lsbCwgdGhhdCBpcyB1c2VkIHRvIGluZmx1ZW5j ZSBob3cgT0FNIGNvbW1hbmRzIHdpbGwgYmUgZXhlY3V0ZWQuDQoNClJlZ2FyZHMsDQpHcmVnDQoN Ck9uIFdlZCwgRmViIDE2LCAyMDIyIGF0IDY6NDAgQU0gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIGFs bCwNCg0KQSBwcm9wb3NhbCB0byBjbGFyaWZ5IHRoZSBpbnRlbnQgb2YgU0ZDIE9BTSBwYWNrZXQu IENvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpDaGVlcnMsDQpNZWQNCg0KLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQpEZSA6IEktRC1Bbm5vdW5jZSA8aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPj4gRGUgbGEgcGFydCBk ZSBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4NCkVudm95w6kgOiBtZXJjcmVkaSAxNiBmw6l2cmllciAyMDIyIDE1OjM4DQrDgCA6IGktZC1h bm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KT2JqZXQgOiBJ LUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQtMDAudHh0DQoNCg0KQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzIGRpcmVjdG9yaWVzLg0KDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogQ2xhcmlm eWluZyBBbWJpZ3VpdHkgcmVsYXRlZCB0byBOZXR3b3JrIFNlcnZpY2UgSGVhZGVyIChOU0gpIE9B TSBQYWNrZXQNCiAgICAgICAgQXV0aG9yICAgICAgICAgIDogTW9oYW1lZCBCb3VjYWRhaXINCiAg ICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAw LnR4dA0KICAgICAgICBQYWdlcyAgICAgICAgICAgOiA1DQogICAgICAgIERhdGUgICAgICAgICAg ICA6IDIwMjItMDItMTYNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGNsYXJpZmllcyBh biBhbWJpZ3VpdHkgaW4gdGhlIE5ldHdvcmsgU2VydmljZSBIZWFkZXINCiAgIChOU0gpIHNwZWNp ZmljYXRpb24gcmVsYXRlZCB0byB0aGUgaGFuZGxpbmcgb2YgTy1iaXQuICBJbiBwYXJ0aWN1bGFy LA0KICAgdGhpcyBkb2N1bWVudCBjbGFyaWZpZXMgdGhlIG1lYW5pbmcgb2YgIk9BTSBwYWNrZXQi Lg0KDQogICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDODMwMC4NCg0KDQpUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC8NCg0KVGhlcmUg aXMgYWxzbyBhbiBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAw DQoNCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSByc3luYyBhdCByc3lu Yy5pZXRmLm9yZzo6aW50ZXJuZXQtZHJhZnRzDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1B bm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0 IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yIGZ0cDovL2Z0 cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpU aGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K DQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91LgoK --_000_787AE7BB302AE849A7480A190F8B933035494EAEOPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRl eHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJUZXh0ZSBicnV0IENhciI7DQoJbWFyZ2luOjBjbTsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLD qWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bh bi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0 w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RlI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u VGV4dGVicnV0Q2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBicnV0IENhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBicnV0IjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZS0sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhp cyBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBlbnRpdHkgdGhhdCBpc3N1ZXMgdGhlIE9BTSBwYWNrZXQu IFRoaXMgaXMgdHlwaWNhbGx5IGEgZGVkaWNhdGVkIE9BTSBjb250cm9sbGVyIG9yIGFuIFNGQyBl bGVtZW50IChjbGFzc2lmaWVyIGZvcg0KIHRoZSBpb2FtIGNhc2UsIGZvciBleGFtcGxlKS4gJm5i c3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+QlRXLCBJIHVwZGF0ZWQgdGhlIGRyYWZ0IHRvIHJlZmxlY3QgeW91ciBjb21tZW50cyBh bmQgYWxzbyB0aG9zZSBmcm9tIEppbToNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAxIj48c3Bh biBsYW5nPSJFTi1VUyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJv dWNhZGFpci1zZmMtb2FtLXBhY2tldC0wMTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RGUmbmJz cDs6PC9iPiBHcmVnIE1pcnNreSAmbHQ7Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0OyA8YnI+DQo8 Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMTYgZsOpdnJpZXIgMjAyMiAxNjo1Mjxicj4N CjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU5OT1YvTkVUICZsdDttb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tJmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4gc2ZjQGlldGYu b3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246IGRy YWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC0wMC50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBNZWQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmsgeW91IGZvciB5b3VyIGV4cGVkaWVudCZuYnNwO3Jl c3BvbnNlLiBJIGhhdmUgYSBmb2xsb3ctdXAgcXVlc3Rpb246PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBkb2VzIG9uZSBkZXRl cm1pbmUgdGhlIG5hdHVyZSwgT0FNIG9yIG5vdC1PQU0sIG9mIGRhdGEgZWxlbWVudHMgaW4gdGhl IE5TSCBDb250ZXh0IGhlYWRlcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgSSB1bmRlcnN0YW5kIGl0LCBkcmFmdC1pZXRmLXNm Yy1uc2gtdGx2IGRvZXMgbm90IHByb3ZpZGUgdGhhdC4gRG8gd2UgbmVlZCB0byBhZGQgaXQ/IEFw cHJlY2lhdGUgeW91ciB0aG91Z2h0cyBvbiB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3JlZzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAxNiwgMjAyMiBh dCA3OjMwIEFNICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5IaSBHcmVnLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlBsZWFzZSBzZWUgaW5saW5lLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPk1lZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj5EZSZuYnNwOzo8L2I+IEdyZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86 Z3JlZ2ltaXJza3lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3JlZ2ltaXJza3lAZ21haWwu Y29tPC9hPiZndDsNCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAxNiBmw6l2 cmllciAyMDIyIDE2OjEzPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJ Tk5PVi9ORVQgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t IiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2MmbmJzcDs6PC9iPiA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtz ZmNdIFRSOiBJLUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQtMDAudHh0 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5IaSBNZWQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5t YW55IHRoYW5rcyBmb3IgdGFraW5nIHRoZSBsZWFkIGFuZCBwdXR0aW5nIHRoZSBwcm9wb3NhbCBv biB0aGUgdGFibGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkkgaGF2ZSBhIHF1ZXN0aW9uIG9uIHRoZSBwcm9wb3NlZCBuZXcgdGV4dCBmb3Ig dGhlIE8gYml0IGFuZCBpdHMgcG9zc2libGUgZWZmZWN0IG9uIElPQU06PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5i c3A7TyBiaXQ6Jm5ic3A7IFNldHRpbmcgdGhpcyBiaXQgaW5kaWNhdGVzIGFuIFNGQyBPQU0gcGFj a2V0LiZuYnNwOyBTdWNoIGEgcGFja2V0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGlzIGFueSBOU0gtZW5j YXBhc3VsYXRlZCBwYWNrZXQgdGhhdCBleGNsdXNpdmVseSBpbmNsdWRlcyBhbiBPQU08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgY29tbWFuZCBhbmQvb3IgT0FNIGRhdGEuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TXkgdW5kZXJzdGFuZGlu ZyBvZiB0aGUgbmV3IGRlZmluaXRpb24gb2YgdGhlIE8gYml0IGlzIHRoYXQgdGhlIE5TSCBpbmNs dWRlcyBhbmQvb3IgZW5jYXBzdWxhdGVzIG9ubHkgT0FNIGNvbW1hbmQgYW5kL29yIGRhdGEuIElP QU0sIGFzIEkgdW5kZXJzdGFuZCBpdHMgYXBwbGljYXRpb24gaW4gTlNILCBtYXkNCiBmb2xsb3cg dGhlIE5TSCBhbmQgaGF2ZSB1c2VyIHBheWxvYWQgYWZ0ZXIgdGhlIElPQU0gZGF0YS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwv c3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNZWRdIFBhY2tldHMgdGhhdCBpbmNsdWRlIGFsc28g dXNlciBkYXRhIGFyZSBub3QgY29uc2lkZXJlZCBhcyDigJxPQU0gcGFja2V0c+KAnSBhcyBwZXIg dGhlIG5ldyBkZWZpbml0aW9uLjwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPkFuZCBhbm90aGVyIHNjZW5hcmlvLCBpZiBGbG93IElEIFRMViBpcyB1c2Vk IHRvIGluZmx1ZW5jZSB1c2VyIGRhdGEgdGhyb3VnaCBTRlAsIE9BTSB3aWxsIGFwcGx5IHRoZSBz YW1lIEZsb3cgSUQgdmFsdWUuDQo8L3NwYW4+V291bGQgc3VjaCBwYWNrZXQgc3RpbGwgYmUgY29u c2lkZXJlZCBhcyAmcXVvdDtleGNsdXNpdmVseSBpbmNsdWRlcyBPQU0gY29tbWFuZCBhbmQvb3Ig ZGF0YSZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPltNZWRdIFllcywgdGhl eSBhcmUuIEZsb3cgaWQgaXMganVzdCBhIGNvbnN0cmFpbnQsIGlmIHlvdSB3aWxsLCB0aGF0IGlz IHVzZWQgdG8gaW5mbHVlbmNlIGhvdyBPQU0gY29tbWFuZHMNCiB3aWxsIGJlIGV4ZWN1dGVkLiAm bmJzcDs8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R3Jl ZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5PbiBXZWQsIEZlYiAxNiwgMjAyMiBhdCA2OjQwIEFNICZsdDs8YSBocmVmPSJt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIGFsbCwNCjxicj4NCjxicj4NCkEgcHJvcG9zYWwgdG8g Y2xhcmlmeSB0aGUgaW50ZW50IG9mIFNGQyBPQU0gcGFja2V0LiBDb21tZW50cyBhcmUgd2VsY29t ZS48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KTWVkPGJyPg0KPGJyPg0KLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tPGJyPg0KRGUmbmJzcDs6IEktRC1Bbm5vdW5jZSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aS1kLWFu bm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBEZSBsYSBwYXJ0IGRlDQo8YSBocmVmPSJt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPC9hPjxicj4NCkVudm95w6kmbmJzcDs6IG1lcmNyZWRpIDE2IGbDqXZy aWVyIDIwMjIgMTU6Mzg8YnI+DQrDgCZuYnNwOzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5j ZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+ DQpPYmpldCZuYnNwOzogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0 LTAwLnR4dDxicj4NCjxicj4NCjxicj4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQo8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogQ2xhcmlmeWluZyBBbWJpZ3VpdHkgcmVsYXRlZCB0 byBOZXR3b3JrIFNlcnZpY2UgSGVhZGVyIChOU0gpIE9BTSBQYWNrZXQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9yJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA6IE1vaGFtZWQgQm91Y2FkYWlyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZp bGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtYm91Y2FkYWlyLXNmYy1v YW0tcGFja2V0LTAwLnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiA1PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IERhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA6IDIwMjItMDItMTY8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5i c3A7VGhpcyBkb2N1bWVudCBjbGFyaWZpZXMgYW4gYW1iaWd1aXR5IGluIHRoZSBOZXR3b3JrIFNl cnZpY2UgSGVhZGVyPGJyPg0KJm5ic3A7ICZuYnNwOyhOU0gpIHNwZWNpZmljYXRpb24gcmVsYXRl ZCB0byB0aGUgaGFuZGxpbmcgb2YgTy1iaXQuJm5ic3A7IEluIHBhcnRpY3VsYXIsPGJyPg0KJm5i c3A7ICZuYnNwO3RoaXMgZG9jdW1lbnQgY2xhcmlmaWVzIHRoZSBtZWFuaW5nIG9mICZxdW90O09B TSBwYWNrZXQmcXVvdDsuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgdXBk YXRlcyBSRkM4MzAwLjxicj4NCjxicj4NCjxicj4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC8iIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRhaXIt c2ZjLW9hbS1wYWNrZXQvPC9hPjxicj4NCjxicj4NClRoZXJlIGlzIGFsc28gYW4gaHRtbGl6ZWQg dmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQtMDAiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWJv dWNhZGFpci1zZmMtb2FtLXBhY2tldC0wMDwvYT48YnI+DQo8YnI+DQo8YnI+DQpJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IHJzeW5jIGF0IHJzeW5jLmlldGYub3JnOjppbnRl cm5ldC1kcmFmdHM8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SS1E LUFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8L2E+PGJyPg0KSW50ZXJu ZXQtRHJhZnQgZGlyZWN0b3JpZXM6IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93 Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWw8 L2E+IG9yIDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0 IiB0YXJnZXQ9Il9ibGFuayI+DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVz LnR4dDwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPGJyPg0KcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8YnI+ DQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLDxicj4NCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48YnI+DQo8YnI+ DQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Ozxicj4NCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxicj4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC48YnI+DQpUaGFuayB5b3UuPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNm Y0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3ByZT4NCjxwcmU+cGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5UaGFuayB5b3UuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9Q UkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933035494EAEOPEXCAUBMA2corp_-- From nobody Wed Feb 16 08:29:49 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0256E3A0D8D for ; Wed, 16 Feb 2022 08:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.815 X-Spam-Level: X-Spam-Status: No, score=-7.815 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_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=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 HgSGZAA0VUsE for ; Wed, 16 Feb 2022 08:29: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 271073A0D89 for ; Wed, 16 Feb 2022 08:29:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4JzNhh6KcDz6G9Lf; Wed, 16 Feb 2022 08:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1645028980; bh=sZsajhyxr/OMP6DtIPQ2IPwmlC/dd+aqUhknDs3ANDE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=g+Ntt+49Ah8F3rx8S5NfpN8t/dvK6pMMjN0BVNRDD6pow2AbvRV3yaVxgiqPlCsiM rPIxe1Sc32sokqOZQHsf9IVVShrkNal+1H+/mUtPZUYQZW/EdHdhWC6lb2KUgtSd/x xsZ6BH/1i4fiRdIhGFNgeTrLFkSNRTnsaUnF4o0I= 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 4JzNhh1T1fz6G7qd; Wed, 16 Feb 2022 08:29:40 -0800 (PST) Message-ID: <5efa6354-4396-d1b1-bec3-122d2aa148c2@joelhalpern.com> Date: Wed, 16 Feb 2022 11:29:38 -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 To: mohamed.boucadair@orange.com, Greg Mirsky Cc: "sfc@ietf.org" References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <30956_1645025435_620D189B_30956_353_1_787AE7BB302AE849A7480A190F8B933035494DD5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <3535_1645028520_620D24A8_3535_225_1_787AE7BB302AE849A7480A190F8B933035494EAE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" In-Reply-To: <3535_1645028520_620D24A8_3535_225_1_787AE7BB302AE849A7480A190F8B933035494EAE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 16:29:46 -0000 Thank you for writing this. I look forward to more dscussion by more WG members. I want to ask one clarifying quesiton about an example that was raised earlier. If the NSH payload is an IP packet, and that packet is addressed to something other than this node, and that packet is carrying an ICMP echo, is that an SFC OAM packet requiring the O-bit being set? And conversely, is an SFF required to check for that case if it sees an NSH with the O-bit set? Yours, Joel On 2/16/2022 11:21 AM, mohamed.boucadair@orange.com wrote: > Re-, > > This is determined by the entity that issues the OAM packet. This is > typically a dedicated OAM controller or an SFC element (classifier for > the ioam case, for example). > > BTW, I updated the draft to reflect your comments and also those from > Jim: https://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-oam-packet-01 > > > Cheers, > > Med > > *De :* Greg Mirsky > *Envoyé :* mercredi 16 février 2022 16:52 > *À :* BOUCADAIR Mohamed INNOV/NET > *Cc :* sfc@ietf.org > *Objet :* Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt > > Hi Med, > > thank you for your expedient response. I have a follow-up question: > > How does one determine the nature, OAM or not-OAM, of data elements > in the NSH Context header? > > As I understand it, draft-ietf-sfc-nsh-tlv does not provide that. Do we > need to add it? Appreciate your thoughts on that. > > Regards, > > Greg > > On Wed, Feb 16, 2022 at 7:30 AM > wrote: > > Hi Greg, > > Please see inline. > > Cheers, > > Med > > *De :* Greg Mirsky > > *Envoyé :* mercredi 16 février 2022 16:13 > *À :* BOUCADAIR Mohamed INNOV/NET > > *Cc :* sfc@ietf.org > *Objet :* Re: [sfc] TR: I-D Action: > draft-boucadair-sfc-oam-packet-00.txt > > Hi Med, > > many thanks for taking the lead and putting the proposal on the table. > > I have a question on the proposed new text for the O bit and its > possible effect on IOAM: > >    O bit:  Setting this bit indicates an SFC OAM packet.  Such a packet > >       is any NSH-encapasulated packet that exclusively includes an OAM > >       command and/or OAM data. > > My understanding of the new definition of the O bit is that the NSH > includes and/or encapsulates only OAM command and/or data. IOAM, as > I understand its application in NSH, may follow the NSH and have > user payload after the IOAM data. > > *//* > > */[Med] Packets that include also user data are not considered as > “OAM packets” as per the new definition./* > > And another scenario, if Flow ID TLV is used to influence user data > through SFP, OAM will apply the same Flow ID value. Would such > packet still be considered as "exclusively includes OAM command > and/or data"? > > *//* > > */[Med] Yes, they are. Flow id is just a constraint, if you will, > that is used to influence how OAM commands will be executed. /* > > Regards, > > Greg > > On Wed, Feb 16, 2022 at 6:40 AM > wrote: > > Hi all, > > A proposal to clarify the intent of SFC OAM packet. Comments are > welcome. > > Cheers, > Med > > -----Message d'origine----- > De : I-D-Announce > De la part de > internet-drafts@ietf.org > Envoyé : mercredi 16 février 2022 15:38 > À : i-d-announce@ietf.org > Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > >         Title           : Clarifying Ambiguity related to > Network Service Header (NSH) OAM Packet >         Author          : Mohamed Boucadair >         Filename        : draft-boucadair-sfc-oam-packet-00.txt >         Pages           : 5 >         Date            : 2022-02-16 > > Abstract: >    This document clarifies an ambiguity in the Network Service > Header >    (NSH) specification related to the handling of O-bit.  In > particular, >    this document clarifies the meaning of "OAM packet". > >    This document updates RFC8300. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam-packet/ > > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-packet-00 > > > > Internet-Drafts are also available by rsync at > rsync.ietf.org::internet-drafts > > > _______________________________________________ > 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.ietf.org/ietf/1shadow-sites.txt > > > _________________________________________________________________________________________________________________________ > > 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. > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _________________________________________________________________________________________________________________________ > > 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. > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Feb 16 23:13:59 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EBE3A14B9 for ; Wed, 16 Feb 2022 23:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.785 X-Spam-Level: X-Spam-Status: No, score=-0.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL=1.31, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 AJ1piMxf2QBy for ; Wed, 16 Feb 2022 23:13:53 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 01E7F3A14D3 for ; Wed, 16 Feb 2022 23:13:52 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) (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 opfedar25.francetelecom.fr (ESMTP service) with ESMTPS id 4JzmJv3Wrpz8t4v; Thu, 17 Feb 2022 08:13:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645082031; bh=ZymAtUJgU30Ete+wwBZsP2DeiNnD6oqbeoFNOc+D+yQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=rSTSlmZkM1oyCIwnA09a6uajJWiqHnMGdo7vm7euUVojZ4GiG8oF4/f76FZHNu6UN v6cHW6bjfbKbWlkFumY8WenDdz+dUeuzlkRnc3/ksYudSYQ8IzjYNIOrhdegd7Pv+C 5tty/eOvsCexQAnB3zaBaXef4Tz/KHaiou8Ie/J5yD+5X2rZb339L9SC1xDeiqFSuN Sc4XRZhejcthJOORALq/qTkv+XHQshpAagZg/uttlvBZNHG2xqW9TcYBfBsEFR9AJg tz/jNkIIP9GxFD3CCpf+MmwiaQ6nzo4q7S4ZStbzDCFqZ+gap6fJoB8v7r8x9tlDmg OQYP5f4YkiQbA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar02.francetelecom.fr (ESMTP service) with ESMTPS id 4JzmJv2TYQzCql0; Thu, 17 Feb 2022 08:13:51 +0100 (CET) From: To: "Joel M. Halpern" , Greg Mirsky CC: "sfc@ietf.org" Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt Thread-Index: AQHYI0LOqTeC5k5EYkSp4mi5aRUmyqyWXkqZgADrEJA= Content-Class: Date: Thu, 17 Feb 2022 07:13:50 +0000 Message-ID: <26440_1645082031_620DF5AF_26440_39_1_787AE7BB302AE849A7480A190F8B9330354954F7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <30956_1645025435_620D189B_30956_353_1_787AE7BB302AE849A7480A190F8B933035494DD5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <3535_1645028520_620D24A8_3535_225_1_787AE7BB302AE849A7480A190F8B933035494EAE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <5efa6354-4396-d1b1-bec3-122d2aa148c2@joelhalpern.com> In-Reply-To: <5efa6354-4396-d1b1-bec3-122d2aa148c2@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-17T06:31:14Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=15096efe-dcb1-49ad-82e0-c36509479261; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2022 07:13:58 -0000 SGkgSm9lbCwgDQoNCj4gSWYgdGhlIE5TSCBwYXlsb2FkIGlzIGFuIElQIHBhY2tldCwgYW5kIHRo YXQgcGFja2V0IGlzIGFkZHJlc3NlZCB0bw0KPiBzb21ldGhpbmcgb3RoZXIgdGhhbiB0aGlzIG5v ZGUsIGFuZCB0aGF0IHBhY2tldCBpcyBjYXJyeWluZyAgYW4gSUNNUA0KPiBlY2hvLCBpcyB0aGF0 IGFuIFNGQyBPQU0gcGFja2V0IHJlcXVpcmluZyB0aGUgTy1iaXQgYmVpbmcgc2V0Pw0KDQpNZWQ6 IFRoZSBOU0ggY2FuIGJlIGFkZGVkIGJ5IGEgY2xhc3NpZmllciBvciBkaXJlY3RseSBieSBhbiBT RkMgT0FNIGNvbnRyb2xsZXIgdGhhdCBpc3N1ZXMgdGhlIHBhY2tldC4gSWYgdGhlIG9yaWdpbmFs IElQL0lDTVAgcGFja2V0IGlzIHJlY2VpdmVkIGJ5IGEgY2xhc3NpZmllciwgdGhlIGNsYXNzaWZp ZXIgbXVzdCBub3Qgc2V0IHRoZSBPIGJpdCBhcyBwZXIgZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0t cGFja2V0IGJlY2F1c2UgdGhhdCBwYWNrZXQgaXMgc2VlbiBhcyBkYXRhIHBhY2tldC4gDQoNCkxl dCdzIG5vdyBmb2N1cyBvbiB0aGUgU0ZDIE9BTSBjb250cm9sbGVyIGNhc2U6IA0KKiBEb2VzIGl0 IG1ha2VzIHNlbnNlIGZvciBhbiBTRkMgT0FNIGNvbnRyb2xsZXIgdG8gImxldmVyYWdlIiBJUC9J Q01QIGZvciBTRkMgT0FNIHB1cnBvc2VzIHdoaWxlIGl0IGNhbiBkbyBpdCBkaXJlY3RseSB1c2lu ZyBJQ01QICh3aXRob3V0IHRoZSBJUCBoZWFkZXIpPyANCg0KSSBwZXJzb25hbGx5IGRvbid0IHNl ZSBhbnkuIA0KDQoqIERvZXMgaXQgbWFrZXMgc2Vuc2UgZm9yIGFuIFNGQyBPQU0gY29udHJvbGxl ciB0byAic3VwcGx5IiBhbiBJUC9JQ01QIGFzIGFuIGlucHV0IGZvciBzcGVjaWZpYyBPQU0gcHVy cG9zZXM/ICANCg0KVGhpcyBpcyBpbiB0aGVvcnkgcG9zc2libGUgZm9yIFNGIHRlc3RpbmcgcHVy cG9zZXMgKGUuZy4sIHRlc3QgdGhlIGJlaGF2aW9yIG9mIGEgZmlyZXdhbGwgYWdhaW5zdCBzdWNo IHBhY2tldC4gVGhlIG91dHB1dCBvZiB0aGUgdGVzdCB3aWxsIGJlIHVzZWQgdG8gYXNzZXNzIGlm IHRoZSBGVyBjb25maWd1cmF0aW9uIGlzIE9LL05PSykuIEhvd2V2ZXIsIHN1Y2ggdGVzdCBPQU0g cGFja2V0cyBoYXZlIHRvIGJlIHVuYW1iaWd1b3VzbHkgaWRlbnRpZmllZCBhcyBzdWNoLiBUaGUg TmV4dCBQcm90b2NvbCB3b24ndCBiZSBzZXQgdG8gSVAgYnV0IHRvIHRoZSB2YWx1ZSBhc3NpZ25l ZCB0byBhbiBPQU0gcHJvdG9jb2wuICANCg0KICBBbmQNCj4gY29udmVyc2VseSwgaXMgYW4gU0ZG IHJlcXVpcmVkIHRvIGNoZWNrIGZvciB0aGF0IGNhc2UgaWYgaXQgc2VlcyBhbiBOU0gNCj4gd2l0 aCB0aGUgTy1iaXQgc2V0Pw0KDQpNZWQ6IFNGRnMgaGF2ZSB0byBzdXBwb3J0IHBvbGljaWVzIHdo ZXRoZXIgc29tZSBPQU0gbWVzc2FnZXMgY2FuIGJlIGZvcndhcmRlZCB0byBTRnMuIFRoZXNlIHBv bGljaWVzIG1heSBpbmNsdWRlIGEgZmlsdGVyIG9uIHZhbGlkIG5leHQgcHJvdG9jb2wgdmFsdWVz LiBJIGRvbid0IGhhdmUgYW4gb2JqZWN0aW9uIHRvIGRpc2NhcmQgYnkgZGVmYXVsdCBwYWNrZXRz IHdpdGggTyBiaXQgc2V0IGFuZCBuZXh0IHByb3RvY29sID0gSVAvTVBMUy9FdGhlcm5ldA0KDQpD aGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogSm9l bCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPiBFbnZvecOpwqA6IG1lcmNyZWRp IDE2IGbDqXZyaWVyIDIwMjIgMTc6MzANCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU5OT1Yv TkVUIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgR3JlZw0KPiBNaXJza3kgPGdyZWdp bWlyc2t5QGdtYWlsLmNvbT4NCj4gQ2PCoDogc2ZjQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBb c2ZjXSBUUjogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAwLnR4 dA0KPiANCj4gVGhhbmsgeW91IGZvciB3cml0aW5nIHRoaXMuICBJIGxvb2sgZm9yd2FyZCB0byBt b3JlIGRzY3Vzc2lvbiBieSBtb3JlIFdHDQo+IG1lbWJlcnMuDQo+IA0KPiBJIHdhbnQgdG8gYXNr IG9uZSBjbGFyaWZ5aW5nIHF1ZXNpdG9uIGFib3V0IGFuIGV4YW1wbGUgdGhhdCB3YXMgcmFpc2Vk DQo+IGVhcmxpZXIuDQo+IA0KPiBJZiB0aGUgTlNIIHBheWxvYWQgaXMgYW4gSVAgcGFja2V0LCBh bmQgdGhhdCBwYWNrZXQgaXMgYWRkcmVzc2VkIHRvDQo+IHNvbWV0aGluZyBvdGhlciB0aGFuIHRo aXMgbm9kZSwgYW5kIHRoYXQgcGFja2V0IGlzIGNhcnJ5aW5nICBhbiBJQ01QDQo+IGVjaG8sIGlz IHRoYXQgYW4gU0ZDIE9BTSBwYWNrZXQgcmVxdWlyaW5nIHRoZSBPLWJpdCBiZWluZyBzZXQ/ICBB bmQNCj4gY29udmVyc2VseSwgaXMgYW4gU0ZGIHJlcXVpcmVkIHRvIGNoZWNrIGZvciB0aGF0IGNh c2UgaWYgaXQgc2VlcyBhbiBOU0gNCj4gd2l0aCB0aGUgTy1iaXQgc2V0Pw0KPiANCj4gWW91cnMs DQo+IEpvZWwNCj4gDQo+IE9uIDIvMTYvMjAyMiAxMToyMSBBTSwgbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSB3cm90ZToNCj4gPiBSZS0sDQo+ID4NCj4gPiBUaGlzIGlzIGRldGVybWluZWQg YnkgdGhlIGVudGl0eSB0aGF0IGlzc3VlcyB0aGUgT0FNIHBhY2tldC4gVGhpcyBpcw0KPiA+IHR5 cGljYWxseSBhIGRlZGljYXRlZCBPQU0gY29udHJvbGxlciBvciBhbiBTRkMgZWxlbWVudCAoY2xh c3NpZmllciBmb3INCj4gPiB0aGUgaW9hbSBjYXNlLCBmb3IgZXhhbXBsZSkuDQo+ID4NCj4gPiBC VFcsIEkgdXBkYXRlZCB0aGUgZHJhZnQgdG8gcmVmbGVjdCB5b3VyIGNvbW1lbnRzIGFuZCBhbHNv IHRob3NlIGZyb20NCj4gPiBKaW06DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC0wMQ0KPiA+IDxodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAxPg0K PiA+DQo+ID4gQ2hlZXJzLA0KPiA+DQo+ID4gTWVkDQo+ID4NCj4gPiAqRGXCoDoqIEdyZWcgTWly c2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20+ICpFbnZvecOpwqA6KiBtZXJjcmVkaSAxNg0KPiA+ IGbDqXZyaWVyIDIwMjIgMTY6NTIgKsOAwqA6KiBCT1VDQURBSVIgTW9oYW1lZCBJTk5PVi9ORVQN Cj4gPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gKkNjwqA6KiBzZmNAaWV0Zi5vcmcg Kk9iamV0wqA6KiBSZTogW3NmY10NCj4gPiBUUjogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWly LXNmYy1vYW0tcGFja2V0LTAwLnR4dA0KPiA+DQo+ID4gSGkgTWVkLA0KPiA+DQo+ID4gdGhhbmsg eW91IGZvciB5b3VyIGV4cGVkaWVudMKgcmVzcG9uc2UuIEkgaGF2ZSBhIGZvbGxvdy11cCBxdWVz dGlvbjoNCj4gPg0KPiA+ICAgICBIb3cgZG9lcyBvbmUgZGV0ZXJtaW5lIHRoZSBuYXR1cmUsIE9B TSBvciBub3QtT0FNLCBvZiBkYXRhDQo+IGVsZW1lbnRzDQo+ID4gICAgIGluIHRoZSBOU0ggQ29u dGV4dCBoZWFkZXI/DQo+ID4NCj4gPiBBcyBJIHVuZGVyc3RhbmQgaXQsIGRyYWZ0LWlldGYtc2Zj LW5zaC10bHYgZG9lcyBub3QgcHJvdmlkZSB0aGF0LiBEbw0KPiA+IHdlIG5lZWQgdG8gYWRkIGl0 PyBBcHByZWNpYXRlIHlvdXIgdGhvdWdodHMgb24gdGhhdC4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ ID4NCj4gPiBHcmVnDQo+ID4NCj4gPiBPbiBXZWQsIEZlYiAxNiwgMjAyMiBhdCA3OjMwIEFNIDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+ID4NCj4gPiAgICAgSGkgR3JlZywNCj4gPg0KPiA+ICAg ICBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+ICAgICBDaGVlcnMsDQo+ID4NCj4gPiAgICAg TWVkDQo+ID4NCj4gPiAgICAgKkRlwqA6KiBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwu Y29tDQo+ID4gICAgIDxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4NCj4gPiAgICAgKkVu dm95w6nCoDoqIG1lcmNyZWRpIDE2IGbDqXZyaWVyIDIwMjIgMTY6MTMNCj4gPiAgICAgKsOAwqA6 KiBCT1VDQURBSVIgTW9oYW1lZCBJTk5PVi9ORVQgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20NCj4gPiAgICAgPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4NCj4gPiAg ICAgKkNjwqA6KiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4gICAgICpP YmpldMKgOiogUmU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOg0KPiA+ICAgICBkcmFmdC1ib3VjYWRh aXItc2ZjLW9hbS1wYWNrZXQtMDAudHh0DQo+ID4NCj4gPiAgICAgSGkgTWVkLA0KPiA+DQo+ID4g ICAgIG1hbnkgdGhhbmtzIGZvciB0YWtpbmcgdGhlIGxlYWQgYW5kIHB1dHRpbmcgdGhlIHByb3Bv c2FsIG9uIHRoZQ0KPiB0YWJsZS4NCj4gPg0KPiA+ICAgICBJIGhhdmUgYSBxdWVzdGlvbiBvbiB0 aGUgcHJvcG9zZWQgbmV3IHRleHQgZm9yIHRoZSBPIGJpdCBhbmQgaXRzDQo+ID4gICAgIHBvc3Np YmxlIGVmZmVjdCBvbiBJT0FNOg0KPiA+DQo+ID4gICAgICDCoCDCoE8gYml0OsKgIFNldHRpbmcg dGhpcyBiaXQgaW5kaWNhdGVzIGFuIFNGQyBPQU0gcGFja2V0LsKgIFN1Y2ggYQ0KPiA+IHBhY2tl dA0KPiA+DQo+ID4gICAgICDCoCDCoCDCoCBpcyBhbnkgTlNILWVuY2FwYXN1bGF0ZWQgcGFja2V0 IHRoYXQgZXhjbHVzaXZlbHkgaW5jbHVkZXMNCj4gPiBhbiBPQU0NCj4gPg0KPiA+ICAgICAgwqAg wqAgwqAgY29tbWFuZCBhbmQvb3IgT0FNIGRhdGEuDQo+ID4NCj4gPiAgICAgTXkgdW5kZXJzdGFu ZGluZyBvZiB0aGUgbmV3IGRlZmluaXRpb24gb2YgdGhlIE8gYml0IGlzIHRoYXQgdGhlDQo+IE5T SA0KPiA+ICAgICBpbmNsdWRlcyBhbmQvb3IgZW5jYXBzdWxhdGVzIG9ubHkgT0FNIGNvbW1hbmQg YW5kL29yIGRhdGEuIElPQU0sDQo+IGFzDQo+ID4gICAgIEkgdW5kZXJzdGFuZCBpdHMgYXBwbGlj YXRpb24gaW4gTlNILCBtYXkgZm9sbG93IHRoZSBOU0ggYW5kIGhhdmUNCj4gPiAgICAgdXNlciBw YXlsb2FkIGFmdGVyIHRoZSBJT0FNIGRhdGEuDQo+ID4NCj4gPiAgICAgKi8vKg0KPiA+DQo+ID4g ICAgICovW01lZF0gUGFja2V0cyB0aGF0IGluY2x1ZGUgYWxzbyB1c2VyIGRhdGEgYXJlIG5vdCBj b25zaWRlcmVkIGFzDQo+ID4gICAgIOKAnE9BTSBwYWNrZXRz4oCdIGFzIHBlciB0aGUgbmV3IGRl ZmluaXRpb24uLyoNCj4gPg0KPiA+ICAgICBBbmQgYW5vdGhlciBzY2VuYXJpbywgaWYgRmxvdyBJ RCBUTFYgaXMgdXNlZCB0byBpbmZsdWVuY2UgdXNlcg0KPiBkYXRhDQo+ID4gICAgIHRocm91Z2gg U0ZQLCBPQU0gd2lsbCBhcHBseSB0aGUgc2FtZSBGbG93IElEIHZhbHVlLiBXb3VsZCBzdWNoDQo+ ID4gICAgIHBhY2tldCBzdGlsbCBiZSBjb25zaWRlcmVkIGFzICJleGNsdXNpdmVseSBpbmNsdWRl cyBPQU0gY29tbWFuZA0KPiA+ICAgICBhbmQvb3IgZGF0YSI/DQo+ID4NCj4gPiAgICAgKi8vKg0K PiA+DQo+ID4gICAgICovW01lZF0gWWVzLCB0aGV5IGFyZS4gRmxvdyBpZCBpcyBqdXN0IGEgY29u c3RyYWludCwgaWYgeW91IHdpbGwsDQo+ID4gICAgIHRoYXQgaXMgdXNlZCB0byBpbmZsdWVuY2Ug aG93IE9BTSBjb21tYW5kcyB3aWxsIGJlIGV4ZWN1dGVkLiAvKg0KPiA+DQo+ID4gICAgIFJlZ2Fy ZHMsDQo+ID4NCj4gPiAgICAgR3JlZw0KPiA+DQo+ID4gICAgIE9uIFdlZCwgRmViIDE2LCAyMDIy IGF0IDY6NDAgQU0gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiAgICAgPG1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+ID4NCj4gPiAgICAgICAg IEhpIGFsbCwNCj4gPg0KPiA+ICAgICAgICAgQSBwcm9wb3NhbCB0byBjbGFyaWZ5IHRoZSBpbnRl bnQgb2YgU0ZDIE9BTSBwYWNrZXQuIENvbW1lbnRzDQo+IGFyZQ0KPiA+ICAgICAgICAgd2VsY29t ZS4NCj4gPg0KPiA+ICAgICAgICAgQ2hlZXJzLA0KPiA+ICAgICAgICAgTWVkDQo+ID4NCj4gPiAg ICAgICAgIC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ICAgICAgICAgRGXCoDogSS1E LUFubm91bmNlIDxpLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZw0KPiA+ICAgICAgICAgPG1h aWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZz4+IERlIGxhIHBhcnQgZGUNCj4gPiAg ICAgICAgIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8bWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz4NCj4gPiAgICAgICAgIEVudm95w6nCoDogbWVyY3JlZGkgMTYgZsOpdnJpZXIgMjAy MiAxNTozOA0KPiA+ICAgICAgICAgw4DCoDogaS1kLWFubm91bmNlQGlldGYub3JnIDxtYWlsdG86 aS1kLWFubm91bmNlQGlldGYub3JnPg0KPiA+ICAgICAgICAgT2JqZXTCoDogSS1EIEFjdGlvbjog ZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAwLnR4dA0KPiA+DQo+ID4NCj4gPiAgICAg ICAgIEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lDQo+ ID4gICAgICAgICBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ID4NCj4gPg0KPiA+ICAg ICAgICAgIMKgIMKgIMKgIMKgIFRpdGxlwqAgwqAgwqAgwqAgwqAgwqA6IENsYXJpZnlpbmcgQW1i aWd1aXR5IHJlbGF0ZWQgdG8NCj4gPiAgICAgICAgIE5ldHdvcmsgU2VydmljZSBIZWFkZXIgKE5T SCkgT0FNIFBhY2tldA0KPiA+ICAgICAgICAgIMKgIMKgIMKgIMKgIEF1dGhvcsKgIMKgIMKgIMKg IMKgIDogTW9oYW1lZCBCb3VjYWRhaXINCj4gPiAgICAgICAgICDCoCDCoCDCoCDCoCBGaWxlbmFt ZcKgIMKgIMKgIMKgIDogZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LQ0KPiAwMC50eHQN Cj4gPiAgICAgICAgICDCoCDCoCDCoCDCoCBQYWdlc8KgIMKgIMKgIMKgIMKgIMKgOiA1DQo+ID4g ICAgICAgICAgwqAgwqAgwqAgwqAgRGF0ZcKgIMKgIMKgIMKgIMKgIMKgIDogMjAyMi0wMi0xNg0K PiA+DQo+ID4gICAgICAgICBBYnN0cmFjdDoNCj4gPiAgICAgICAgICDCoCDCoFRoaXMgZG9jdW1l bnQgY2xhcmlmaWVzIGFuIGFtYmlndWl0eSBpbiB0aGUgTmV0d29yaw0KPiBTZXJ2aWNlDQo+ID4g ICAgICAgICBIZWFkZXINCj4gPiAgICAgICAgICDCoCDCoChOU0gpIHNwZWNpZmljYXRpb24gcmVs YXRlZCB0byB0aGUgaGFuZGxpbmcgb2YgTy1iaXQuwqAgSW4NCj4gPiAgICAgICAgIHBhcnRpY3Vs YXIsDQo+ID4gICAgICAgICAgwqAgwqB0aGlzIGRvY3VtZW50IGNsYXJpZmllcyB0aGUgbWVhbmlu ZyBvZiAiT0FNIHBhY2tldCIuDQo+ID4NCj4gPiAgICAgICAgICDCoCDCoFRoaXMgZG9jdW1lbnQg dXBkYXRlcyBSRkM4MzAwLg0KPiA+DQo+ID4NCj4gPiAgICAgICAgIFRoZSBJRVRGIGRhdGF0cmFj a2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tDQo+IHBhY2tl dC8NCj4gPg0KPiA+IDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3Vj YWRhaXItc2ZjLW9hbS1wYWNrZXQvPg0KPiA+DQo+ID4gICAgICAgICBUaGVyZSBpcyBhbHNvIGFu IGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiA+ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ib3VjYWRhaXItc2ZjLW9hbS0NCj4gcGFj a2V0LTAwDQo+ID4NCj4gPiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQtDQo+ID4gMDA+DQo+ID4NCj4gPg0KPiA+ICAg ICAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSByc3luYyBhdA0KPiA+ ICAgICAgICAgcnN5bmMuaWV0Zi5vcmc6OmludGVybmV0LWRyYWZ0cw0KPiA+DQo+ID4NCj4gPiAg ICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gICAgICAgICBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+ID4gICAgICAgICBJLUQtQW5u b3VuY2VAaWV0Zi5vcmcgPG1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmc+DQo+ID4gICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPiA+ ICAgICAgICAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91 bmNlPg0KPiA+ICAgICAgICAgSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cu aWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gPiAgICAgICAgIDxodHRwOi8vd3d3LmlldGYub3JnL3No YWRvdy5odG1sPiBvcg0KPiA+ICAgICAgICAgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRv dy1zaXRlcy50eHQNCj4gPiAgICAgICAgIDxmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93 LXNpdGVzLnR4dD4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+DQo+ID4gICAgICAg ICBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcw0K PiA+ICAgICAgICAgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudA0KPiBkb25jDQo+ID4gICAgICAgICBwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kNCj4gPiAgICAgICAgIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4g PiAgICAgICAgIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuDQo+IExlcw0KPiA+ICAgICAgICAgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPiA+ICAgICAgICAgT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZQ0KPiBhbHRlcmUsDQo+ ID4gICAgICAgICBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4gPg0KPiA+ICAgICAgICAg VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yDQo+ID4gICAgICAgICBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7DQo+ID4gICAgICAgICB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQNCj4gPiAgICAgICAgIGF1dGhvcmlzYXRpb24uDQo+ID4g ICAgICAgICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZQ0KPiA+ICAgICAgICAgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQo+ID4gICAgICAgICBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcw0KPiB0aGF0DQo+ID4gICAgICAgICBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+ICAgICAgICAgVGhh bmsgeW91Lg0KPiA+DQo+ID4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ICAgICAgICAgc2ZjIG1haWxpbmcgbGlzdA0KPiA+ICAgICAg ICAgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+ICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPiAgICAgICAgIDxodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYz4NCj4gPg0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+DQo+ID4gICAgIENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiA+IGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+ID4NCj4gPiAgICAgcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMNCj4g PiBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0K PiA+DQo+ID4gICAgIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcw0KPiA+IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gPg0KPiA+ICAgICBPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwNCj4gZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuDQo+ID4NCj4gPiAgICAgVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yDQo+ID4gcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPiA+DQo+ID4gICAgIHRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dA0KPiBhdXRo b3Jpc2F0aW9uLg0KPiA+DQo+ID4gICAgIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+DQo+ID4gICAgIEFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQNCj4gaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gPg0KPiA+ICAgICBUaGFuayB5 b3UuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPiBDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gPiBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBk aWZmdXNlcywNCj4gPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlDQo+ID4gcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kNCj4gcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz DQo+IGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg Y2UgbWVzc2FnZSBhIGV0ZQ0KPiBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0K PiA+DQo+ID4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yDQo+ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QNCj4gYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kDQo+IGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gPiBBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUNCj4g YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+ID4gVGhhbmsgeW91Lg0KPiA+ DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+IHNmYyBtYWlsaW5nIGxpc3QNCj4gPiBzZmNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Tue Feb 22 23:26:14 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5263A0D3C; Tue, 22 Feb 2022 23:25:30 -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, CTE_8BIT_MISMATCH=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Jq77OYGU8kgm; Tue, 22 Feb 2022 23:25:25 -0800 (PST) Received: from mxde.zte.com.cn (mxde.zte.com.cn [209.9.37.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A023A0D58; Tue, 22 Feb 2022 23:25:23 -0800 (PST) Received: from mse-eu.zte.com.cn (unknown [10.35.13.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxde.zte.com.cn (FangMail) with ESMTPS id 4K3SHB4VjHzB5LR7; Wed, 23 Feb 2022 15:25:10 +0800 (CST) Received: from dgapp01.zte.com.cn ([10.35.13.16]) by mse-eu.zte.com.cn with SMTP id 21N7P2gL096792; Wed, 23 Feb 2022 15:25:02 +0800 (GMT-8) (envelope-from wei.yuehua@zte.com.cn) Received: from mapi (dgapp02[null]) by mapi (Zmail) with MAPI id mid1; Wed, 23 Feb 2022 15:25:04 +0800 (CST) Date: Wed, 23 Feb 2022 15:25:04 +0800 (CST) X-Zmail-TransId: 2afa6215e1506e762388 X-Mailer: Zmail v1.0 Message-ID: <202202231525042357307@zte.com.cn> In-Reply-To: References: 163818356894.9882.14504113673742570287@ietfa.amsl.com, f511d5ec-a840-52bc-ec9a-da8b54403781@nokia.com, 202201261014495204767@zte.com.cn, HE1PR07MB42178E476E313EC8FA66E20098309@HE1PR07MB4217.eurprd07.prod.outlook.com Mime-Version: 1.0 From: To: Cc: , , , , , Content-Type: text/plain; charset="UTF-8" X-MAIL: mse-eu.zte.com.cn 21N7P2gL096792 X-Fangmail-Gw-Spam-Type: 0 X-FangMail-Miltered: at 10-35-8-63 with ID 6215E156.000 by FangMail milter! X-FangMail-Envelope: 1645601110/4K3SHB4VjHzB5LR7/6215E156.000/10.35.13.51/[10.35.13.51]/mse-eu.zte.com.cn/ X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 6215E156.000/4K3SHB4VjHzB5LR7 Archived-At: Subject: Re: [sfc] =?utf-8?q?Francesca_Palombini=27s_Discuss_on_draft-ietf-sf?= =?utf-8?q?c-nsh-tlv-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2022 07:25:31 -0000 Dear Francesca, Thank you for providing detailed opinions and references. How about adding some text like the following ： “The Tenant ID is assumed to be generated and assigned by an orchestration system, which would allow for interoperability. The specifics of that orchestration system assignment are outside the scope of this document.” Best Regards, 魏月华 Yuehua Wei 承载网标准预研-项目经理/Lead of Bearer Network Standards Development Project 架构团队/有线规划部/有线产品经营部/Architecture Team/Wireline Product Planning Dept/Wireline Product Operation ZTE Corporation 南京市软件大道50号/No.50, Software Avenue, Nanjing, 210012, P. R. China M: +86 13851460269 E: wei.yuehua@zte.com.cn ------------------原始邮件------------------ 发件人：FrancescaPalombini 收件人：魏月华00019655;martin.vigoureux@nokia.com; 抄送人：draft-ietf-sfc-nsh-tlv@ietf.org;sfc-chairs@ietf.org;iesg@ietf.org;sfc@ietf.org;gregimirsky@gmail.com; 日 期 ：2022年02月11日 21:33 主 题 ：Re: [sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT) _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc Hi Yuehua, Thanks for your update! It addresses almost all my comments. I still have the same problem with the following unchanged text: Tenant ID: Represents an opaque value pointing to Orchestration system-generated tenant identifier. The structure and semantics of this field are deployment specific. The question being how can this field be interoperable if the structure and semantics is deployment specific. This was discussed during the telechat (minutes here: https://www6.ietf.org/iesg/minutes/2021/narrative-minutes-2021-12-02.txt ), and Ben was great at putting into words my concern: Ben: If it's going to be the byte string that is just configured everywhere and you just check if it matches or doesn't match, that's pretty straightforward and that is probably going to be interoperable. I think you can get some interoperability issues if it's a value that may or may not be configured as opaque to the NSH implementation but then it has to be processed in some way by the recipients, as the software implementation on the recipient is only going to implement support for some fixed set of formats. If that implementation picks one set of formats and another implementation picks a different set of formats, there may not be any overlap so you may not be able to actually interoperate in terms of the contents of that field. That's a little far removed from the NSH protocol itself but there is perhaps still some interoperability concern to be worried about there, depending on how this value is expected to be processed by the recipient. I was hoping some text could be added about configuration, and why this should not be a problem in the use cases of this document. Basically some more details about what Martin says: The point is really that both the classifier that we insert to that metadata and possibly some virtual network function that will process it, be configured the same. This in my opinion is not clear enough in the document as is. It could be clarified ither in the “Tenant ID” definition or in a separate paragraph. I’ll update the DISCUSS to reflect this comment. Thank you, Francesca From: wei.yuehua@zte.com.cn Date: Wednesday, 26 January 2022 at 03:15 To: martin.vigoureux@nokia.com , Francesca Palombini Cc: iesg@ietf.org , draft-ietf-sfc-nsh-tlv@ietf.org , sfc-chairs@ietf.org , sfc@ietf.org , gregimirsky@gmail.com Subject: Re:[sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT) Dear Martin and Francesca, Combine with your comments and suggestions, I uploaded a ver12 to reflected the updates. I appreciate your further review. The link of differences is : https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt Best Regards, Yuehua Wei M: +86 13851460269 E: wei.yuehua@zte.com.cn ------------------原始邮件------------------ 发件人：MartinVigoureux 收件人：Francesca Palombini;The IESG; 抄送人：draft-ietf-sfc-nsh-tlv@ietf.org;sfc-chairs@ietf.org;sfc@ietf.org;gregimirsky@gmail.com; 日 期 ：2021年12月02日 20:31 主 题 ：Re: [sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT) Hello Francesca, thank you for your review. Please see inline. I invite the authors to share their views. -m Le 2021-11-29 à 11:59, Francesca Palombini via Datatracker a écrit : > Francesca Palombini has entered the following ballot position for > draft-ietf-sfc-nsh-tlv-09: 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-sfc-nsh-tlv/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the work on this document. > > I have some comments, mostly having to do with clarifications and improvement > of text for readability. I'd like answers to two main points: first - I believe > the lack of normative references to the documents that define the fields this > document registers into IANA is important enough to warrant some discussion. Not sure whether you are asking for Normative references in 4.1 or in 4.2 to 4.6, or both. I'm not sure Normative references would be appropriate for the metadata objects (from 4.2 to 4.6) this document defines. All of them are opaque, and under the control of the operator. Informative references (like in 4.6) would be a plus though. I'm sure the authors can add Normative references to 4.1 too. > Second - I'd like some clarification about interoperability. More details below. It would be great if you could elaborate a bit on the interoperability issues you foresee. Personally, I can envisage misconfiguration driven problems, but not interop ones. > > Francesca > > 1. ----- > > Tenant ID: Represents an opaque value pointing to Orchestration > system-generated tenant identifier. The structure and semantics > of this field are deployment specific. > > FP: I am worried about interoperability, as the field is defined as deployment > specific. Could you clarify why you don't think this is an issue? Also, please > add a normative reference to the section and document defining tenant > identification. > > 2. ---- > > Section 4.3 > > FP: Same comment as above for Node ID: please add a reference and explain > interoperability, as this is defined as deployment specific. > > 3. ----- > > Sections 4.4, 4.5 > > FP: I do think these fields need references to the documents they are defined > in. (I am aware section 2.1 and the normative references should help, but I > think it would be much clearer to have direct links to the right place in the > text.) For Flow ID, if I understand correctly, this document defines it high > level and gives examples of what value it can take. I would clarify that in the > first paragraph of the section (as you do for Section 4.6), instead of having > the references only in the "Length" paragraph. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 4. ----- > > Section 4.1 > > FP: I think it would be better to have the sentence "Reserved bits MUST be sent > as zero and ignored on receipt." only once, rather than repeat for each > context. What is missing instead is the number of bits that are reserved for > each CT. I know that it can be extracted from the figure or from the value of > the Forwarding Context field, but I believe figures should be complemented by > clear written text. Additionally, to improve readability, references should be > added for the forwarding context where they are missing: VLAN identifier, MPLS > VPN label‚ VNI. > > > > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Feb 23 16:23:01 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942A63A11E6 for ; Wed, 23 Feb 2022 16:22:59 -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 wCJ74ADowZ1S for ; Wed, 23 Feb 2022 16:22:55 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8553A07C0 for ; Wed, 23 Feb 2022 16:22:55 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id i11so622472eda.9 for ; Wed, 23 Feb 2022 16:22:55 -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=9dMJzIcZGBMYLwWHgsPHAczkwlsW6LvWpP7ECwszdy0=; b=JHQMts9UjH+Y1dudSHXWW5g6W9r/CY8xG1yA4ARnFL5kIvvKWjLlovCWvZYzUxj6n/ tEBk7C9THzei64GLeIomYiB2VuTNBGvQzstckHjrdpx7psZeVJUlzS4VKFqdLehCefH5 bc88+4qS25Ot0cCAhoMFcS1V3E3IoyKqwKH2+FcgC3zUnPFYtl3cwXk6YqnQ/xBfCtEy DhHTB9jerXkQ7GnFbqOJuPmqvSOXpYzsjhcKt18KXfoFZxYCZCMQktSEyoSG4YziR9l5 Mt6Sv71KlLD+OS0yGj9p4syk9knUQl9fz33jjaBMHafivbQjbV5oy4/idENRq7NwF1gE m2Vw== 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=9dMJzIcZGBMYLwWHgsPHAczkwlsW6LvWpP7ECwszdy0=; b=GkYTUfVfcAzw9ZnfW5osFrSn0xEErViJaaV419ynTTJobckdNGG3tzBHURvbIShVGg V9oGrbDiA/ktdomi25AxnTE0M4kMQoPdAjrHBr2yJBzKAVYpIx+EAHEgpxpTFwsziyWp GgqQToxlraKQkReWERUi+FplJ+5J9Va84E3taPFnd5QWt2h5/5sgHCkl4XTDiIsf1y+X lqtx70SHblbVMHvNEXZ8naKTAp+4APpt8Ws8O5oMEoeLItTb/bsyW4ymOgtDool506oX XQgelUHhZwBNqjY3BoLgaTU1OkfKUJvSrmPZpaG9snL2IO5guQpAFjsZE8Q4zM8qabs5 upFg== X-Gm-Message-State: AOAM533Pm3zfpTL7f9/iw0O2zSb9jkUPd/G9f83op4HolJLLeNihLuCe 3Fxvg4WQJBXS0lRk/JV4Gv3+SlFtUa+D8rM7rqMQQrfB X-Google-Smtp-Source: ABdhPJxAqWjlSV8ym2H4omJD4lTvd9SYz45Wjy4f0BJJrns9ygUl81SHIDao8titwhsHKCtGb18Phix6Bp8sCuvPLuA= X-Received: by 2002:a05:6402:d7:b0:413:673:ba2f with SMTP id i23-20020a05640200d700b004130673ba2fmr69001edu.29.1645662173299; Wed, 23 Feb 2022 16:22:53 -0800 (PST) MIME-Version: 1.0 References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Greg Mirsky Date: Wed, 23 Feb 2022 16:22:42 -0800 Message-ID: To: Med Boucadair Cc: "sfc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000042894b05d8b8959b" Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 00:23:00 -0000 --00000000000042894b05d8b8959b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, thank you for your proposal. I believe that it solves the problem and helps the Active SFC OAM. If I may, I'm proposing the WG Chairs consider the WG AP on this document. And for the record: I've read the document and support its adoption by the SFC WG. Regards, Greg On Wed, Feb 16, 2022 at 6:40 AM wrote: > Hi all, > > A proposal to clarify the intent of SFC OAM packet. Comments are welcome. > > Cheers, > Med > > -----Message d'origine----- > De : I-D-Announce De la part de > internet-drafts@ietf.org > Envoy=C3=A9 : mercredi 16 f=C3=A9vrier 2022 15:38 > =C3=80 : i-d-announce@ietf.org > Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Clarifying Ambiguity related to Network Service > Header (NSH) OAM Packet > Author : Mohamed Boucadair > Filename : draft-boucadair-sfc-oam-packet-00.txt > Pages : 5 > Date : 2022-02-16 > > Abstract: > This document clarifies an ambiguity in the Network Service Header > (NSH) specification related to the handling of O-bit. In particular, > this document clarifies the meaning of "OAM packet". > > This document updates RFC8300. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam-packet/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-packet-00 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > _______________________________________________ > 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.ietf.org/ietf/1shadow-sites.txt > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --00000000000042894b05d8b8959b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Med,
thank you for your proposal. I believe that it= solves=C2=A0the problem and helps the Active SFC OAM. If I may, I'm pr= oposing the WG Chairs consider the WG AP on this document. And for the reco= rd:
I've read the document and support its adoption by the SFC WG.
=

Regards,
Greg

On Wed, Feb 1= 6, 2022 at 6:40 AM <moha= med.boucadair@orange.com> wrote:
Hi all,

A proposal to clarify the intent of SFC OAM packet. Comments are welcome.
Cheers,
Med

-----Message d'origine-----
De=C2=A0: I-D-Announce <i-d-announce-bounces@ietf.org> De la part de internet-drafts@i= etf.org
Envoy=C3=A9=C2=A0: mercredi 16 f=C3=A9vrier 2022 15:38
=C3=80=C2=A0: i-= d-announce@ietf.org
Objet=C2=A0: I-D Action: draft-boucadair-sfc-oam-packet-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Clarifying Ambiguity related to Network Service Header (NSH) OAM Packet =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Moha= med Boucadair
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-bou= cadair-sfc-oam-packet-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2022-02-16

Abstract:
=C2=A0 =C2=A0This document clarifies an ambiguity in the Network Service He= ader
=C2=A0 =C2=A0(NSH) specification related to the handling of O-bit.=C2=A0 In= particular,
=C2=A0 =C2=A0this document clarifies the meaning of "OAM packet".=

=C2=A0 =C2=A0This document updates RFC8300.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-boucadair-sfc-oam-packet/

There is also an htmlized version available at:
https://datatracker.ietf.org/= doc/html/draft-boucadair-sfc-oam-packet-00


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


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___________________________________________________________________________= ______________________________________________

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.

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--00000000000042894b05d8b8959b-- From nobody Wed Feb 23 23:56:15 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF533A0970 for ; Wed, 23 Feb 2022 23:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 L-hPMcRbdb_V for ; Wed, 23 Feb 2022 23:56:07 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 93B043A0965 for ; Wed, 23 Feb 2022 23:56:07 -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 opfednr24.francetelecom.fr (ESMTP service) with ESMTPS id 4K44wP45Hdz1xx7; Thu, 24 Feb 2022 08:56:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645689365; bh=cbY7vev/1F9qCRU2j2ZxktrMu06gWIywBM36T1WKvTo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=GEPw6XPQaEDCRbbUgJuDil+fjxoK4oItIXoFzUTnLCx1FqDTRx8cmSg4PI7K5Odwm Pa2n1qxouoky7yeVKh63n0yIt5aS82g2ZO8TlUuStlRmST2xk8wtG5/o3tScuOlsFJ N1ddXNOik0ATLm9Ze6gs1bY3Giq34J3jnMW9OvUS0JWwpgdsNIgYm7uO9S+Bqzpb65 GMKJbwcNs2XAv6SbfxkPd2G1OhgFZaL3WGTDeOwwCM/7EhkboWAZCGJSd6+Vp22YYO QT4fK/eJOa2XYmhOkEbbb7ori2GC9PI58N8e6OXC2Zs/51QMqA72D7vfB4F27XMwFS +NwhzsTobqwtw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr03.francetelecom.fr (ESMTP service) with ESMTPS id 4K44wP3GZKzDq7T; Thu, 24 Feb 2022 08:56:05 +0100 (CET) From: To: "Joel M. Halpern" , Greg Mirsky CC: "sfc@ietf.org" Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt Thread-Index: AQHYI0LOqTeC5k5EYkSp4mi5aRUmyqyWXkqZgADrEJCACxeW4A== Content-Class: Date: Thu, 24 Feb 2022 07:56:04 +0000 Message-ID: <16224_1645689365_62173A15_16224_31_1_787AE7BB302AE849A7480A190F8B933035498F45@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <30956_1645025435_620D189B_30956_353_1_787AE7BB302AE849A7480A190F8B933035494DD5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <3535_1645028520_620D24A8_3535_225_1_787AE7BB302AE849A7480A190F8B933035494EAE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <5efa6354-4396-d1b1-bec3-122d2aa148c2@joelhalpern.com> <26440_1645082031_620DF5AF_26440_39_1_787AE7BB302AE849A7480A190F8B9330354954F7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <26440_1645082031_620DF5AF_26440_39_1_787AE7BB302AE849A7480A190F8B9330354954F7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-24T07:55:18Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=fb9dd995-229c-48e1-8991-46cef9715b20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 07:56:13 -0000 SGkgSm9lbCwgYWxsLCANCg0KRldJVywgSSB1cGRhdGVkIC0wMiB3aXRoIHRoZSBmb2xsb3dpbmcg dG8gcmVmbGVjdCBvbmUgb2YgdGhlIHBvaW50cyBkaXNjdXNzZWQgYmVsb3c6DQoNCiAgICAgIFdo ZW4gYW4gT0FNIGRhdGEgaXMgaW5jbHVkZWQgaW4gdGhlIGlubmVyIHBhY2tldCwgdGhlIE5leHQN CiAgICAgIFByb3RvY29sIGZpZWxkIGlzIHNldCB0byByZWZsZWN0IHRoZSBzdHJ1Y3R1cmUgb2Yg dGhhdCBpbm5lcg0KICAgICAgcGFja2V0LiAgQnkgZGVmYXVsdCwgU0ZGcyBTSE9VTEQgZGlzY2Fy ZCBOU0ggcGFja2V0cyB3aXRoIE8gYml0DQogICAgICBzZXQgYW5kIE5leHQgUHJvdG9jb2wgc2V0 IHRvIDB4MSAoSVB2NCksIDB4MiAoSVB2NiksIDB4MyAoTVBMUyksDQogICAgICBvciAweDUgKEV0 aGVybmV0KS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+IERlwqA6IHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+IERlIGxhIHBhcnQgZGUNCj4gbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiBFbnZvecOpwqA6IGpldWRpIDE3IGbDqXZyaWVy IDIwMjIgMDg6MTQNCj4gw4DCoDogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29t PjsgR3JlZyBNaXJza3kNCj4gPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4NCj4gQ2PCoDogc2ZjQGll dGYub3JnDQo+IE9iamV0wqA6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2Fk YWlyLXNmYy1vYW0tcGFja2V0LTAwLnR4dA0KPiANCj4gSGkgSm9lbCwNCj4gDQo+ID4gSWYgdGhl IE5TSCBwYXlsb2FkIGlzIGFuIElQIHBhY2tldCwgYW5kIHRoYXQgcGFja2V0IGlzIGFkZHJlc3Nl ZCB0bw0KPiA+IHNvbWV0aGluZyBvdGhlciB0aGFuIHRoaXMgbm9kZSwgYW5kIHRoYXQgcGFja2V0 IGlzIGNhcnJ5aW5nICBhbiBJQ01QDQo+ID4gZWNobywgaXMgdGhhdCBhbiBTRkMgT0FNIHBhY2tl dCByZXF1aXJpbmcgdGhlIE8tYml0IGJlaW5nIHNldD8NCj4gDQo+IE1lZDogVGhlIE5TSCBjYW4g YmUgYWRkZWQgYnkgYSBjbGFzc2lmaWVyIG9yIGRpcmVjdGx5IGJ5IGFuIFNGQyBPQU0NCj4gY29u dHJvbGxlciB0aGF0IGlzc3VlcyB0aGUgcGFja2V0LiBJZiB0aGUgb3JpZ2luYWwgSVAvSUNNUCBw YWNrZXQgaXMNCj4gcmVjZWl2ZWQgYnkgYSBjbGFzc2lmaWVyLCB0aGUgY2xhc3NpZmllciBtdXN0 IG5vdCBzZXQgdGhlIE8gYml0IGFzIHBlcg0KPiBkcmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNr ZXQgYmVjYXVzZSB0aGF0IHBhY2tldCBpcyBzZWVuIGFzIGRhdGENCj4gcGFja2V0Lg0KPiANCj4g TGV0J3Mgbm93IGZvY3VzIG9uIHRoZSBTRkMgT0FNIGNvbnRyb2xsZXIgY2FzZToNCj4gKiBEb2Vz IGl0IG1ha2VzIHNlbnNlIGZvciBhbiBTRkMgT0FNIGNvbnRyb2xsZXIgdG8gImxldmVyYWdlIiBJ UC9JQ01QDQo+IGZvciBTRkMgT0FNIHB1cnBvc2VzIHdoaWxlIGl0IGNhbiBkbyBpdCBkaXJlY3Rs eSB1c2luZyBJQ01QICh3aXRob3V0IHRoZQ0KPiBJUCBoZWFkZXIpPw0KPiANCj4gSSBwZXJzb25h bGx5IGRvbid0IHNlZSBhbnkuDQo+IA0KPiAqIERvZXMgaXQgbWFrZXMgc2Vuc2UgZm9yIGFuIFNG QyBPQU0gY29udHJvbGxlciB0byAic3VwcGx5IiBhbiBJUC9JQ01QDQo+IGFzIGFuIGlucHV0IGZv ciBzcGVjaWZpYyBPQU0gcHVycG9zZXM/DQo+IA0KPiBUaGlzIGlzIGluIHRoZW9yeSBwb3NzaWJs ZSBmb3IgU0YgdGVzdGluZyBwdXJwb3NlcyAoZS5nLiwgdGVzdCB0aGUNCj4gYmVoYXZpb3Igb2Yg YSBmaXJld2FsbCBhZ2FpbnN0IHN1Y2ggcGFja2V0LiBUaGUgb3V0cHV0IG9mIHRoZSB0ZXN0IHdp bGwNCj4gYmUgdXNlZCB0byBhc3Nlc3MgaWYgdGhlIEZXIGNvbmZpZ3VyYXRpb24gaXMgT0svTk9L KS4gSG93ZXZlciwgc3VjaCB0ZXN0DQo+IE9BTSBwYWNrZXRzIGhhdmUgdG8gYmUgdW5hbWJpZ3Vv dXNseSBpZGVudGlmaWVkIGFzIHN1Y2guIFRoZSBOZXh0DQo+IFByb3RvY29sIHdvbid0IGJlIHNl dCB0byBJUCBidXQgdG8gdGhlIHZhbHVlIGFzc2lnbmVkIHRvIGFuIE9BTQ0KPiBwcm90b2NvbC4N Cj4gDQo+ICAgQW5kDQo+ID4gY29udmVyc2VseSwgaXMgYW4gU0ZGIHJlcXVpcmVkIHRvIGNoZWNr IGZvciB0aGF0IGNhc2UgaWYgaXQgc2VlcyBhbg0KPiA+IE5TSCB3aXRoIHRoZSBPLWJpdCBzZXQ/ DQo+IA0KPiBNZWQ6IFNGRnMgaGF2ZSB0byBzdXBwb3J0IHBvbGljaWVzIHdoZXRoZXIgc29tZSBP QU0gbWVzc2FnZXMgY2FuIGJlDQo+IGZvcndhcmRlZCB0byBTRnMuIFRoZXNlIHBvbGljaWVzIG1h eSBpbmNsdWRlIGEgZmlsdGVyIG9uIHZhbGlkIG5leHQNCj4gcHJvdG9jb2wgdmFsdWVzLiBJIGRv bid0IGhhdmUgYW4gb2JqZWN0aW9uIHRvIGRpc2NhcmQgYnkgZGVmYXVsdCBwYWNrZXRzDQo+IHdp dGggTyBiaXQgc2V0IGFuZCBuZXh0IHByb3RvY29sID0gSVAvTVBMUy9FdGhlcm5ldA0KPiANCj4g Q2hlZXJzLA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4g RGXCoDogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPiBFbnZvecOpwqA6IG1l cmNyZWRpIDE2DQo+ID4gZsOpdnJpZXIgMjAyMiAxNzozMCDDgMKgOiBCT1VDQURBSVIgTW9oYW1l ZCBJTk5PVi9ORVQNCj4gPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IEdyZWcgTWly c2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20+DQo+IENjDQo+ID4gOiBzZmNAaWV0Zi5vcmcgT2Jq ZXTCoDogUmU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOg0KPiA+IGRyYWZ0LWJvdWNhZGFpci1zZmMt b2FtLXBhY2tldC0wMC50eHQNCj4gPg0KPiA+IFRoYW5rIHlvdSBmb3Igd3JpdGluZyB0aGlzLiAg SSBsb29rIGZvcndhcmQgdG8gbW9yZSBkc2N1c3Npb24gYnkgbW9yZQ0KPiA+IFdHIG1lbWJlcnMu DQo+ID4NCj4gPiBJIHdhbnQgdG8gYXNrIG9uZSBjbGFyaWZ5aW5nIHF1ZXNpdG9uIGFib3V0IGFu IGV4YW1wbGUgdGhhdCB3YXMgcmFpc2VkDQo+ID4gZWFybGllci4NCj4gPg0KPiA+IElmIHRoZSBO U0ggcGF5bG9hZCBpcyBhbiBJUCBwYWNrZXQsIGFuZCB0aGF0IHBhY2tldCBpcyBhZGRyZXNzZWQg dG8NCj4gPiBzb21ldGhpbmcgb3RoZXIgdGhhbiB0aGlzIG5vZGUsIGFuZCB0aGF0IHBhY2tldCBp cyBjYXJyeWluZyAgYW4gSUNNUA0KPiA+IGVjaG8sIGlzIHRoYXQgYW4gU0ZDIE9BTSBwYWNrZXQg cmVxdWlyaW5nIHRoZSBPLWJpdCBiZWluZyBzZXQ/ICBBbmQNCj4gPiBjb252ZXJzZWx5LCBpcyBh biBTRkYgcmVxdWlyZWQgdG8gY2hlY2sgZm9yIHRoYXQgY2FzZSBpZiBpdCBzZWVzIGFuDQo+ID4g TlNIIHdpdGggdGhlIE8tYml0IHNldD8NCj4gPg0KPiA+IFlvdXJzLA0KPiA+IEpvZWwNCj4gPg0K PiA+IE9uIDIvMTYvMjAyMiAxMToyMSBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3 cm90ZToNCj4gPiA+IFJlLSwNCj4gPiA+DQo+ID4gPiBUaGlzIGlzIGRldGVybWluZWQgYnkgdGhl IGVudGl0eSB0aGF0IGlzc3VlcyB0aGUgT0FNIHBhY2tldC4gVGhpcyBpcw0KPiA+ID4gdHlwaWNh bGx5IGEgZGVkaWNhdGVkIE9BTSBjb250cm9sbGVyIG9yIGFuIFNGQyBlbGVtZW50IChjbGFzc2lm aWVyDQo+ID4gPiBmb3IgdGhlIGlvYW0gY2FzZSwgZm9yIGV4YW1wbGUpLg0KPiA+ID4NCj4gPiA+ IEJUVywgSSB1cGRhdGVkIHRoZSBkcmFmdCB0byByZWZsZWN0IHlvdXIgY29tbWVudHMgYW5kIGFs c28gdGhvc2UNCj4gPiA+IGZyb20NCj4gPiA+IEppbToNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQtMDENCj4gPiA+ IDxodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYm91Y2FkYWlyLXNmYy1v YW0tcGFja2V0LTAxDQo+ID4gPiA+DQo+ID4gPg0KPiA+ID4gQ2hlZXJzLA0KPiA+ID4NCj4gPiA+ IE1lZA0KPiA+ID4NCj4gPiA+ICpEZcKgOiogR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWls LmNvbT4gKkVudm95w6nCoDoqIG1lcmNyZWRpIDE2DQo+ID4gPiBmw6l2cmllciAyMDIyIDE2OjUy ICrDgMKgOiogQk9VQ0FEQUlSIE1vaGFtZWQgSU5OT1YvTkVUDQo+ID4gPiA8bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbT4gKkNjwqA6KiBzZmNAaWV0Zi5vcmcgKk9iamV0wqA6KiBSZToNCj4g PiA+IFtzZmNdDQo+ID4gPiBUUjogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0t cGFja2V0LTAwLnR4dA0KPiA+ID4NCj4gPiA+IEhpIE1lZCwNCj4gPiA+DQo+ID4gPiB0aGFuayB5 b3UgZm9yIHlvdXIgZXhwZWRpZW50wqByZXNwb25zZS4gSSBoYXZlIGEgZm9sbG93LXVwIHF1ZXN0 aW9uOg0KPiA+ID4NCj4gPiA+ICAgICBIb3cgZG9lcyBvbmUgZGV0ZXJtaW5lIHRoZSBuYXR1cmUs IE9BTSBvciBub3QtT0FNLCBvZiBkYXRhDQo+ID4gZWxlbWVudHMNCj4gPiA+ICAgICBpbiB0aGUg TlNIIENvbnRleHQgaGVhZGVyPw0KPiA+ID4NCj4gPiA+IEFzIEkgdW5kZXJzdGFuZCBpdCwgZHJh ZnQtaWV0Zi1zZmMtbnNoLXRsdiBkb2VzIG5vdCBwcm92aWRlIHRoYXQuIERvDQo+ID4gPiB3ZSBu ZWVkIHRvIGFkZCBpdD8gQXBwcmVjaWF0ZSB5b3VyIHRob3VnaHRzIG9uIHRoYXQuDQo+ID4gPg0K PiA+ID4gUmVnYXJkcywNCj4gPiA+DQo+ID4gPiBHcmVnDQo+ID4gPg0KPiA+ID4gT24gV2VkLCBG ZWIgMTYsIDIwMjIgYXQgNzozMCBBTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+ ID4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+ID4gPg0K PiA+ID4gICAgIEhpIEdyZWcsDQo+ID4gPg0KPiA+ID4gICAgIFBsZWFzZSBzZWUgaW5saW5lLg0K PiA+ID4NCj4gPiA+ICAgICBDaGVlcnMsDQo+ID4gPg0KPiA+ID4gICAgIE1lZA0KPiA+ID4NCj4g PiA+ICAgICAqRGXCoDoqIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20NCj4gPiA+ ICAgICA8bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+DQo+ID4gPiAgICAgKkVudm95w6nC oDoqIG1lcmNyZWRpIDE2IGbDqXZyaWVyIDIwMjIgMTY6MTMNCj4gPiA+ICAgICAqw4DCoDoqIEJP VUNBREFJUiBNb2hhbWVkIElOTk9WL05FVCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0K PiA+ID4gICAgIDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+DQo+ID4gPiAg ICAgKkNjwqA6KiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4gPiAgICAg Kk9iamV0wqA6KiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246DQo+ID4gPiAgICAgZHJhZnQtYm91 Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAwLnR4dA0KPiA+ID4NCj4gPiA+ICAgICBIaSBNZWQsDQo+ ID4gPg0KPiA+ID4gICAgIG1hbnkgdGhhbmtzIGZvciB0YWtpbmcgdGhlIGxlYWQgYW5kIHB1dHRp bmcgdGhlIHByb3Bvc2FsIG9uIHRoZQ0KPiA+IHRhYmxlLg0KPiA+ID4NCj4gPiA+ICAgICBJIGhh dmUgYSBxdWVzdGlvbiBvbiB0aGUgcHJvcG9zZWQgbmV3IHRleHQgZm9yIHRoZSBPIGJpdCBhbmQg aXRzDQo+ID4gPiAgICAgcG9zc2libGUgZWZmZWN0IG9uIElPQU06DQo+ID4gPg0KPiA+ID4gICAg ICDCoCDCoE8gYml0OsKgIFNldHRpbmcgdGhpcyBiaXQgaW5kaWNhdGVzIGFuIFNGQyBPQU0gcGFj a2V0LsKgIFN1Y2gNCj4gPiA+IGEgcGFja2V0DQo+ID4gPg0KPiA+ID4gICAgICDCoCDCoCDCoCBp cyBhbnkgTlNILWVuY2FwYXN1bGF0ZWQgcGFja2V0IHRoYXQgZXhjbHVzaXZlbHkgaW5jbHVkZXMN Cj4gPiA+IGFuIE9BTQ0KPiA+ID4NCj4gPiA+ICAgICAgwqAgwqAgwqAgY29tbWFuZCBhbmQvb3Ig T0FNIGRhdGEuDQo+ID4gPg0KPiA+ID4gICAgIE15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIG5ldyBk ZWZpbml0aW9uIG9mIHRoZSBPIGJpdCBpcyB0aGF0IHRoZQ0KPiA+IE5TSA0KPiA+ID4gICAgIGlu Y2x1ZGVzIGFuZC9vciBlbmNhcHN1bGF0ZXMgb25seSBPQU0gY29tbWFuZCBhbmQvb3IgZGF0YS4g SU9BTSwNCj4gPiBhcw0KPiA+ID4gICAgIEkgdW5kZXJzdGFuZCBpdHMgYXBwbGljYXRpb24gaW4g TlNILCBtYXkgZm9sbG93IHRoZSBOU0ggYW5kIGhhdmUNCj4gPiA+ICAgICB1c2VyIHBheWxvYWQg YWZ0ZXIgdGhlIElPQU0gZGF0YS4NCj4gPiA+DQo+ID4gPiAgICAgKi8vKg0KPiA+ID4NCj4gPiA+ ICAgICAqL1tNZWRdIFBhY2tldHMgdGhhdCBpbmNsdWRlIGFsc28gdXNlciBkYXRhIGFyZSBub3Qg Y29uc2lkZXJlZA0KPiBhcw0KPiA+ID4gICAgIOKAnE9BTSBwYWNrZXRz4oCdIGFzIHBlciB0aGUg bmV3IGRlZmluaXRpb24uLyoNCj4gPiA+DQo+ID4gPiAgICAgQW5kIGFub3RoZXIgc2NlbmFyaW8s IGlmIEZsb3cgSUQgVExWIGlzIHVzZWQgdG8gaW5mbHVlbmNlIHVzZXINCj4gPiBkYXRhDQo+ID4g PiAgICAgdGhyb3VnaCBTRlAsIE9BTSB3aWxsIGFwcGx5IHRoZSBzYW1lIEZsb3cgSUQgdmFsdWUu IFdvdWxkIHN1Y2gNCj4gPiA+ICAgICBwYWNrZXQgc3RpbGwgYmUgY29uc2lkZXJlZCBhcyAiZXhj bHVzaXZlbHkgaW5jbHVkZXMgT0FNIGNvbW1hbmQNCj4gPiA+ICAgICBhbmQvb3IgZGF0YSI/DQo+ ID4gPg0KPiA+ID4gICAgICovLyoNCj4gPiA+DQo+ID4gPiAgICAgKi9bTWVkXSBZZXMsIHRoZXkg YXJlLiBGbG93IGlkIGlzIGp1c3QgYSBjb25zdHJhaW50LCBpZiB5b3UNCj4gd2lsbCwNCj4gPiA+ ICAgICB0aGF0IGlzIHVzZWQgdG8gaW5mbHVlbmNlIGhvdyBPQU0gY29tbWFuZHMgd2lsbCBiZSBl eGVjdXRlZC4gLyoNCj4gPiA+DQo+ID4gPiAgICAgUmVnYXJkcywNCj4gPiA+DQo+ID4gPiAgICAg R3JlZw0KPiA+ID4NCj4gPiA+ICAgICBPbiBXZWQsIEZlYiAxNiwgMjAyMiBhdCA2OjQwIEFNIDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4gPiAgICAgPG1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gICAgICAgICBIaSBhbGws DQo+ID4gPg0KPiA+ID4gICAgICAgICBBIHByb3Bvc2FsIHRvIGNsYXJpZnkgdGhlIGludGVudCBv ZiBTRkMgT0FNIHBhY2tldC4gQ29tbWVudHMNCj4gPiBhcmUNCj4gPiA+ICAgICAgICAgd2VsY29t ZS4NCj4gPiA+DQo+ID4gPiAgICAgICAgIENoZWVycywNCj4gPiA+ICAgICAgICAgTWVkDQo+ID4g Pg0KPiA+ID4gICAgICAgICAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+ICAgICAg ICAgRGXCoDogSS1ELUFubm91bmNlIDxpLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZw0KPiA+ ID4gICAgICAgICA8bWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPj4gRGUgbGEg cGFydCBkZQ0KPiA+ID4gICAgICAgICBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPG1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+ID4gPiAgICAgICAgIEVudm95w6nCoDogbWVyY3Jl ZGkgMTYgZsOpdnJpZXIgMjAyMiAxNTozOA0KPiA+ID4gICAgICAgICDDgMKgOiBpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmcgPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+ID4gPiAgICAgICAg IE9iamV0wqA6IEktRCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC0wMC50 eHQNCj4gPiA+DQo+ID4gPg0KPiA+ID4gICAgICAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZQ0KPiA+ID4gICAgICAgICBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuDQo+ID4gPg0KPiA+ID4NCj4gPiA+ICAgICAgICAgIMKgIMKgIMKgIMKgIFRp dGxlwqAgwqAgwqAgwqAgwqAgwqA6IENsYXJpZnlpbmcgQW1iaWd1aXR5IHJlbGF0ZWQgdG8NCj4g PiA+ICAgICAgICAgTmV0d29yayBTZXJ2aWNlIEhlYWRlciAoTlNIKSBPQU0gUGFja2V0DQo+ID4g PiAgICAgICAgICDCoCDCoCDCoCDCoCBBdXRob3LCoCDCoCDCoCDCoCDCoCA6IE1vaGFtZWQgQm91 Y2FkYWlyDQo+ID4gPiAgICAgICAgICDCoCDCoCDCoCDCoCBGaWxlbmFtZcKgIMKgIMKgIMKgIDog ZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LQ0KPiA+IDAwLnR4dA0KPiA+ID4gICAgICAg ICAgwqAgwqAgwqAgwqAgUGFnZXPCoCDCoCDCoCDCoCDCoCDCoDogNQ0KPiA+ID4gICAgICAgICAg wqAgwqAgwqAgwqAgRGF0ZcKgIMKgIMKgIMKgIMKgIMKgIDogMjAyMi0wMi0xNg0KPiA+ID4NCj4g PiA+ICAgICAgICAgQWJzdHJhY3Q6DQo+ID4gPiAgICAgICAgICDCoCDCoFRoaXMgZG9jdW1lbnQg Y2xhcmlmaWVzIGFuIGFtYmlndWl0eSBpbiB0aGUgTmV0d29yaw0KPiA+IFNlcnZpY2UNCj4gPiA+ ICAgICAgICAgSGVhZGVyDQo+ID4gPiAgICAgICAgICDCoCDCoChOU0gpIHNwZWNpZmljYXRpb24g cmVsYXRlZCB0byB0aGUgaGFuZGxpbmcgb2YgTy0NCj4gYml0LsKgIEluDQo+ID4gPiAgICAgICAg IHBhcnRpY3VsYXIsDQo+ID4gPiAgICAgICAgICDCoCDCoHRoaXMgZG9jdW1lbnQgY2xhcmlmaWVz IHRoZSBtZWFuaW5nIG9mICJPQU0gcGFja2V0Ii4NCj4gPiA+DQo+ID4gPiAgICAgICAgICDCoCDC oFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM4MzAwLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAgICAg ICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K PiA+ID4gICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3Vj YWRhaXItc2ZjLW9hbS0NCj4gPiBwYWNrZXQvDQo+ID4gPg0KPiA+ID4gPGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC8+DQo+ID4g Pg0KPiA+ID4gICAgICAgICBUaGVyZSBpcyBhbHNvIGFuIGh0bWxpemVkIHZlcnNpb24gYXZhaWxh YmxlIGF0Og0KPiA+ID4NCj4gPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tDQo+ID4gcGFja2V0LTAwDQo+ID4gPg0KPiA+ID4g PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYm91Y2FkYWlyLXNm Yy1vYW0tcGFja2UNCj4gPiA+IHQtDQo+ID4gPiAwMD4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gICAg ICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IHJzeW5jIGF0DQo+ID4g PiAgICAgICAgIHJzeW5jLmlldGYub3JnOjppbnRlcm5ldC1kcmFmdHMNCj4gPiA+DQo+ID4gPg0K PiA+ID4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+ID4gICAgICAgICBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+ID4gPiAgICAg ICAgIEktRC1Bbm5vdW5jZUBpZXRmLm9yZyA8bWFpbHRvOkktRC1Bbm5vdW5jZUBpZXRmLm9yZz4N Cj4gPiA+ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQt YW5ub3VuY2UNCj4gPiA+ICAgICAgICAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaS1kLWFubm91bmNlPg0KPiA+ID4gICAgICAgICBJbnRlcm5ldC1EcmFmdCBkaXJlY3Rv cmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPiA+ID4gICAgICAgICA8aHR0 cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbD4gb3INCj4gPiA+ICAgICAgICAgZnRwOi8vZnRw LmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4gPiA+ICAgICAgICAgPGZ0cDovL2Z0 cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0Pg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+ID4gX18gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gPg0KPiA+ID4gICAgICAgICBDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcw0KPiA+ID4gICAgICAgICBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50DQo+ID4g ZG9uYw0KPiA+ID4gICAgICAgICBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kNCj4gPiA+ICAgICAgICAgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPiA+ID4gICAgICAgICBh IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz Lg0KPiA+IExlcw0KPiA+ID4gICAgICAgICBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+ID4gPiAgICAgICAgIE9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUNCj4gPiBhbHRlcmUsDQo+ID4g PiAgICAgICAgIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiA+ID4NCj4gPiA+ICAgICAg ICAgVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yDQo+ID4gPiAgICAgICAgIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsNCj4gPiA+ICAgICAgICAgdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0DQo+ID4gPiAgICAgICAgIGF1dGhvcmlzYXRp b24uDQo+ID4gPiAgICAgICAgIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlDQo+ID4gPiAgICAgICAgIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+ID4gICAgICAgICBBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcw0KPiA+IHRo YXQNCj4gPiA+ICAgICAgICAgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4NCj4gPiA+ICAgICAgICAgVGhhbmsgeW91Lg0KPiA+ID4NCj4gPiA+ICAgICAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ICAgICAgICAg c2ZjIG1haWxpbmcgbGlzdA0KPiA+ID4gICAgICAgICBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+ID4gPiAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+ID4gPiAgICAgICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYz4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IF9fIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4N Cj4gPiA+ICAgICBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcw0KPiA+ID4gaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll ZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+ID4gPg0KPiA+ID4gICAgIHBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaQ0KPiA+ID4gdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPiA+ ID4NCj4gPiA+ICAgICBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMNCj4gPiA+IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gPiA+DQo+ID4gPiAgICAgT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsDQo+ID4g ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+ID4gPg0KPiA+ID4gICAgIFRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiA+ID4g cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPiA+ ID4NCj4gPiA+ICAgICB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQNCj4gPiBhdXRob3Jpc2F0aW9uLg0KPiA+ID4NCj4gPiA+ICAgICBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZQ0KPiA+ ID4gc2VuZGVyDQo+ID4gYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4NCj4gPiA+DQo+ID4gPiAgICAgQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdA0KPiA+IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuDQo+ID4gPg0KPiA+ID4gICAgIFRoYW5rIHlvdS4NCj4gPiA+DQo+ ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gX18gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPg0KPiA+ID4gQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+ID4gPiBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZQ0K PiA+ID4gZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1DQo+ID4gPiBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlDQo+ID4gPiBkZXRydWlyZSBhaW5zaQ0KPiA+ IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcw0KPiA+IGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZQ0KPiA+IGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuDQo+ID4gPg0KPiA+ID4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yDQo+ID4gPiBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdA0KPiA+ IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ ID4gPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXINCj4gPiA+IGFuZA0KPiA+IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4NCj4gPiA+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQNCj4gPiA+IGhhdmUNCj4gPiBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gPiA+IFRoYW5rIHlvdS4NCj4gPiA+DQo+ID4g Pg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+IHNmYyBtYWlsaW5nIGxpc3QNCj4gPiA+IHNmY0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IA0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMNCj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsDQo+IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyDQo+IGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kgcXVlIGxlcw0KPiBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzDQo+IGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZQ0KPiBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLg0KPiANCj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCj4gaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlDQo+IGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+IElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQNCj4gZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiBBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUNCj4gYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRoYW5rIHlv dS4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Wed Feb 23 23:57:51 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01C63A0971; Wed, 23 Feb 2022 23:57:49 -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_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 7QoJpXQg8uyC; Wed, 23 Feb 2022 23:57:45 -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 1EB283A0977; Wed, 23 Feb 2022 23:57:45 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (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 opfedar21.francetelecom.fr (ESMTP service) with ESMTPS id 4K44yG6tLrz7ttc; Thu, 24 Feb 2022 08:57:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645689463; bh=VP8nrknPZPGY5w0k2sfUoHVCJJeljPKoALnypIAs4WY=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=nGHyF6mkGM6OXTsFg2cK7Glv8aPubiQdtAfa4fzXx6X4+cOuq8wOpAf/tR4zlGr7G 3mZRLhiboxHTq1RFqIC41DbMZ8+jm8yuA8zZrylCKoDyhamHzQklOcIcS4+3tvzmxh 83eZBkvNwX5lKKq4HjeVOxR7fuCRGGuHziDKnmI/f11wGoV0C33Y8iXyrhWeHrOe25 PJs5eOSyVP7y0Shomd7IXjEwhzExIik0rzY9PnOysSYpyEZj1XMlwuiy2LwERPwcsy vxgKzEz7OoNkn9wHxP/ic64r8kQryc9Bvee//hJy4AWkl3i4nbTscyF+nOrFe9rAWE TWyMR9SfPWHQg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4K44yG5VdpzCqk7; Thu, 24 Feb 2022 08:57:42 +0100 (CET) From: To: Greg Mirsky CC: "sfc@ietf.org" , "draft-ietf-sfc-ioam-nsh@ietf.org" Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt Thread-Index: AQHYI0LOqTeC5k5EYkSp4mi5aRUmyqyh4tF+gAB6kwA= Content-Class: Date: Thu, 24 Feb 2022 07:57:41 +0000 Message-ID: <17568_1645689462_62173A76_17568_471_1_787AE7BB302AE849A7480A190F8B933035498F57@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-24T07:41:53Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=ab8ddb29-21a4-44aa-a467-ebd5088dd956; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933035498F57OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 07:57:50 -0000 --_000_787AE7BB302AE849A7480A190F8B933035498F57OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KSSBob3BlIHRvIHNlZSBpdCBhZG9wdGVkIGFzIHdlbGwuIFRoYW5rIHlvdS4N Cg0KSWYvb25jZSBhZG9wdGVkLCBJIGV4cGVjdCBTZWN0aW9uIDQuMSBvZiBkcmFmdC1pZXRmLXNm Yy1pb2FtLW5zaCAob3IgYXQgbGVhc3QgaXRzIG5vcm1hdGl2ZSBsYW5ndWFnZSkgdG8gYmUgcmVt b3ZlZCBidXQgcG9pbnQgdG8gZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0IGZvciBPIGJp dCBoYW5kbGluZy4NCg0KSWRlbSBmb3IgU2VjdGlvbiA0IG9mIGRyYWZ0LWlldGYtc2ZjLW11bHRp LWxheWVyLW9hbS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogR3JlZyBNaXJza3kgPGdyZWdpbWly c2t5QGdtYWlsLmNvbT4NCkVudm95w6kgOiBqZXVkaSAyNCBmw6l2cmllciAyMDIyIDAxOjIzDQrD gCA6IEJPVUNBREFJUiBNb2hhbWVkIElOTk9WL05FVCA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT4NCkNjIDogc2ZjQGlldGYub3JnDQpPYmpldCA6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlv bjogZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAwLnR4dA0KDQpIaSBNZWQsDQp0aGFu ayB5b3UgZm9yIHlvdXIgcHJvcG9zYWwuIEkgYmVsaWV2ZSB0aGF0IGl0IHNvbHZlcyB0aGUgcHJv YmxlbSBhbmQgaGVscHMgdGhlIEFjdGl2ZSBTRkMgT0FNLiBJZiBJIG1heSwgSSdtIHByb3Bvc2lu ZyB0aGUgV0cgQ2hhaXJzIGNvbnNpZGVyIHRoZSBXRyBBUCBvbiB0aGlzIGRvY3VtZW50LiBBbmQg Zm9yIHRoZSByZWNvcmQ6DQpJJ3ZlIHJlYWQgdGhlIGRvY3VtZW50IGFuZCBzdXBwb3J0IGl0cyBh ZG9wdGlvbiBieSB0aGUgU0ZDIFdHLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBXZWQsIEZlYiAx NiwgMjAyMiBhdCA2OjQwIEFNIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzpt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQpIaSBhbGwsDQoNCkEgcHJvcG9z YWwgdG8gY2xhcmlmeSB0aGUgaW50ZW50IG9mIFNGQyBPQU0gcGFja2V0LiBDb21tZW50cyBhcmUg d2VsY29tZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K RGUgOiBJLUQtQW5ub3VuY2UgPGktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpp LWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZz4+IERlIGxhIHBhcnQgZGUgaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpFbnZvecOpIDog bWVyY3JlZGkgMTYgZsOpdnJpZXIgMjAyMiAxNTozOA0Kw4AgOiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCk9iamV0IDogSS1EIEFjdGlvbjogZHJh ZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAwLnR4dA0KDQoNCkEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IENsYXJpZnlpbmcgQW1iaWd1aXR5 IHJlbGF0ZWQgdG8gTmV0d29yayBTZXJ2aWNlIEhlYWRlciAoTlNIKSBPQU0gUGFja2V0DQogICAg ICAgIEF1dGhvciAgICAgICAgICA6IE1vaGFtZWQgQm91Y2FkYWlyDQogICAgICAgIEZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC0wMC50eHQNCiAgICAgICAg UGFnZXMgICAgICAgICAgIDogNQ0KICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDIyLTAyLTE2 DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBjbGFyaWZpZXMgYW4gYW1iaWd1aXR5IGlu IHRoZSBOZXR3b3JrIFNlcnZpY2UgSGVhZGVyDQogICAoTlNIKSBzcGVjaWZpY2F0aW9uIHJlbGF0 ZWQgdG8gdGhlIGhhbmRsaW5nIG9mIE8tYml0LiAgSW4gcGFydGljdWxhciwNCiAgIHRoaXMgZG9j dW1lbnQgY2xhcmlmaWVzIHRoZSBtZWFuaW5nIG9mICJPQU0gcGFja2V0Ii4NCg0KICAgVGhpcyBk b2N1bWVudCB1cGRhdGVzIFJGQzgzMDAuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQvDQoNClRoZXJlIGlzIGFsc28gYW4gaHRt bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC0wMA0KDQoNCkludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgcnN5bmMgYXQgcnN5bmMuaWV0Zi5vcmc6Omlu dGVybmV0LWRyYWZ0cw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VAaWV0Zi5v cmc8bWFpbHRvOkktRC1Bbm5vdW5jZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJbnRlcm5ldC1EcmFmdCBkaXJlY3Rvcmllczog aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0 Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxp bmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_787AE7BB302AE849A7480A190F8B933035498F57OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNzMxNzMzMDY0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTI3MzYwMjk4IC0zNTcxNzA0NjYgNjc4OTUyOTkg Njc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4 OTUzMDE7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo0Ow0KCW1zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9Indv cmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgR3Jl ZywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkkgaG9wZSB0byBzZWUgaXQgYWRvcHRlZCBhcyB3ZWxsLiBUaGFuayB5 b3UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklmL29uY2UgYWRvcHRlZCwgSSBleHBlY3QgU2Vj dGlvbiA0LjEgb2YgZHJhZnQtaWV0Zi1zZmMtaW9hbS1uc2ggKG9yIGF0IGxlYXN0IGl0cyBub3Jt YXRpdmUgbGFuZ3VhZ2UpIHRvIGJlIHJlbW92ZWQgYnV0IHBvaW50IHRvIGRyYWZ0LWJvdWNhZGFp ci1zZmMtb2FtLXBhY2tldA0KIGZvciBPIGJpdCBoYW5kbGluZy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SWRlbSBmb3IgU2VjdGlvbiA0IG9mIGRyYWZ0LWlldGYtc2ZjLW11bHRpLWxheWVyLW9h bS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ RGUmbmJzcDs6PC9iPiBHcmVnIE1pcnNreSAmbHQ7Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0OyA8 YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgMjQgZsOpdnJpZXIgMjAyMiAwMToyMzxi cj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU5OT1YvTkVUICZsdDttb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4gc2ZjQGll dGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246 IGRyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC0wMC50eHQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBNZWQsPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmsgeW91IGZvciB5b3VyIHByb3Bvc2FsLiBJIGJl bGlldmUgdGhhdCBpdCBzb2x2ZXMmbmJzcDt0aGUgcHJvYmxlbSBhbmQgaGVscHMgdGhlIEFjdGl2 ZSBTRkMgT0FNLiBJZiBJIG1heSwgSSdtIHByb3Bvc2luZyB0aGUgV0cgQ2hhaXJzIGNvbnNpZGVy IHRoZSBXRyBBUCBvbiB0aGlzIGRvY3VtZW50LiBBbmQgZm9yIHRoZSByZWNvcmQ6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFy Z2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSd2ZSByZWFkIHRo ZSBkb2N1bWVudCBhbmQgc3VwcG9ydCBpdHMgYWRvcHRpb24gYnkgdGhlIFNGQyBXRy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMTYsIDIwMjIgYXQgNjo0MCBBTSAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCwgPGJyPg0KPGJyPg0KQSBwcm9wb3NhbCB0 byBjbGFyaWZ5IHRoZSBpbnRlbnQgb2YgU0ZDIE9BTSBwYWNrZXQuIENvbW1lbnRzIGFyZSB3ZWxj b21lLjxicj4NCjxicj4NCkNoZWVycyw8YnI+DQpNZWQ8YnI+DQo8YnI+DQotLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS08YnI+DQpEZSZuYnNwOzogSS1ELUFubm91bmNlICZsdDs8YSBocmVmPSJt YWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pLWQt YW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IERlIGxhIHBhcnQgZGUNCjxhIGhyZWY9 Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8L2E+PGJyPg0KRW52b3nDqSZuYnNwOzogbWVyY3JlZGkgMTYgZsOp dnJpZXIgMjAyMiAxNTozODxicj4NCsOAJm5ic3A7OiA8YSBocmVmPSJtYWlsdG86aS1kLWFubm91 bmNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPjxi cj4NCk9iamV0Jm5ic3A7OiBJLUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNr ZXQtMDAudHh0PGJyPg0KPGJyPg0KPGJyPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NCjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBDbGFyaWZ5aW5nIEFtYmlndWl0eSByZWxhdGVk IHRvIE5ldHdvcmsgU2VydmljZSBIZWFkZXIgKE5TSCkgT0FNIFBhY2tldDxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBBdXRob3ImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDogTW9oYW1lZCBCb3VjYWRhaXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg RmlsZW5hbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBkcmFmdC1ib3VjYWRhaXItc2Zj LW9hbS1wYWNrZXQtMDAudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBhZ2Vz Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDU8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDogMjAyMi0wMi0xNjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAm bmJzcDtUaGlzIGRvY3VtZW50IGNsYXJpZmllcyBhbiBhbWJpZ3VpdHkgaW4gdGhlIE5ldHdvcmsg U2VydmljZSBIZWFkZXI8YnI+DQombmJzcDsgJm5ic3A7KE5TSCkgc3BlY2lmaWNhdGlvbiByZWxh dGVkIHRvIHRoZSBoYW5kbGluZyBvZiBPLWJpdC4mbmJzcDsgSW4gcGFydGljdWxhciw8YnI+DQom bmJzcDsgJm5ic3A7dGhpcyBkb2N1bWVudCBjbGFyaWZpZXMgdGhlIG1lYW5pbmcgb2YgJnF1b3Q7 T0FNIHBhY2tldCZxdW90Oy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCB1 cGRhdGVzIFJGQzgzMDAuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNhZGFp ci1zZmMtb2FtLXBhY2tldC88L2E+PGJyPg0KPGJyPg0KVGhlcmUgaXMgYWxzbyBhbiBodG1saXpl ZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBhY2tldC0wMCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt Ym91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAwPC9hPjxicj4NCjxicj4NCjxicj4NCkludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgcnN5bmMgYXQgcnN5bmMuaWV0Zi5vcmc6Omlu dGVybmV0LWRyYWZ0czxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5J LUQtQW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTwvYT48YnI+DQpJbnRl cm5ldC1EcmFmdCBkaXJlY3RvcmllczogPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFk b3cuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bDwvYT4gb3IgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50 eHQiIHRhcmdldD0iX2JsYW5rIj4NCmZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0 ZXMudHh0PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8YnI+DQpwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxi cj4NCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sPGJyPg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxicj4NCjxi cj4NClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7PGJyPg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uPGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPGJyPg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxicj4NClRoYW5rIHlvdS48YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ c2ZjQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+ DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933035498F57OPEXCAUBMA2corp_-- From nobody Thu Feb 24 05:40:10 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05A73A0D5A for ; Thu, 24 Feb 2022 05:40:07 -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, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMicBQ1aYFDL for ; Thu, 24 Feb 2022 05:40:03 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615233A0D61 for ; Thu, 24 Feb 2022 05:40:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4K4DYH1FnZz1nv1J; Thu, 24 Feb 2022 05:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1645710003; bh=Wx3yx3W7o1x7A1ej3EAIcVV/WBXzuK3C34MUtbozW+8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=hh2/boMsawpu02w/6vXye1e0L+KTdsaHt/B+s3HXCAJ3o1cJeBZ5L4Z+LhdCvKLXJ LsvYgkJ9RmpQ4WmVxAbqOYljQeBmXxYuJYiFrRF0ibaEfnYmswDSx9FnveWR5ldnQP B7O17jqEEdSrfMQQ4ViXPcnllyvRqtU0nv02aTJo= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4K4DYG3dVpz1nsbZ; Thu, 24 Feb 2022 05:40:02 -0800 (PST) Message-ID: Date: Thu, 24 Feb 2022 08:40:01 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: mohamed.boucadair@orange.com, Greg Mirsky Cc: "sfc@ietf.org" References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <30956_1645025435_620D189B_30956_353_1_787AE7BB302AE849A7480A190F8B933035494DD5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <3535_1645028520_620D24A8_3535_225_1_787AE7BB302AE849A7480A190F8B933035494EAE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <5efa6354-4396-d1b1-bec3-122d2aa148c2@joelhalpern.com> <26440_1645082031_620DF5AF_26440_39_1_787AE7BB302AE849A7480A190F8B9330354954F7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <16224_1645689365_62173A15_16224_31_1_787AE7BB302AE849A7480A190F8B933035498F45@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" In-Reply-To: <16224_1645689365_62173A15_16224_31_1_787AE7BB302AE849A7480A190F8B933035498F45@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 13:40:08 -0000 May a suggest a small refinement? The setting and processing of the O bit neither assumes nor expects detailed analysis of the contents of any IP packets carried by NSH. As such, SFFs and SFs SHOULD discard any NSH packets with the O bit set and Next protocol set to something that is not itself an OAM protocol. THis includes discarding the packet when O bit is set and the Next Protocol is set to 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or 0x05 (Ethernet). Yours, Joel On 2/24/2022 2:56 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, all, > > FWIW, I updated -02 with the following to reflect one of the points discussed below: > > When an OAM data is included in the inner packet, the Next > Protocol field is set to reflect the structure of that inner > packet. By default, SFFs SHOULD discard NSH packets with O bit > set and Next Protocol set to 0x1 (IPv4), 0x2 (IPv6), 0x3 (MPLS), > or 0x5 (Ethernet). > > Cheers, > Med > >> -----Message d'origine----- >> De : sfc De la part de >> mohamed.boucadair@orange.com >> Envoyé : jeudi 17 février 2022 08:14 >> À : Joel M. Halpern ; Greg Mirsky >> >> Cc : sfc@ietf.org >> Objet : Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt >> >> Hi Joel, >> >>> If the NSH payload is an IP packet, and that packet is addressed to >>> something other than this node, and that packet is carrying an ICMP >>> echo, is that an SFC OAM packet requiring the O-bit being set? >> >> Med: The NSH can be added by a classifier or directly by an SFC OAM >> controller that issues the packet. If the original IP/ICMP packet is >> received by a classifier, the classifier must not set the O bit as per >> draft-boucadair-sfc-oam-packet because that packet is seen as data >> packet. >> >> Let's now focus on the SFC OAM controller case: >> * Does it makes sense for an SFC OAM controller to "leverage" IP/ICMP >> for SFC OAM purposes while it can do it directly using ICMP (without the >> IP header)? >> >> I personally don't see any. >> >> * Does it makes sense for an SFC OAM controller to "supply" an IP/ICMP >> as an input for specific OAM purposes? >> >> This is in theory possible for SF testing purposes (e.g., test the >> behavior of a firewall against such packet. The output of the test will >> be used to assess if the FW configuration is OK/NOK). However, such test >> OAM packets have to be unambiguously identified as such. The Next >> Protocol won't be set to IP but to the value assigned to an OAM >> protocol. >> >> And >>> conversely, is an SFF required to check for that case if it sees an >>> NSH with the O-bit set? >> >> Med: SFFs have to support policies whether some OAM messages can be >> forwarded to SFs. These policies may include a filter on valid next >> protocol values. I don't have an objection to discard by default packets >> with O bit set and next protocol = IP/MPLS/Ethernet >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern Envoyé : mercredi 16 >>> février 2022 17:30 À : BOUCADAIR Mohamed INNOV/NET >>> ; Greg Mirsky >> Cc >>> : sfc@ietf.org Objet : Re: [sfc] TR: I-D Action: >>> draft-boucadair-sfc-oam-packet-00.txt >>> >>> Thank you for writing this. I look forward to more dscussion by more >>> WG members. >>> >>> I want to ask one clarifying quesiton about an example that was raised >>> earlier. >>> >>> If the NSH payload is an IP packet, and that packet is addressed to >>> something other than this node, and that packet is carrying an ICMP >>> echo, is that an SFC OAM packet requiring the O-bit being set? And >>> conversely, is an SFF required to check for that case if it sees an >>> NSH with the O-bit set? >>> >>> Yours, >>> Joel >>> >>> On 2/16/2022 11:21 AM, mohamed.boucadair@orange.com wrote: >>>> Re-, >>>> >>>> This is determined by the entity that issues the OAM packet. This is >>>> typically a dedicated OAM controller or an SFC element (classifier >>>> for the ioam case, for example). >>>> >>>> BTW, I updated the draft to reflect your comments and also those >>>> from >>>> Jim: >>>> https://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-oam-packet-01 >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Med >>>> >>>> *De :* Greg Mirsky *Envoyé :* mercredi 16 >>>> février 2022 16:52 *À :* BOUCADAIR Mohamed INNOV/NET >>>> *Cc :* sfc@ietf.org *Objet :* Re: >>>> [sfc] >>>> TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt >>>> >>>> Hi Med, >>>> >>>> thank you for your expedient response. I have a follow-up question: >>>> >>>> How does one determine the nature, OAM or not-OAM, of data >>> elements >>>> in the NSH Context header? >>>> >>>> As I understand it, draft-ietf-sfc-nsh-tlv does not provide that. Do >>>> we need to add it? Appreciate your thoughts on that. >>>> >>>> Regards, >>>> >>>> Greg >>>> >>>> On Wed, Feb 16, 2022 at 7:30 AM >>> > wrote: >>>> >>>> Hi Greg, >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> >>>> Med >>>> >>>> *De :* Greg Mirsky >>> > >>>> *Envoyé :* mercredi 16 février 2022 16:13 >>>> *À :* BOUCADAIR Mohamed INNOV/NET >>> > >>>> *Cc :* sfc@ietf.org >>>> *Objet :* Re: [sfc] TR: I-D Action: >>>> draft-boucadair-sfc-oam-packet-00.txt >>>> >>>> Hi Med, >>>> >>>> many thanks for taking the lead and putting the proposal on the >>> table. >>>> >>>> I have a question on the proposed new text for the O bit and its >>>> possible effect on IOAM: >>>> >>>>    O bit:  Setting this bit indicates an SFC OAM packet.  Such >>>> a packet >>>> >>>>       is any NSH-encapasulated packet that exclusively includes >>>> an OAM >>>> >>>>       command and/or OAM data. >>>> >>>> My understanding of the new definition of the O bit is that the >>> NSH >>>> includes and/or encapsulates only OAM command and/or data. IOAM, >>> as >>>> I understand its application in NSH, may follow the NSH and have >>>> user payload after the IOAM data. >>>> >>>> *//* >>>> >>>> */[Med] Packets that include also user data are not considered >> as >>>> “OAM packets” as per the new definition./* >>>> >>>> And another scenario, if Flow ID TLV is used to influence user >>> data >>>> through SFP, OAM will apply the same Flow ID value. Would such >>>> packet still be considered as "exclusively includes OAM command >>>> and/or data"? >>>> >>>> *//* >>>> >>>> */[Med] Yes, they are. Flow id is just a constraint, if you >> will, >>>> that is used to influence how OAM commands will be executed. /* >>>> >>>> Regards, >>>> >>>> Greg >>>> >>>> On Wed, Feb 16, 2022 at 6:40 AM >>> > wrote: >>>> >>>> Hi all, >>>> >>>> A proposal to clarify the intent of SFC OAM packet. Comments >>> are >>>> welcome. >>>> >>>> Cheers, >>>> Med >>>> >>>> -----Message d'origine----- >>>> De : I-D-Announce >>> > De la part de >>>> internet-drafts@ietf.org >>>> Envoyé : mercredi 16 février 2022 15:38 >>>> À : i-d-announce@ietf.org >>>> Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. >>>> >>>> >>>>         Title           : Clarifying Ambiguity related to >>>> Network Service Header (NSH) OAM Packet >>>>         Author          : Mohamed Boucadair >>>>         Filename        : draft-boucadair-sfc-oam-packet- >>> 00.txt >>>>         Pages           : 5 >>>>         Date            : 2022-02-16 >>>> >>>> Abstract: >>>>    This document clarifies an ambiguity in the Network >>> Service >>>> Header >>>>    (NSH) specification related to the handling of O- >> bit.  In >>>> particular, >>>>    this document clarifies the meaning of "OAM packet". >>>> >>>>    This document updates RFC8300. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam- >>> packet/ >>>> >>>> >>>> >>>> There is also an htmlized version available at: >>>> >>>> https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam- >>> packet-00 >>>> >>>> >>> t- >>>> 00> >>>> >>>> >>>> Internet-Drafts are also available by rsync at >>>> rsync.ietf.org::internet-drafts >>>> >>>> >>>> _______________________________________________ >>>> 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.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> >>>> ____________________________________________________________________ >>>> __ ___________________________________________________ >>>> >>>> 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. >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> >>>> >>>> ____________________________________________________________________ >>>> __ ___________________________________________________ >>>> >>>> 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. >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> ________________________________________________________________________ >> _________________________________________________ >> >> 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. >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _________________________________________________________________________________________________________________________ > > 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. > From nobody Thu Feb 24 05:59:31 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245943A1400 for ; Thu, 24 Feb 2022 05:59:28 -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, 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 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 Mg9g3bTugjvR for ; Thu, 24 Feb 2022 05:59:23 -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 4AB323A13FA for ; Thu, 24 Feb 2022 05:59:23 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) (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 opfedar21.francetelecom.fr (ESMTP service) with ESMTPS id 4K4DzY4SDfz7tVg; Thu, 24 Feb 2022 14:59:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645711161; bh=z6r1MqU3P+JrezG2+h17KA8hRlknS9wCGyoYyuIM7s8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=n8B4ob5U5DlSlqNIdVfw2vUq1V/iGO5PL1OPk1ui9xGtMpAz3V/E8g8HePK01chUw kOpU8dusjBpKztALl7BzNInXF2AybXDH8X6t2XO93FzwxmbXLGpttCZQDdFtSMc/Yj T+a2bZhz/2LnPNB9vrxFwh9ftqo6SrV6IU79j7GQeob1OhHXBcI+u8clI0v3euuJND 2Lwkz0M+1WNgvrLpcjCXIezwNSAtbnCOkv/DdIQ19ZEW3tbJFxzsWwup+oTcfSzXEk +AKLYUCGC3pIQ0X/A7VlsRUd9sElgVIt/dV+GuttEh++UO5tuj2QpzcVSVV6N6t6eb qf+SN7qdT/uzA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar01.francetelecom.fr (ESMTP service) with ESMTPS id 4K4DzY3HQnzBrLg; Thu, 24 Feb 2022 14:59:21 +0100 (CET) From: To: "Joel M. Halpern" , Greg Mirsky CC: "sfc@ietf.org" Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt Thread-Index: AQHYI0LOqTeC5k5EYkSp4mi5aRUmyqyiwYxMgAADgoA= Content-Class: Date: Thu, 24 Feb 2022 13:59:20 +0000 Message-ID: <18342_1645711161_62178F39_18342_314_1_787AE7BB302AE849A7480A190F8B9330354992A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <30956_1645025435_620D189B_30956_353_1_787AE7BB302AE849A7480A190F8B933035494DD5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <3535_1645028520_620D24A8_3535_225_1_787AE7BB302AE849A7480A190F8B933035494EAE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <5efa6354-4396-d1b1-bec3-122d2aa148c2@joelhalpern.com> <26440_1645082031_620DF5AF_26440_39_1_787AE7BB302AE849A7480A190F8B9330354954F7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <16224_1645689365_62173A15_16224_31_1_787AE7BB302AE849A7480A190F8B933035498F45@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-24T13:53:13Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=3f781148-7934-47ba-b5b3-6f19d1c32dd2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 13:59:28 -0000 UmUtLA0KDQpTdXJlLiBJIG1hZGUgc29tZSBtaW5vciBlZGl0cy4gVGhlIE5FVyB0ZXh0IGxvb2tz IGFzIGZvbGxvd3M6IA0KDQogICAgICBXaGVuIGFuIE9BTSBkYXRhIGlzIGluY2x1ZGVkIGluIHRo ZSBpbm5lciBwYWNrZXQsIHRoZSBOZXh0DQogICAgICBQcm90b2NvbCBmaWVsZCBpcyBzZXQgdG8g cmVmbGVjdCB0aGUgc3RydWN0dXJlIG9mIHRoYXQgaW5uZXIgT0FNDQogICAgICBwYWNrZXQuICBU aGUgc2V0dGluZyBhbmQgcHJvY2Vzc2luZyBvZiB0aGUgTyBiaXQgbmVpdGhlciBhc3N1bWVzDQog ICAgICBub3IgZXhwZWN0cyBkZXRhaWxlZCBhbmFseXNpcyBvZiB0aGUgY29udGVudCBvZiBhbnkg aW5uZXIgSVANCiAgICAgIHBhY2tldCBjYXJyaWVkIGJ5IHRoZSBOU0guICBBcyBzdWNoLCBTRkZz LCBTRkMtYXdhcmUgU0ZzLCBhbmQgU0ZDDQogICAgICBQcm94aWVzIFNIT1VMRCBkaXNjYXJkIGFu eSBOU0ggcGFja2V0cyB3aXRoIHRoZSBPIGJpdCBzZXQgYW5kIE5leHQNCiAgICAgIFByb3RvY29s IHNldCB0byBzb21ldGhpbmcgdGhhdCBpcyBub3QgaXRzZWxmIGFuIE9BTSBwcm90b2NvbC4NCiAg ICAgIFRoaXMgaW5jbHVkZXMgZGlzY2FyZGluZyB0aGUgcGFja2V0IHdoZW4gdGhlIE8gYml0IGlz IHNldCBhbmQgdGhlDQogICAgICBOZXh0IFByb3RvY29sIGlzIHNldCB0byAweDAxIChJUHY0KSwg MHgwMiAoSVB2NiksIDB4MDMgKE1QTFMpLCBvcg0KICAgICAgMHgwNSAoRXRoZXJuZXQpLg0KDQpU aGFua3MuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4gRGXCoDogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPiBFbnZvecOp wqA6IGpldWRpIDI0IGbDqXZyaWVyIDIwMjIgMTQ6NDANCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFt ZWQgSU5OT1YvTkVUIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgR3JlZw0KPiBNaXJz a3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4NCj4gQ2PCoDogc2ZjQGlldGYub3JnDQo+IE9iamV0 wqA6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFj a2V0LTAwLnR4dA0KPiANCj4gTWF5IGEgc3VnZ2VzdCBhIHNtYWxsIHJlZmluZW1lbnQ/DQo+ICAg ICAgVGhlIHNldHRpbmcgYW5kIHByb2Nlc3Npbmcgb2YgdGhlIE8gYml0IG5laXRoZXIgYXNzdW1l cyBub3IgZXhwZWN0cw0KPiBkZXRhaWxlZCBhbmFseXNpcyBvZiB0aGUgY29udGVudHMgb2YgYW55 IElQIHBhY2tldHMgY2FycmllZCBieSBOU0guICBBcw0KPiBzdWNoLCBTRkZzIGFuZCBTRnMgU0hP VUxEIGRpc2NhcmQgYW55IE5TSCBwYWNrZXRzIHdpdGggdGhlIE8gYml0IHNldCBhbmQNCj4gTmV4 dCBwcm90b2NvbCBzZXQgdG8gc29tZXRoaW5nIHRoYXQgaXMgbm90IGl0c2VsZiBhbiBPQU0gcHJv dG9jb2wuICBUSGlzDQo+IGluY2x1ZGVzIGRpc2NhcmRpbmcgdGhlIHBhY2tldCB3aGVuIE8gYml0 IGlzIHNldCBhbmQgdGhlIE5leHQgUHJvdG9jb2wNCj4gaXMgc2V0IHRvIDB4MDEgKElQdjQpLCAw eDAyIChJUHY2KSwgMHgwMyAoTVBMUyksIG9yIDB4MDUgKEV0aGVybmV0KS4NCj4gDQo+IFlvdXJz LA0KPiBKb2VsDQo+IA0KPiBPbiAyLzI0LzIwMjIgMjo1NiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSB3cm90ZToNCj4gPiBIaSBKb2VsLCBhbGwsDQo+ID4NCj4gPiBGV0lXLCBJIHVw ZGF0ZWQgLTAyIHdpdGggdGhlIGZvbGxvd2luZyB0byByZWZsZWN0IG9uZSBvZiB0aGUgcG9pbnRz DQo+IGRpc2N1c3NlZCBiZWxvdzoNCj4gPg0KPiA+ICAgICAgICBXaGVuIGFuIE9BTSBkYXRhIGlz IGluY2x1ZGVkIGluIHRoZSBpbm5lciBwYWNrZXQsIHRoZSBOZXh0DQo+ID4gICAgICAgIFByb3Rv Y29sIGZpZWxkIGlzIHNldCB0byByZWZsZWN0IHRoZSBzdHJ1Y3R1cmUgb2YgdGhhdCBpbm5lcg0K PiA+ICAgICAgICBwYWNrZXQuICBCeSBkZWZhdWx0LCBTRkZzIFNIT1VMRCBkaXNjYXJkIE5TSCBw YWNrZXRzIHdpdGggTyBiaXQNCj4gPiAgICAgICAgc2V0IGFuZCBOZXh0IFByb3RvY29sIHNldCB0 byAweDEgKElQdjQpLCAweDIgKElQdjYpLCAweDMNCj4gKE1QTFMpLA0KPiA+ICAgICAgICBvciAw eDUgKEV0aGVybmV0KS4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gRGXCoDogc2ZjIDxzZmMtYm91bmNlc0BpZXRm Lm9yZz4gRGUgbGEgcGFydCBkZQ0KPiA+PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIEVu dm95w6nCoDogamV1ZGkgMTcgZsOpdnJpZXIgMjAyMiAwODoxNCDDgMKgOg0KPiA+PiBKb2VsIE0u IEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+OyBHcmVnIE1pcnNreQ0KPiA+PiA8Z3JlZ2lt aXJza3lAZ21haWwuY29tPiBDY8KgOiBzZmNAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFtzZmNdIFRS OiBJLUQNCj4gPj4gQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQtMDAudHh0 DQo+ID4+DQo+ID4+IEhpIEpvZWwsDQo+ID4+DQo+ID4+PiBJZiB0aGUgTlNIIHBheWxvYWQgaXMg YW4gSVAgcGFja2V0LCBhbmQgdGhhdCBwYWNrZXQgaXMgYWRkcmVzc2VkIHRvDQo+ID4+PiBzb21l dGhpbmcgb3RoZXIgdGhhbiB0aGlzIG5vZGUsIGFuZCB0aGF0IHBhY2tldCBpcyBjYXJyeWluZyAg YW4gSUNNUA0KPiA+Pj4gZWNobywgaXMgdGhhdCBhbiBTRkMgT0FNIHBhY2tldCByZXF1aXJpbmcg dGhlIE8tYml0IGJlaW5nIHNldD8NCj4gPj4NCj4gPj4gTWVkOiBUaGUgTlNIIGNhbiBiZSBhZGRl ZCBieSBhIGNsYXNzaWZpZXIgb3IgZGlyZWN0bHkgYnkgYW4gU0ZDIE9BTQ0KPiA+PiBjb250cm9s bGVyIHRoYXQgaXNzdWVzIHRoZSBwYWNrZXQuIElmIHRoZSBvcmlnaW5hbCBJUC9JQ01QIHBhY2tl dCBpcw0KPiA+PiByZWNlaXZlZCBieSBhIGNsYXNzaWZpZXIsIHRoZSBjbGFzc2lmaWVyIG11c3Qg bm90IHNldCB0aGUgTyBiaXQgYXMNCj4gPj4gcGVyIGRyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLXBh Y2tldCBiZWNhdXNlIHRoYXQgcGFja2V0IGlzIHNlZW4gYXMNCj4gPj4gZGF0YSBwYWNrZXQuDQo+ ID4+DQo+ID4+IExldCdzIG5vdyBmb2N1cyBvbiB0aGUgU0ZDIE9BTSBjb250cm9sbGVyIGNhc2U6 DQo+ID4+ICogRG9lcyBpdCBtYWtlcyBzZW5zZSBmb3IgYW4gU0ZDIE9BTSBjb250cm9sbGVyIHRv ICJsZXZlcmFnZSIgSVAvSUNNUA0KPiA+PiBmb3IgU0ZDIE9BTSBwdXJwb3NlcyB3aGlsZSBpdCBj YW4gZG8gaXQgZGlyZWN0bHkgdXNpbmcgSUNNUCAod2l0aG91dA0KPiA+PiB0aGUgSVAgaGVhZGVy KT8NCj4gPj4NCj4gPj4gSSBwZXJzb25hbGx5IGRvbid0IHNlZSBhbnkuDQo+ID4+DQo+ID4+ICog RG9lcyBpdCBtYWtlcyBzZW5zZSBmb3IgYW4gU0ZDIE9BTSBjb250cm9sbGVyIHRvICJzdXBwbHki IGFuDQo+ID4+IElQL0lDTVAgYXMgYW4gaW5wdXQgZm9yIHNwZWNpZmljIE9BTSBwdXJwb3Nlcz8N Cj4gPj4NCj4gPj4gVGhpcyBpcyBpbiB0aGVvcnkgcG9zc2libGUgZm9yIFNGIHRlc3RpbmcgcHVy cG9zZXMgKGUuZy4sIHRlc3QgdGhlDQo+ID4+IGJlaGF2aW9yIG9mIGEgZmlyZXdhbGwgYWdhaW5z dCBzdWNoIHBhY2tldC4gVGhlIG91dHB1dCBvZiB0aGUgdGVzdA0KPiA+PiB3aWxsIGJlIHVzZWQg dG8gYXNzZXNzIGlmIHRoZSBGVyBjb25maWd1cmF0aW9uIGlzIE9LL05PSykuIEhvd2V2ZXIsDQo+ ID4+IHN1Y2ggdGVzdCBPQU0gcGFja2V0cyBoYXZlIHRvIGJlIHVuYW1iaWd1b3VzbHkgaWRlbnRp ZmllZCBhcyBzdWNoLg0KPiA+PiBUaGUgTmV4dCBQcm90b2NvbCB3b24ndCBiZSBzZXQgdG8gSVAg YnV0IHRvIHRoZSB2YWx1ZSBhc3NpZ25lZCB0byBhbg0KPiA+PiBPQU0gcHJvdG9jb2wuDQo+ID4+ DQo+ID4+ICAgIEFuZA0KPiA+Pj4gY29udmVyc2VseSwgaXMgYW4gU0ZGIHJlcXVpcmVkIHRvIGNo ZWNrIGZvciB0aGF0IGNhc2UgaWYgaXQgc2VlcyBhbg0KPiA+Pj4gTlNIIHdpdGggdGhlIE8tYml0 IHNldD8NCj4gPj4NCj4gPj4gTWVkOiBTRkZzIGhhdmUgdG8gc3VwcG9ydCBwb2xpY2llcyB3aGV0 aGVyIHNvbWUgT0FNIG1lc3NhZ2VzIGNhbiBiZQ0KPiA+PiBmb3J3YXJkZWQgdG8gU0ZzLiBUaGVz ZSBwb2xpY2llcyBtYXkgaW5jbHVkZSBhIGZpbHRlciBvbiB2YWxpZCBuZXh0DQo+ID4+IHByb3Rv Y29sIHZhbHVlcy4gSSBkb24ndCBoYXZlIGFuIG9iamVjdGlvbiB0byBkaXNjYXJkIGJ5IGRlZmF1 bHQNCj4gPj4gcGFja2V0cyB3aXRoIE8gYml0IHNldCBhbmQgbmV4dCBwcm90b2NvbCA9IElQL01Q TFMvRXRoZXJuZXQNCj4gPj4NCj4gPj4gQ2hlZXJzLA0KPiA+PiBNZWQNCj4gPj4NCj4gPj4+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+Pj4gRGXCoDogSm9lbCBNLiBIYWxwZXJuIDxq bWhAam9lbGhhbHBlcm4uY29tPiBFbnZvecOpwqA6IG1lcmNyZWRpIDE2DQo+ID4+PiBmw6l2cmll ciAyMDIyIDE3OjMwIMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElOTk9WL05FVA0KPiA+Pj4gPG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21h aWwuY29tPg0KPiA+PiBDYw0KPiA+Pj4gOiBzZmNAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFtzZmNd IFRSOiBJLUQgQWN0aW9uOg0KPiA+Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAw LnR4dA0KPiA+Pj4NCj4gPj4+IFRoYW5rIHlvdSBmb3Igd3JpdGluZyB0aGlzLiAgSSBsb29rIGZv cndhcmQgdG8gbW9yZSBkc2N1c3Npb24gYnkNCj4gPj4+IG1vcmUgV0cgbWVtYmVycy4NCj4gPj4+ DQo+ID4+PiBJIHdhbnQgdG8gYXNrIG9uZSBjbGFyaWZ5aW5nIHF1ZXNpdG9uIGFib3V0IGFuIGV4 YW1wbGUgdGhhdCB3YXMNCj4gPj4+IHJhaXNlZCBlYXJsaWVyLg0KPiA+Pj4NCj4gPj4+IElmIHRo ZSBOU0ggcGF5bG9hZCBpcyBhbiBJUCBwYWNrZXQsIGFuZCB0aGF0IHBhY2tldCBpcyBhZGRyZXNz ZWQgdG8NCj4gPj4+IHNvbWV0aGluZyBvdGhlciB0aGFuIHRoaXMgbm9kZSwgYW5kIHRoYXQgcGFj a2V0IGlzIGNhcnJ5aW5nICBhbiBJQ01QDQo+ID4+PiBlY2hvLCBpcyB0aGF0IGFuIFNGQyBPQU0g cGFja2V0IHJlcXVpcmluZyB0aGUgTy1iaXQgYmVpbmcgc2V0PyAgQW5kDQo+ID4+PiBjb252ZXJz ZWx5LCBpcyBhbiBTRkYgcmVxdWlyZWQgdG8gY2hlY2sgZm9yIHRoYXQgY2FzZSBpZiBpdCBzZWVz IGFuDQo+ID4+PiBOU0ggd2l0aCB0aGUgTy1iaXQgc2V0Pw0KPiA+Pj4NCj4gPj4+IFlvdXJzLA0K PiA+Pj4gSm9lbA0KPiA+Pj4NCj4gPj4+IE9uIDIvMTYvMjAyMiAxMToyMSBBTSwgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPj4+PiBSZS0sDQo+ID4+Pj4NCj4gPj4+PiBU aGlzIGlzIGRldGVybWluZWQgYnkgdGhlIGVudGl0eSB0aGF0IGlzc3VlcyB0aGUgT0FNIHBhY2tl dC4gVGhpcw0KPiA+Pj4+IGlzIHR5cGljYWxseSBhIGRlZGljYXRlZCBPQU0gY29udHJvbGxlciBv ciBhbiBTRkMgZWxlbWVudA0KPiA+Pj4+IChjbGFzc2lmaWVyIGZvciB0aGUgaW9hbSBjYXNlLCBm b3IgZXhhbXBsZSkuDQo+ID4+Pj4NCj4gPj4+PiBCVFcsIEkgdXBkYXRlZCB0aGUgZHJhZnQgdG8g cmVmbGVjdCB5b3VyIGNvbW1lbnRzIGFuZCBhbHNvIHRob3NlDQo+ID4+Pj4gZnJvbQ0KPiA+Pj4+ IEppbToNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYm91 Y2FkYWlyLXNmYy1vYW0tcGFja2V0LTAxDQo+ID4+Pj4gPGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQtMA0KPiA+Pj4+IDENCj4g Pj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IENoZWVycywNCj4gPj4+Pg0KPiA+Pj4+IE1lZA0KPiA+Pj4+ DQo+ID4+Pj4gKkRlwqA6KiBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPiAqRW52 b3nDqcKgOiogbWVyY3JlZGkgMTYNCj4gPj4+PiBmw6l2cmllciAyMDIyIDE2OjUyICrDgMKgOiog Qk9VQ0FEQUlSIE1vaGFtZWQgSU5OT1YvTkVUDQo+ID4+Pj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+ICpDY8KgOiogc2ZjQGlldGYub3JnICpPYmpldMKgOiogUmU6DQo+ID4+Pj4gW3Nm Y10NCj4gPj4+PiBUUjogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFja2V0 LTAwLnR4dA0KPiA+Pj4+DQo+ID4+Pj4gSGkgTWVkLA0KPiA+Pj4+DQo+ID4+Pj4gdGhhbmsgeW91 IGZvciB5b3VyIGV4cGVkaWVudMKgcmVzcG9uc2UuIEkgaGF2ZSBhIGZvbGxvdy11cCBxdWVzdGlv bjoNCj4gPj4+Pg0KPiA+Pj4+ICAgICAgSG93IGRvZXMgb25lIGRldGVybWluZSB0aGUgbmF0dXJl LCBPQU0gb3Igbm90LU9BTSwgb2YgZGF0YQ0KPiA+Pj4gZWxlbWVudHMNCj4gPj4+PiAgICAgIGlu IHRoZSBOU0ggQ29udGV4dCBoZWFkZXI/DQo+ID4+Pj4NCj4gPj4+PiBBcyBJIHVuZGVyc3RhbmQg aXQsIGRyYWZ0LWlldGYtc2ZjLW5zaC10bHYgZG9lcyBub3QgcHJvdmlkZSB0aGF0Lg0KPiA+Pj4+ IERvIHdlIG5lZWQgdG8gYWRkIGl0PyBBcHByZWNpYXRlIHlvdXIgdGhvdWdodHMgb24gdGhhdC4N Cj4gPj4+Pg0KPiA+Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4NCj4gPj4+PiBHcmVnDQo+ID4+Pj4NCj4g Pj4+PiBPbiBXZWQsIEZlYiAxNiwgMjAyMiBhdCA3OjMwIEFNIDxtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tDQo+ID4+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4g d3JvdGU6DQo+ID4+Pj4NCj4gPj4+PiAgICAgIEhpIEdyZWcsDQo+ID4+Pj4NCj4gPj4+PiAgICAg IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+Pj4+DQo+ID4+Pj4gICAgICBDaGVlcnMsDQo+ID4+Pj4N Cj4gPj4+PiAgICAgIE1lZA0KPiA+Pj4+DQo+ID4+Pj4gICAgICAqRGXCoDoqIEdyZWcgTWlyc2t5 IDxncmVnaW1pcnNreUBnbWFpbC5jb20NCj4gPj4+PiAgICAgIDxtYWlsdG86Z3JlZ2ltaXJza3lA Z21haWwuY29tPj4NCj4gPj4+PiAgICAgICpFbnZvecOpwqA6KiBtZXJjcmVkaSAxNiBmw6l2cmll ciAyMDIyIDE2OjEzDQo+ID4+Pj4gICAgICAqw4DCoDoqIEJPVUNBREFJUiBNb2hhbWVkIElOTk9W L05FVA0KPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+Pj4+ICAgICAgPG1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4NCj4gPj4+PiAgICAgICpDY8KgOiogc2Zj QGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+Pj4+ICAgICAgKk9iamV0wqA6KiBS ZTogW3NmY10gVFI6IEktRCBBY3Rpb246DQo+ID4+Pj4gICAgICBkcmFmdC1ib3VjYWRhaXItc2Zj LW9hbS1wYWNrZXQtMDAudHh0DQo+ID4+Pj4NCj4gPj4+PiAgICAgIEhpIE1lZCwNCj4gPj4+Pg0K PiA+Pj4+ICAgICAgbWFueSB0aGFua3MgZm9yIHRha2luZyB0aGUgbGVhZCBhbmQgcHV0dGluZyB0 aGUgcHJvcG9zYWwgb24NCj4gPj4+PiB0aGUNCj4gPj4+IHRhYmxlLg0KPiA+Pj4+DQo+ID4+Pj4g ICAgICBJIGhhdmUgYSBxdWVzdGlvbiBvbiB0aGUgcHJvcG9zZWQgbmV3IHRleHQgZm9yIHRoZSBP IGJpdCBhbmQNCj4gaXRzDQo+ID4+Pj4gICAgICBwb3NzaWJsZSBlZmZlY3Qgb24gSU9BTToNCj4g Pj4+Pg0KPiA+Pj4+ICAgICAgIMKgIMKgTyBiaXQ6wqAgU2V0dGluZyB0aGlzIGJpdCBpbmRpY2F0 ZXMgYW4gU0ZDIE9BTSBwYWNrZXQuDQo+ID4+Pj4gU3VjaCBhIHBhY2tldA0KPiA+Pj4+DQo+ID4+ Pj4gICAgICAgwqAgwqAgwqAgaXMgYW55IE5TSC1lbmNhcGFzdWxhdGVkIHBhY2tldCB0aGF0IGV4 Y2x1c2l2ZWx5DQo+ID4+Pj4gaW5jbHVkZXMgYW4gT0FNDQo+ID4+Pj4NCj4gPj4+PiAgICAgICDC oCDCoCDCoCBjb21tYW5kIGFuZC9vciBPQU0gZGF0YS4NCj4gPj4+Pg0KPiA+Pj4+ICAgICAgTXkg dW5kZXJzdGFuZGluZyBvZiB0aGUgbmV3IGRlZmluaXRpb24gb2YgdGhlIE8gYml0IGlzIHRoYXQN Cj4gPj4+PiB0aGUNCj4gPj4+IE5TSA0KPiA+Pj4+ICAgICAgaW5jbHVkZXMgYW5kL29yIGVuY2Fw c3VsYXRlcyBvbmx5IE9BTSBjb21tYW5kIGFuZC9vciBkYXRhLg0KPiA+Pj4+IElPQU0sDQo+ID4+ PiBhcw0KPiA+Pj4+ICAgICAgSSB1bmRlcnN0YW5kIGl0cyBhcHBsaWNhdGlvbiBpbiBOU0gsIG1h eSBmb2xsb3cgdGhlIE5TSCBhbmQNCj4gaGF2ZQ0KPiA+Pj4+ICAgICAgdXNlciBwYXlsb2FkIGFm dGVyIHRoZSBJT0FNIGRhdGEuDQo+ID4+Pj4NCj4gPj4+PiAgICAgICovLyoNCj4gPj4+Pg0KPiA+ Pj4+ICAgICAgKi9bTWVkXSBQYWNrZXRzIHRoYXQgaW5jbHVkZSBhbHNvIHVzZXIgZGF0YSBhcmUg bm90IGNvbnNpZGVyZWQNCj4gPj4gYXMNCj4gPj4+PiAgICAgIOKAnE9BTSBwYWNrZXRz4oCdIGFz IHBlciB0aGUgbmV3IGRlZmluaXRpb24uLyoNCj4gPj4+Pg0KPiA+Pj4+ICAgICAgQW5kIGFub3Ro ZXIgc2NlbmFyaW8sIGlmIEZsb3cgSUQgVExWIGlzIHVzZWQgdG8gaW5mbHVlbmNlIHVzZXINCj4g Pj4+IGRhdGENCj4gPj4+PiAgICAgIHRocm91Z2ggU0ZQLCBPQU0gd2lsbCBhcHBseSB0aGUgc2Ft ZSBGbG93IElEIHZhbHVlLiBXb3VsZCBzdWNoDQo+ID4+Pj4gICAgICBwYWNrZXQgc3RpbGwgYmUg Y29uc2lkZXJlZCBhcyAiZXhjbHVzaXZlbHkgaW5jbHVkZXMgT0FNDQo+IGNvbW1hbmQNCj4gPj4+ PiAgICAgIGFuZC9vciBkYXRhIj8NCj4gPj4+Pg0KPiA+Pj4+ICAgICAgKi8vKg0KPiA+Pj4+DQo+ ID4+Pj4gICAgICAqL1tNZWRdIFllcywgdGhleSBhcmUuIEZsb3cgaWQgaXMganVzdCBhIGNvbnN0 cmFpbnQsIGlmIHlvdQ0KPiA+PiB3aWxsLA0KPiA+Pj4+ICAgICAgdGhhdCBpcyB1c2VkIHRvIGlu Zmx1ZW5jZSBob3cgT0FNIGNvbW1hbmRzIHdpbGwgYmUgZXhlY3V0ZWQuDQo+ID4+Pj4gLyoNCj4g Pj4+Pg0KPiA+Pj4+ICAgICAgUmVnYXJkcywNCj4gPj4+Pg0KPiA+Pj4+ICAgICAgR3JlZw0KPiA+ Pj4+DQo+ID4+Pj4gICAgICBPbiBXZWQsIEZlYiAxNiwgMjAyMiBhdCA2OjQwIEFNIDxtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4+Pj4gICAgICA8bWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+PiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+ICAgICAgICAgIEhpIGFsbCwN Cj4gPj4+Pg0KPiA+Pj4+ICAgICAgICAgIEEgcHJvcG9zYWwgdG8gY2xhcmlmeSB0aGUgaW50ZW50 IG9mIFNGQyBPQU0gcGFja2V0Lg0KPiA+Pj4+IENvbW1lbnRzDQo+ID4+PiBhcmUNCj4gPj4+PiAg ICAgICAgICB3ZWxjb21lLg0KPiA+Pj4+DQo+ID4+Pj4gICAgICAgICAgQ2hlZXJzLA0KPiA+Pj4+ ICAgICAgICAgIE1lZA0KPiA+Pj4+DQo+ID4+Pj4gICAgICAgICAgLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+ID4+Pj4gICAgICAgICAgRGXCoDogSS1ELUFubm91bmNlIDxpLWQtYW5ub3Vu Y2UtYm91bmNlc0BpZXRmLm9yZw0KPiA+Pj4+ICAgICAgICAgIDxtYWlsdG86aS1kLWFubm91bmNl LWJvdW5jZXNAaWV0Zi5vcmc+PiBEZSBsYSBwYXJ0IGRlDQo+ID4+Pj4gICAgICAgICAgaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIDxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiA+ Pj4+ICAgICAgICAgIEVudm95w6nCoDogbWVyY3JlZGkgMTYgZsOpdnJpZXIgMjAyMiAxNTozOA0K PiA+Pj4+ICAgICAgICAgIMOAwqA6IGktZC1hbm5vdW5jZUBpZXRmLm9yZyA8bWFpbHRvOmktZC1h bm5vdW5jZUBpZXRmLm9yZz4NCj4gPj4+PiAgICAgICAgICBPYmpldMKgOiBJLUQgQWN0aW9uOiBk cmFmdC1ib3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQtMDAudHh0DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+ Pj4+ICAgICAgICAgIEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lDQo+ID4+Pj4gICAgICAgICAgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiA+ Pj4+DQo+ID4+Pj4NCj4gPj4+PiAgICAgICAgICAgwqAgwqAgwqAgwqAgVGl0bGXCoCDCoCDCoCDC oCDCoCDCoDogQ2xhcmlmeWluZyBBbWJpZ3VpdHkgcmVsYXRlZCB0bw0KPiA+Pj4+ICAgICAgICAg IE5ldHdvcmsgU2VydmljZSBIZWFkZXIgKE5TSCkgT0FNIFBhY2tldA0KPiA+Pj4+ICAgICAgICAg ICDCoCDCoCDCoCDCoCBBdXRob3LCoCDCoCDCoCDCoCDCoCA6IE1vaGFtZWQgQm91Y2FkYWlyDQo+ ID4+Pj4gICAgICAgICAgIMKgIMKgIMKgIMKgIEZpbGVuYW1lwqAgwqAgwqAgwqAgOiBkcmFmdC1i b3VjYWRhaXItc2ZjLW9hbS1wYWNrZXQtDQo+ID4+PiAwMC50eHQNCj4gPj4+PiAgICAgICAgICAg wqAgwqAgwqAgwqAgUGFnZXPCoCDCoCDCoCDCoCDCoCDCoDogNQ0KPiA+Pj4+ICAgICAgICAgICDC oCDCoCDCoCDCoCBEYXRlwqAgwqAgwqAgwqAgwqAgwqAgOiAyMDIyLTAyLTE2DQo+ID4+Pj4NCj4g Pj4+PiAgICAgICAgICBBYnN0cmFjdDoNCj4gPj4+PiAgICAgICAgICAgwqAgwqBUaGlzIGRvY3Vt ZW50IGNsYXJpZmllcyBhbiBhbWJpZ3VpdHkgaW4gdGhlIE5ldHdvcmsNCj4gPj4+IFNlcnZpY2UN Cj4gPj4+PiAgICAgICAgICBIZWFkZXINCj4gPj4+PiAgICAgICAgICAgwqAgwqAoTlNIKSBzcGVj aWZpY2F0aW9uIHJlbGF0ZWQgdG8gdGhlIGhhbmRsaW5nIG9mIE8tDQo+ID4+IGJpdC7CoCBJbg0K PiA+Pj4+ICAgICAgICAgIHBhcnRpY3VsYXIsDQo+ID4+Pj4gICAgICAgICAgIMKgIMKgdGhpcyBk b2N1bWVudCBjbGFyaWZpZXMgdGhlIG1lYW5pbmcgb2YgIk9BTSBwYWNrZXQiLg0KPiA+Pj4+DQo+ ID4+Pj4gICAgICAgICAgIMKgIMKgVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzgzMDAuDQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+ICAgICAgICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+Pj4+ICAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNhZGFpci1zZmMtb2FtLQ0KPiA+Pj4gcGFja2V0Lw0K PiA+Pj4+DQo+ID4+Pj4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJv dWNhZGFpci1zZmMtb2FtLXBhY2tldC8+DQo+ID4+Pj4NCj4gPj4+PiAgICAgICAgICBUaGVyZSBp cyBhbHNvIGFuIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiA+Pj4+DQo+ID4+Pj4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ib3VjYWRhaXItc2Zj LW9hbS0NCj4gPj4+IHBhY2tldC0wMA0KPiA+Pj4+DQo+ID4+Pj4gPGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYm91Y2FkYWlyLXNmYy1vYW0tcGFjaw0KPiA+Pj4+ IGUNCj4gPj4+PiB0LQ0KPiA+Pj4+IDAwPg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAgICAgICAg ICBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IHJzeW5jIGF0DQo+ID4+Pj4g ICAgICAgICAgcnN5bmMuaWV0Zi5vcmc6OmludGVybmV0LWRyYWZ0cw0KPiA+Pj4+DQo+ID4+Pj4N Cj4gPj4+PiAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+Pj4+ICAgICAgICAgIEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4gPj4+ PiAgICAgICAgICBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcgPG1haWx0bzpJLUQtQW5ub3VuY2VAaWV0 Zi5vcmc+DQo+ID4+Pj4gICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pLWQtYW5ub3VuY2UNCj4gPj4+PiAgICAgICAgICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U+DQo+ID4+Pj4gICAgICAgICAgSW50ZXJuZXQt RHJhZnQgZGlyZWN0b3JpZXM6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4g Pj4+PiAgICAgICAgICA8aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbD4gb3INCj4gPj4+ PiAgICAgICAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPiA+ Pj4+ICAgICAgICAgIDxmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dD4N Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+IF8gX18gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4NCj4gPj4+ PiAgICAgICAgICBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcw0KPiA+Pj4+ICAgICAgICAgIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQNCj4gPj4+IGRvbmMNCj4gPj4+PiAgICAgICAgICBw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4N Cj4gU2kNCj4gPj4+PiAgICAgICAgICB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+ID4+Pj4gICAgICAgICAgYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMNCj4gam9pbnRlcy4NCj4gPj4+IExl cw0KPiA+Pj4+ICAgICAgICAgIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiwNCj4gPj4+PiAgICAgICAgICBPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+ID4+PiBhbHRlcmUsDQo+ID4+Pj4g ICAgICAgICAgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+ID4+Pj4NCj4gPj4+PiAgICAg ICAgICBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwNCj4gb3INCj4gPj4+PiAgICAgICAgICBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+ID4+Pj4gICAgICAgICAgdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0DQo+ID4+Pj4gICAgICAgICAg YXV0aG9yaXNhdGlvbi4NCj4gPj4+PiAgICAgICAgICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5DQo+IHRoZQ0KPiA+Pj4+ICAgICAgICAgIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+Pj4+ ICAgICAgICAgIEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yDQo+ID4+Pj4gbWVzc2FnZXMNCj4gPj4+IHRoYXQNCj4gPj4+PiAgICAgICAgICBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+Pj4+ICAgICAgICAgIFRoYW5r IHlvdS4NCj4gPj4+Pg0KPiA+Pj4+ICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4gICAgICAgICAgc2ZjIG1haWxpbmcgbGlzdA0K PiA+Pj4+ICAgICAgICAgIHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4+ PiAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+ Pj4+ICAgICAgICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYz4N Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+IF8gX18gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4NCj4gPj4+ PiAgICAgIENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzDQo+ID4+Pj4gaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jDQo+ID4+Pj4NCj4gPj4+PiAgICAgIHBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaQ0KPiA+Pj4+IHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4g Pj4+Pg0KPiA+Pj4+ICAgICAgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4NCj4gPj4+PiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPiA+Pj4+DQo+ID4+Pj4gICAgICBPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+ID4+ Pj4gYWx0ZXJlLA0KPiA+Pj4gZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+ID4+Pj4NCj4g Pj4+PiAgICAgIFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvcg0KPiA+Pj4+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsNCj4gPj4+Pg0KPiA+Pj4+ICAgICAgdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0DQo+ID4+PiBhdXRob3Jpc2F0aW9u Lg0KPiA+Pj4+DQo+ID4+Pj4gICAgICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZQ0KPiA+Pj4+IHNlbmRlcg0KPiA+Pj4gYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gPj4+Pg0KPiA+Pj4+ICAgICAg QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMNCj4gPj4+PiB0aGF0DQo+ID4+PiBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLg0KPiA+Pj4+DQo+ID4+Pj4gICAgICBUaGFuayB5b3UuDQo+ID4+Pj4NCj4gPj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+Pj4gXyBfXyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4+Pg0KPiA+Pj4+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiA+Pj4+IGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlDQo+ ID4+Pj4gZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1DQo+ID4+Pj4gY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZQ0KPiA+Pj4+IGRldHJ1aXJlIGFpbnNpDQo+ ID4+PiBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudA0KPiA+Pj4gc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UNCj4gPj4+IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4gPj4+Pg0KPiA+Pj4+IFRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiA+Pj4+IHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91 bGQNCj4gPj4+PiBub3QNCj4gPj4+IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uDQo+ID4+Pj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ID4+Pj4gYW5kDQo+ID4+PiBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4+Pj4gQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdA0K PiA+Pj4+IGhhdmUNCj4gPj4+IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0K PiA+Pj4+IFRoYW5rIHlvdS4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBzZmMgbWFpbGluZyBsaXN0 DQo+ID4+Pj4gc2ZjQGlldGYub3JnDQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IF9fXyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+DQo+ID4+IENl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucw0KPiA+PiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywNCj4gPj4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZQ0KPiA+PiBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaQ0KPiA+PiBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMNCj4gPj4gZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+ID4+IGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+ID4+DQo+ID4+IFRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiA+PiBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxk IG5vdA0KPiA+PiBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLg0KPiA+PiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCj4gPj4gYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4NCj4gPj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlDQo+ID4+IGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+PiBUaGFuayB5b3UuDQo+ID4+DQo+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHNmYyBtYWls aW5nIGxpc3QNCj4gPj4gc2ZjQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPiBDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMNCj4gPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywNCj4gPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlDQo+ID4gcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kN Cj4gcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzDQo+IGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZQ0KPiBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLg0KPiA+DQo+ID4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yDQo+ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QNCj4gYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gPiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kDQo+IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gPiBB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUNCj4gYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+ID4g VGhhbmsgeW91Lg0KPiA+DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Thu Feb 24 06:02:50 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680973A0D29 for ; Thu, 24 Feb 2022 06:02:47 -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, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMAooxjwM_3u for ; Thu, 24 Feb 2022 06:02:42 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57AB3A0D1C for ; Thu, 24 Feb 2022 06:02:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4K4F2t53wzz1pMNt; Thu, 24 Feb 2022 06:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1645711334; bh=j4gFaENo366zIrPYDeVMDVxZQwSbus98FmYPiu4aEms=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=M86XsxFJl8scadXFOakVpgQZdDatTjVKd/UCo4FvHuOXUjbR289G0Ujt8ITqrZML5 Gpk6PcHrk1IJw/i+VqCLdI8d0Ay3ThZG5A7VGFNjAZJ9q68iw86ly3yn63FpxXr3MV 9PTtXNHJmfm42aEIpZgTZ+KNaXIpduSlEHfbU+Fk= X-Quarantine-ID: <7Ow6boHMxXf0> X-Virus-Scanned: Debian amavisd-new at b2.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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4K4F2t0vdNz1pGfr; Thu, 24 Feb 2022 06:02:13 -0800 (PST) Message-ID: <5067aa77-1131-987c-4420-993137e09c29@joelhalpern.com> Date: Thu, 24 Feb 2022 09:02:12 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: mohamed.boucadair@orange.com Cc: "sfc@ietf.org" References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <30956_1645025435_620D189B_30956_353_1_787AE7BB302AE849A7480A190F8B933035494DD5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <3535_1645028520_620D24A8_3535_225_1_787AE7BB302AE849A7480A190F8B933035494EAE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <5efa6354-4396-d1b1-bec3-122d2aa148c2@joelhalpern.com> <26440_1645082031_620DF5AF_26440_39_1_787AE7BB302AE849A7480A190F8B9330354954F7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <16224_1645689365_62173A15_16224_31_1_787AE7BB302AE849A7480A190F8B933035498F45@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <18342_1645711161_62178F39_18342_314_1_787AE7BB302AE849A7480A190F8B9330354992A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" In-Reply-To: <18342_1645711161_62178F39_18342_314_1_787AE7BB302AE849A7480A190F8B9330354992A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 14:02:48 -0000 Thanks. I think that captures it nicely. Yours, Joel On 2/24/2022 8:59 AM, mohamed.boucadair@orange.com wrote: > Re-, > > Sure. I made some minor edits. The NEW text looks as follows: > > When an OAM data is included in the inner packet, the Next > Protocol field is set to reflect the structure of that inner OAM > packet. The setting and processing of the O bit neither assumes > nor expects detailed analysis of the content of any inner IP > packet carried by the NSH. As such, SFFs, SFC-aware SFs, and SFC > Proxies SHOULD discard any NSH packets with the O bit set and Next > Protocol set to something that is not itself an OAM protocol. > This includes discarding the packet when the O bit is set and the > Next Protocol is set to 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or > 0x05 (Ethernet). > > Thanks. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern >> Envoyé : jeudi 24 février 2022 14:40 >> À : BOUCADAIR Mohamed INNOV/NET ; Greg >> Mirsky >> Cc : sfc@ietf.org >> Objet : Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt >> >> May a suggest a small refinement? >> The setting and processing of the O bit neither assumes nor expects >> detailed analysis of the contents of any IP packets carried by NSH. As >> such, SFFs and SFs SHOULD discard any NSH packets with the O bit set and >> Next protocol set to something that is not itself an OAM protocol. THis >> includes discarding the packet when O bit is set and the Next Protocol >> is set to 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or 0x05 (Ethernet). >> >> Yours, >> Joel >> >> On 2/24/2022 2:56 AM, mohamed.boucadair@orange.com wrote: >>> Hi Joel, all, >>> >>> FWIW, I updated -02 with the following to reflect one of the points >> discussed below: >>> >>> When an OAM data is included in the inner packet, the Next >>> Protocol field is set to reflect the structure of that inner >>> packet. By default, SFFs SHOULD discard NSH packets with O bit >>> set and Next Protocol set to 0x1 (IPv4), 0x2 (IPv6), 0x3 >> (MPLS), >>> or 0x5 (Ethernet). >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : sfc De la part de >>>> mohamed.boucadair@orange.com Envoyé : jeudi 17 février 2022 08:14 À : >>>> Joel M. Halpern ; Greg Mirsky >>>> Cc : sfc@ietf.org Objet : Re: [sfc] TR: I-D >>>> Action: draft-boucadair-sfc-oam-packet-00.txt >>>> >>>> Hi Joel, >>>> >>>>> If the NSH payload is an IP packet, and that packet is addressed to >>>>> something other than this node, and that packet is carrying an ICMP >>>>> echo, is that an SFC OAM packet requiring the O-bit being set? >>>> >>>> Med: The NSH can be added by a classifier or directly by an SFC OAM >>>> controller that issues the packet. If the original IP/ICMP packet is >>>> received by a classifier, the classifier must not set the O bit as >>>> per draft-boucadair-sfc-oam-packet because that packet is seen as >>>> data packet. >>>> >>>> Let's now focus on the SFC OAM controller case: >>>> * Does it makes sense for an SFC OAM controller to "leverage" IP/ICMP >>>> for SFC OAM purposes while it can do it directly using ICMP (without >>>> the IP header)? >>>> >>>> I personally don't see any. >>>> >>>> * Does it makes sense for an SFC OAM controller to "supply" an >>>> IP/ICMP as an input for specific OAM purposes? >>>> >>>> This is in theory possible for SF testing purposes (e.g., test the >>>> behavior of a firewall against such packet. The output of the test >>>> will be used to assess if the FW configuration is OK/NOK). However, >>>> such test OAM packets have to be unambiguously identified as such. >>>> The Next Protocol won't be set to IP but to the value assigned to an >>>> OAM protocol. >>>> >>>> And >>>>> conversely, is an SFF required to check for that case if it sees an >>>>> NSH with the O-bit set? >>>> >>>> Med: SFFs have to support policies whether some OAM messages can be >>>> forwarded to SFs. These policies may include a filter on valid next >>>> protocol values. I don't have an objection to discard by default >>>> packets with O bit set and next protocol = IP/MPLS/Ethernet >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Joel M. Halpern Envoyé : mercredi 16 >>>>> février 2022 17:30 À : BOUCADAIR Mohamed INNOV/NET >>>>> ; Greg Mirsky >>>> Cc >>>>> : sfc@ietf.org Objet : Re: [sfc] TR: I-D Action: >>>>> draft-boucadair-sfc-oam-packet-00.txt >>>>> >>>>> Thank you for writing this. I look forward to more dscussion by >>>>> more WG members. >>>>> >>>>> I want to ask one clarifying quesiton about an example that was >>>>> raised earlier. >>>>> >>>>> If the NSH payload is an IP packet, and that packet is addressed to >>>>> something other than this node, and that packet is carrying an ICMP >>>>> echo, is that an SFC OAM packet requiring the O-bit being set? And >>>>> conversely, is an SFF required to check for that case if it sees an >>>>> NSH with the O-bit set? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/16/2022 11:21 AM, mohamed.boucadair@orange.com wrote: >>>>>> Re-, >>>>>> >>>>>> This is determined by the entity that issues the OAM packet. This >>>>>> is typically a dedicated OAM controller or an SFC element >>>>>> (classifier for the ioam case, for example). >>>>>> >>>>>> BTW, I updated the draft to reflect your comments and also those >>>>>> from >>>>>> Jim: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-oam-packet-01 >>>>>> >>>>> 1 >>>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Med >>>>>> >>>>>> *De :* Greg Mirsky *Envoyé :* mercredi 16 >>>>>> février 2022 16:52 *À :* BOUCADAIR Mohamed INNOV/NET >>>>>> *Cc :* sfc@ietf.org *Objet :* Re: >>>>>> [sfc] >>>>>> TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt >>>>>> >>>>>> Hi Med, >>>>>> >>>>>> thank you for your expedient response. I have a follow-up question: >>>>>> >>>>>> How does one determine the nature, OAM or not-OAM, of data >>>>> elements >>>>>> in the NSH Context header? >>>>>> >>>>>> As I understand it, draft-ietf-sfc-nsh-tlv does not provide that. >>>>>> Do we need to add it? Appreciate your thoughts on that. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Greg >>>>>> >>>>>> On Wed, Feb 16, 2022 at 7:30 AM >>>>> > wrote: >>>>>> >>>>>> Hi Greg, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Med >>>>>> >>>>>> *De :* Greg Mirsky >>>>> > >>>>>> *Envoyé :* mercredi 16 février 2022 16:13 >>>>>> *À :* BOUCADAIR Mohamed INNOV/NET >> >>>>> > >>>>>> *Cc :* sfc@ietf.org >>>>>> *Objet :* Re: [sfc] TR: I-D Action: >>>>>> draft-boucadair-sfc-oam-packet-00.txt >>>>>> >>>>>> Hi Med, >>>>>> >>>>>> many thanks for taking the lead and putting the proposal on >>>>>> the >>>>> table. >>>>>> >>>>>> I have a question on the proposed new text for the O bit and >> its >>>>>> possible effect on IOAM: >>>>>> >>>>>>    O bit:  Setting this bit indicates an SFC OAM packet. >>>>>> Such a packet >>>>>> >>>>>>       is any NSH-encapasulated packet that exclusively >>>>>> includes an OAM >>>>>> >>>>>>       command and/or OAM data. >>>>>> >>>>>> My understanding of the new definition of the O bit is that >>>>>> the >>>>> NSH >>>>>> includes and/or encapsulates only OAM command and/or data. >>>>>> IOAM, >>>>> as >>>>>> I understand its application in NSH, may follow the NSH and >> have >>>>>> user payload after the IOAM data. >>>>>> >>>>>> *//* >>>>>> >>>>>> */[Med] Packets that include also user data are not considered >>>> as >>>>>> “OAM packets” as per the new definition./* >>>>>> >>>>>> And another scenario, if Flow ID TLV is used to influence user >>>>> data >>>>>> through SFP, OAM will apply the same Flow ID value. Would such >>>>>> packet still be considered as "exclusively includes OAM >> command >>>>>> and/or data"? >>>>>> >>>>>> *//* >>>>>> >>>>>> */[Med] Yes, they are. Flow id is just a constraint, if you >>>> will, >>>>>> that is used to influence how OAM commands will be executed. >>>>>> /* >>>>>> >>>>>> Regards, >>>>>> >>>>>> Greg >>>>>> >>>>>> On Wed, Feb 16, 2022 at 6:40 AM >>>>> > wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> A proposal to clarify the intent of SFC OAM packet. >>>>>> Comments >>>>> are >>>>>> welcome. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : I-D-Announce >>>>> > De la part de >>>>>> internet-drafts@ietf.org >>>>>> Envoyé : mercredi 16 février 2022 15:38 >>>>>> À : i-d-announce@ietf.org >>>>>> Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line >>>>>> Internet-Drafts directories. >>>>>> >>>>>> >>>>>>         Title           : Clarifying Ambiguity related to >>>>>> Network Service Header (NSH) OAM Packet >>>>>>         Author          : Mohamed Boucadair >>>>>>         Filename        : draft-boucadair-sfc-oam-packet- >>>>> 00.txt >>>>>>         Pages           : 5 >>>>>>         Date            : 2022-02-16 >>>>>> >>>>>> Abstract: >>>>>>    This document clarifies an ambiguity in the Network >>>>> Service >>>>>> Header >>>>>>    (NSH) specification related to the handling of O- >>>> bit.  In >>>>>> particular, >>>>>>    this document clarifies the meaning of "OAM packet". >>>>>> >>>>>>    This document updates RFC8300. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam- >>>>> packet/ >>>>>> >>>>>> >>>>>> >>>>>> There is also an htmlized version available at: >>>>>> >>>>>> https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam- >>>>> packet-00 >>>>>> >>>>>> >>>>> e >>>>>> t- >>>>>> 00> >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by rsync at >>>>>> rsync.ietf.org::internet-drafts >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> >>>>>> >>>>>> ___________________________________________________________________ >>>>>> _ __ ___________________________________________________ >>>>>> >>>>>> 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. >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> ___________________________________________________________________ >>>>>> _ __ ___________________________________________________ >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _____________________________________________________________________ >>>> ___ _________________________________________________ >>>> >>>> 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. >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> ______________________________________________________________________ >>> ___________________________________________________ >>> >>> 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. > From nobody Thu Feb 24 06:31:52 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781813A077A; Thu, 24 Feb 2022 06:31:48 -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 x9nTYGCzld29; Thu, 24 Feb 2022 06:31:43 -0800 (PST) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 739B23A0597; Thu, 24 Feb 2022 06:31:43 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id z22so3145598edd.1; Thu, 24 Feb 2022 06:31: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=oK/gt1/gLOZ0II2+9gBnubAQkqe7IUpTW++tAOF0iQU=; b=Tzb0xu83pd5s938a4HezoMzJ68D8hQYTdOzG4wzt2m6uG2I8WFGwkB0UWr3CLqU6/E VCBfaWdghvd30UAahdR4pJEo/ejYB0V7xAI5PTrduDCOeYmnNmm/cs9xsFjpk4Zc3oiR kiD7sbQ+H4KDWAA96eqf1xSRDk/8Swhh0zkWs/rMzO7t2qe6cVN1FtZsB5ENlYc5yip9 8t1kYoD1K9kLBP8vj+DakydewEHA/oql4c6jr6E85nqRagV/tmgsRnEpwZC58fXpiu7s 9USIEo4TIIMMgge3AolJQPIGk/3t6uHCrt7f9D5aBsE0vJxMT44p2zzdD2Dkm3JSg02h vmKQ== 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=oK/gt1/gLOZ0II2+9gBnubAQkqe7IUpTW++tAOF0iQU=; b=i8Dm2QrR4fAhCib77RT/oJclMr8B9lSIu9gnSrJ0criiLnIGfLT4fgfCONb2cu1wc3 CooNoLa/rOUl3ScZN6EjUNcXtAMDPLuI7mfZ+aXX+vHZIBBh1Xjh2r3ahD28xW+mNhtr E/wY5F+VlvDE2+4Bygd2FwIdLp554pU2OhISAap7yLE1AVjR+/R2TB0SGG/6/OGPMmkt j3QCHU0lGtoWiQgUVLavqXtQzT3Y2x9zwppqJkP4+h12WsS/iC/LFSMWfRciBhF+TWLW vwlDr9FkYHwcFMkCFLN8et/c4TI6vi/gxLrxiVx1qAAESlXckz+Xqm/kT0jPpHGvYVf3 EBTw== X-Gm-Message-State: AOAM5320XQHwQVI1YGd19hM2XHZ6Zp6IypOXkWRN450inq57akarhRXY 6PyHuCwjO423jjhj/ececd4Fi4D+oxbrvIzXcNQuSPmW X-Google-Smtp-Source: ABdhPJzSMLog728jUMXJB8E6agdQ7217yP78P16x0Cpcu382+eVryn1llvfmjsu05xsFbO05xP6U1CY1GGfFdlh5wC0= X-Received: by 2002:a05:6402:1435:b0:410:d2e1:e6dc with SMTP id c21-20020a056402143500b00410d2e1e6dcmr2607609edx.138.1645713101422; Thu, 24 Feb 2022 06:31:41 -0800 (PST) MIME-Version: 1.0 References: <164502226599.23621.11371897310173936133@ietfa.amsl.com> <14238_1645022412_620D0CCC_14238_64_1_787AE7BB302AE849A7480A190F8B933035494D1E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <17568_1645689462_62173A76_17568_471_1_787AE7BB302AE849A7480A190F8B933035498F57@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <17568_1645689462_62173A76_17568_471_1_787AE7BB302AE849A7480A190F8B933035498F57@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Greg Mirsky Date: Thu, 24 Feb 2022 06:31:29 -0800 Message-ID: To: Med Boucadair Cc: "sfc@ietf.org" , "draft-ietf-sfc-ioam-nsh@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d0201205d8c4703a" Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 14:31:49 -0000 --000000000000d0201205d8c4703a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, I agree with the changes you've proposed to the draft-ietf-sfc-multi-layer-oam . Regards, Greg On Wed, Feb 23, 2022 at 11:57 PM wrote: > Hi Greg, > > > > I hope to see it adopted as well. Thank you. > > > > If/once adopted, I expect Section 4.1 of draft-ietf-sfc-ioam-nsh (or at > least its normative language) to be removed but point to > draft-boucadair-sfc-oam-packet for O bit handling. > > > > Idem for Section 4 of draft-ietf-sfc-multi-layer-oam. > > > > Cheers, > > Med > > > > *De :* Greg Mirsky > *Envoy=C3=A9 :* jeudi 24 f=C3=A9vrier 2022 01:23 > *=C3=80 :* BOUCADAIR Mohamed INNOV/NET > *Cc :* sfc@ietf.org > *Objet :* Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt > > > > Hi Med, > > thank you for your proposal. I believe that it solves the problem and > helps the Active SFC OAM. If I may, I'm proposing the WG Chairs consider > the WG AP on this document. And for the record: > > I've read the document and support its adoption by the SFC WG. > > > > Regards, > > Greg > > > > On Wed, Feb 16, 2022 at 6:40 AM wrote: > > Hi all, > > A proposal to clarify the intent of SFC OAM packet. Comments are welcome. > > Cheers, > Med > > -----Message d'origine----- > De : I-D-Announce De la part de > internet-drafts@ietf.org > Envoy=C3=A9 : mercredi 16 f=C3=A9vrier 2022 15:38 > =C3=80 : i-d-announce@ietf.org > Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Clarifying Ambiguity related to Network Service > Header (NSH) OAM Packet > Author : Mohamed Boucadair > Filename : draft-boucadair-sfc-oam-packet-00.txt > Pages : 5 > Date : 2022-02-16 > > Abstract: > This document clarifies an ambiguity in the Network Service Header > (NSH) specification related to the handling of O-bit. In particular, > this document clarifies the meaning of "OAM packet". > > This document updates RFC8300. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam-packet/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-packet-00 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > _______________________________________________ > 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.ietf.org/ietf/1shadow-sites.txt > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _________________________________________________________________________= ________________________________________________ > > 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. > > --000000000000d0201205d8c4703a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=
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:23:48 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@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: [sfc] [spring] Comments on draft-saad-mpls-miad-usecases X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 22:23:19 -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:18 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@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: [sfc] [spring] Comments on draft-saad-mpls-miad-usecases X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining 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--
Hi Med,
I agree with the changes you've proposed t= o the draft-ietf-sfc-multi-layer-oam .

Regards,
Greg

On Wed, Feb 23, 2022 at 11:57 PM <mohamed.boucadair@orange.com> wrote:
=

Hi Greg,

=C2=A0

I hope to see it adopted as well. Thank you.<= u>

=C2=A0

If/once adopted, I expect Section 4.1 of draf= t-ietf-sfc-ioam-nsh (or at least its normative language) to be removed but = point to draft-boucadair-sfc-oam-packet for O bit handling.

=C2=A0

Idem for Section 4 of draft-ietf-sfc-multi-la= yer-oam.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Greg Mirsky <gregimirsky@gmail.com>
Envoy=C3=A9=C2=A0: jeudi 24 f=C3=A9vrier 2022 01:23
=C3=80=C2=A0: BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
Cc=C2=A0: sfc@ietf= .org
Objet=C2=A0: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packe= t-00.txt

=C2=A0

Hi Med,

thank you for your proposal. I believe that it solve= s=C2=A0the problem and helps the Active SFC OAM. If I may, I'm proposin= g the WG Chairs consider the WG AP on this document. And for the record:=

I've read the document and support its adoption = by the SFC WG.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Feb 16, 2022 at 6:40 AM <mohamed.boucadair@orange.= com> wrote:

Hi all,

A proposal to clarify the intent of SFC OAM packet. Comments are welcome.
Cheers,
Med

-----Message d'origine-----
De=C2=A0: I-D-Announce <i-d-announce-bounces@ietf.org> De la part de internet-draf= ts@ietf.org
Envoy=C3=A9=C2=A0: mercredi 16 f=C3=A9vrier 2022 15:38
=C3=80=C2=A0: i-= d-announce@ietf.org
Objet=C2=A0: I-D Action: draft-boucadair-sfc-oam-packet-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Clarifying Ambiguity related to Network Service Header (NSH) OAM Packet =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Moha= med Boucadair
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-bou= cadair-sfc-oam-packet-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2022-02-16

Abstract:
=C2=A0 =C2=A0This document clarifies an ambiguity in the Network Service He= ader
=C2=A0 =C2=A0(NSH) specification related to the handling of O-bit.=C2=A0 In= particular,
=C2=A0 =C2=A0this document clarifies the meaning of "OAM packet".=

=C2=A0 =C2=A0This document updates RFC8300.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-sfc-oa= m-packet/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-bouc= adair-sfc-oam-packet-00


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


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___________________________________________________________________________= ______________________________________________

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.

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

______________________________________________________________________=
___________________________________________________

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.
--000000000000d0201205d8c4703a-- From nobody Mon Feb 28 14:00:51 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@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: [sfc] [spring] Comments on draft-saad-mpls-miad-usecases X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining 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