Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FD7130E9D for ; Fri, 22 Feb 2019 07:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=K6i+R0QS; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=DE20JK3T Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccwxQXm9i7PP for ; Fri, 22 Feb 2019 07:39:52 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 8679F130E6E for ; Fri, 22 Feb 2019 07:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550849989; x=1553441989; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DjR0XNOT9wk/eK8f817dCnkkb/VW2GNEBt9cU7y41aE=; b=K6i+R0QS4XTBApm7iIdvjOGxWc3gucJdaXL9JevN79r6juhIcS1R9E9GOFSUEUTP /eAdMXjiQxDF0WmUEKzIc+RSLtANMT1rdi2sWRk+pIHShivbX2oiMo2PAo50PRTr gmWFj2K6Tdrf3QfVA95TDX3cyP6TWgsYNMY9RSE5SEU=; X-AuditID: c1b4fb25-209009e000005ff7-23-5c7017c511ad Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 04.42.24567.5C7107C5; Fri, 22 Feb 2019 16:39:49 +0100 (CET) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 22 Feb 2019 16:39:48 +0100 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 22 Feb 2019 16:39:48 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hPmzlGn+jw1nbA3vZ2gVBbXESzLbFkimt8uXFjP6M3g=; b=DE20JK3TZRTanJkcoO4xxqzfxl6E2ApD+WEys4G/rMnZID7bAb0+aIlArpNQQqTSz8yQyC+QjtxYEAoAOoo6qMIjYwTl62fNxQwFD8lvaA2pRL9htnwCH9eKr82AkujAq5LOE1CshuQKIfQyzTyw4Ra2lFSOVk9HqZZOhQx2JaY= Received: from BN6PR15MB1236.namprd15.prod.outlook.com (10.172.205.136) by BN6PR15MB1203.namprd15.prod.outlook.com (10.172.208.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Fri, 22 Feb 2019 15:39:45 +0000 Received: from BN6PR15MB1236.namprd15.prod.outlook.com ([fe80::2ce1:745d:5907:30c1]) by BN6PR15MB1236.namprd15.prod.outlook.com ([fe80::2ce1:745d:5907:30c1%5]) with mapi id 15.20.1643.018; Fri, 22 Feb 2019 15:39:45 +0000 From: Joel Halpern To: "Andrew G. Malis" , "Carlos Pignataro (cpignata)" CC: "ops-dir@ietf.org" , mpls , "draft-ietf-mpls-sfc-encapsulation.all@ietf.org" , IETF Discussion , "sfc@ietf.org" Thread-Topic: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02 Thread-Index: AQHUyZmooeeOlrGJcEi/lzVg6owG5qXqjRuAgAB/QwCAANX3gIAAE8pQ Date: Fri, 22 Feb 2019 15:39:44 +0000 Message-ID: References: <155072147698.20210.381511429964485828@ietfa.amsl.com> <6A97863A-DD90-4D62-9607-569386F5F850@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=joel.halpern@ericsson.com; x-originating-ip: [209.255.163.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2d989364-92ae-43ff-1f80-08d698dbf864 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR15MB1203; x-ms-traffictypediagnostic: BN6PR15MB1203: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjE1TUIxMjAzOzIzOnpxSVFYeXNjWG9qSjExNkcycjZNeFRUcGx2?= =?utf-8?B?dHBTd0V5U0wzMTIrL1U3ekYxdlNXV1lQODdsUWxvOWRrYktlZVQyL3pnUW1n?= =?utf-8?B?RkhDVVAzdm1QbXR4dTRuZ1R0MTlQcGRodHk3ZzNNMWZnU0YxWUFoMlhrZ0Ro?= =?utf-8?B?TlNCc25LL0RvbnROZUNDN1FIQjNrR0MrTExhclFUZEUrKysybzJmd2ZLN2kr?= =?utf-8?B?ejBJR1RYVDk3TEF4R2t2TEpodytGYlhNWmxIR3ozS2RkMnVLMWVHMzZSWmxR?= =?utf-8?B?bkNWWllMd2JUVElQOTFWNjdqV2RJRmZ1c1BhZzZvVW1COEVSTlFVZVZKYWpF?= =?utf-8?B?Qm9wdlhFTEhzVmYvaFgxTG4xL3J1UVY0SDl4VnArdmxVWE9pZUx2Yk1Kcmsw?= =?utf-8?B?cEUwcGNjMlBTMGgzTm5rb08vRUJPUXZ6K09kYlRhb0tHWm1NbWN5M2xlZVJp?= =?utf-8?B?QXpuN1lqUWhQZXJON2FabXdqRndFQXJZQjU4VzZObzJpNjdEaVNPLzlGUnkz?= =?utf-8?B?SWp2WG5lNmlFYVkxZHhaclduOWMrL2dDVnpQbTA0cmFTUFBDMVVxK2ZPOFNR?= =?utf-8?B?Mk96ajEzY1dSRHRTRDZCMWVSVm4vWGpCL2U2aVMxNjJneEdSS1lBMlRMQ0lJ?= =?utf-8?B?VmNITHRoaXpMNmZjL1hSeTgySUlsNVBqclJFbksreGsxYm5YV3N5Y1NFRmJS?= =?utf-8?B?bTc3RHVIZFlRVG1BdUo4T0pKTTlDQk1qVjJ4L1dadkt0VG1jc0Z6TVF3WXAw?= =?utf-8?B?T3VBb3FzWTRMTUFDR0QycTV4ODRiOW4zUDJwWnVNRVIrb29kSmwrS3ZvYlp6?= =?utf-8?B?WWJveU1Rdm9FL2cwY250aExGYnBpenAxU0pXYmpJK1Z3bjQvcjJvZ1p5Witn?= =?utf-8?B?TWh5L0ZZeXM1ajdIQ1FJZjIveFhHczU4bHFYVllxK3kvaER0VzBqR0VtcVUr?= =?utf-8?B?VHNpQnRzWWU1MHhvTzY5ZnhUN3VESDZURm5JTXpJUFRHREVnK1ArbG5KdWhB?= =?utf-8?B?ZllhWnJJNXJuL2xCcmRGMXl5L01hS0U4MndNS3NHaWI5MklTSDd3YSthOThw?= =?utf-8?B?Z1I5Q3BuMWczaVQzeEw0WU1uNWFBb3dBUHE3KzVXNUNNMWpDakh0aXZubUsx?= =?utf-8?B?bGphV2MrMW1DeTNjcFkvYkpEL3RCUzc1THhhMzB4LzRIRHdIK1pPWXZRT1Fr?= =?utf-8?B?SDgwdHE0ZG9ZTFc5TUN4bjBROFdkOWdXMXcxeHF0NFZYVEE2KzRoY3RMRTEx?= =?utf-8?B?cW9kdGp5NnRxZzgzNjJTRTUvbjdlNDlSK0hvMXhUUDhmN1R3aDM1bSthRlp5?= =?utf-8?B?S050UDg2Mi9RSnZBZDhPN3BrT1p5eld5bldmc0Fsa3AvNGwzMW9lVjhwQU1L?= =?utf-8?B?YjdLRFlmckNPWGphVERMWVR0UnlYdVRvRVptYlpJSE1CSDB2SHNEVHVqUjU2?= =?utf-8?B?RzNLc0FyUGpqbjJiWFBVdE5sK1NlUmwrQzhhdDVDeE8xYTFjcWliL041RVZ0?= =?utf-8?B?TXJUc2ZyUlhJTGZ1cnRYTDljMHZIRk84b0ltby9oMDgyU1c1UlAvUTQzRDMz?= =?utf-8?B?NmJydkxmczFVYUJMTlIySkhCZUhnVFFIWkhUSTMrY0JxTU13K25GbEZvS3Vl?= =?utf-8?B?Y29BQkN4S3NVcklINXdsSjByMVJxRTR1MndUT1p0Wm4xbUdJd3RGYzZqUHFa?= =?utf-8?B?WmFFS1NmWXlNK0F1ZlZrUklITit1QWdZMjlEQ3hBNm0zazJ1bE5YTXpTZ2Ex?= =?utf-8?B?dTJsMDQ2RzVja2FjVnRIdDF0a28yaFdWdzVNRU9Cb2R0d2VlYjVCZXV5OEFV?= =?utf-8?B?ajJzNnVWMzVOVmF6eXlRTU43RVZZbmQ5Y1ErN1MyblQ5eEVqZTNEbGIzUUlr?= =?utf-8?B?T2wvT2dRUnFQQzhDdG5UWTFyWThZUGQ5enhaVzUrb3JoMW5raElmL1d6cHdj?= =?utf-8?B?aFRvWlhlOVAzTk1vYU5KU2Z4TzhEUHd6YzZWQURTbjdESGhhK1dFUGlSeUpv?= =?utf-8?Q?+dSm8g?= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(366004)(39860400002)(376002)(189003)(199004)(51914003)(52314003)(51444003)(790700001)(6116002)(186003)(5660300002)(8936002)(7696005)(68736007)(3846002)(53936002)(4326008)(256004)(8676002)(81156014)(14444005)(316002)(76176011)(81166006)(53546011)(6506007)(6246003)(44832011)(110136005)(229853002)(97736004)(66066001)(6436002)(74316002)(54906003)(7736002)(93886005)(71200400001)(71190400001)(106356001)(25786009)(99936001)(33656002)(105586002)(99286004)(14454004)(478600001)(26005)(486006)(102836004)(86362001)(966005)(2906002)(55016002)(606006)(446003)(6306002)(11346002)(236005)(9686003)(54896002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR15MB1203; H:BN6PR15MB1236.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7ryHChmRvGFs+1szWEmXNd4k9u3N86O0rWpr9Why1Z3roVVrusq7XGz0GsBLY288uKyK9RgV3Nc1vIki1dLIFizc0q5WK1VORfuS7eG1e0/vlRSlJVWCg8OuSnT4q8eSJxLoncyflFhaUjJRqcOzwsEz+Zn0k0VKGFig7a4NJJNUxqUkypS2WnbdBLNt9B0rQjxcYXbKCz9+k9ltmGVq9dyk/nH7aOUVTOHkx+XNyLBvgtmSEf6+7PcKhKNBa0yXTuiaAGb4DYc52wcICTn8hZiyZLijUaOu1sCp9vZff1VbvM8DxABk2dS+iMpluYjzGNXbMU7fSg/8kzHC19qlQfIk7BU60LBCNHGlBCDA8gP4DW7EUKR6ICeaJuQyB42CQT6lmLMRDlxfuY6pI9uzG4dwIN+SChGjK4fFC+LI+38= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0128_01D4CA9A.EBF1E560" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2d989364-92ae-43ff-1f80-08d698dbf864 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 15:39:44.9722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR15MB1203 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSfUhTURjGO/fe3V2txXFNfbP6o6kUVrNPGPRBRYQElpVZ5NBWXky0Kfda ZBCJtUrLUjPBhfODTcsyXCR+YIkri7YyS8o0S+dmTRJD6UuN1bY7Iei/3/s+z3ne8x4OQ0pz 6RAmRZPJchp1mpz2p0oPNPIrOoIzVCtd+lCl9bOFVk6MNVHKZrMRKT+Zyilln/GWSJmfYyCV jsEG8WZxVPG0SRTVrPsgjjIYJokY8qD/hiQ2LeUEy0VuOuR/9HxpF5ExpSVPGs9V09nobC+R h/wYwGuhpqRFlIf8GSl+jKCyY5AWih8I9NZRJBQGAvQ3r4g9BYULSDBd6CYFpZiAkWGHL2AI wUfbRZEnmcYKqPtqd09hGBlOhLeGRI+HxE4ETws7KY9nHt4HZVY96WEZjoNrdzsIgbfD4/O9 Xg+Fw8HuGvN6JFgFI7+bKGHYWQJ6c0toj+CHd8P11kfewwgHwU/LHS+TOBj6HOW+VWVge2Wl BQ6EEbtLJPhVkNPeJxL6oWCrLSAFXgSvyy8hgaPBUqInPIMB2xEUvTT4giLgwfNSsSAMzIOi snxfUiqUfZ3y8UIoybHSgqmehrYbw95YKWahpk6LCtBy3T+31XnfqRBB7tOXlM67dwA8K3W4 mXEL8WDqzxL8yyDfpkUzXF35hRQ4Al686RH/398ITsuAr78Yii/ZfLwOvnSMowo0uxYF8ix/ +Fjy6jUKlks5wvPpGoWGzbyH3J+y/f50eBPqHt1iRphB8jmSBlmGSipSn+CzjplRmDtnqP52 FwqhNOkaVi6TPHGlq6SSJHXWKZZLT+SOp7G8GS1gKHmw5Lc0QCXFyepMNpVlM1huRiUYv5Bs lLkucXhzUUJ8/2RP7LZl86t+hR/nJk3JDxMuR8ZUDM/dWrV+T/PPvbMetLYFHLo6PkQHBoUa VzgVylRVoVEmaVE4LQHvtkZ/02gb2/+0OIKeu3S271FnRmM7K9/vSEo4XZ5lnBtXtf8UVx3c ltdvn1rSYC4Im8hvW+oUdckmtLt2yin+qHpVBMnx6r+UhOBonAMAAA== Archived-At: Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 15:39:56 -0000 ------=_NextPart_000_0128_01D4CA9A.EBF1E560 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0129_01D4CA9A.EBF1E560" ------=_NextPart_001_0129_01D4CA9A.EBF1E560 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable More generally, I do not think there is a requirement that SFF be only = one MPLS-hop apart. So I tend to doubt whether a reference to GTSM will = be helpful. Maybe I am missing the applicability? Yours, Joel =20 From: Andrew G. Malis =20 Sent: Friday, February 22, 2019 9:28 AM To: Carlos Pignataro (cpignata) Cc: ops-dir@ietf.org; mpls ; = draft-ietf-mpls-sfc-encapsulation.all@ietf.org; IETF Discussion = ; sfc@ietf.org Subject: Re: [mpls] Opsdir last call review of = draft-ietf-mpls-sfc-encapsulation-02 =20 Carlos, =20 Looks good on all but one point - I think I see why you're referencing = GTSM, since packets at the SFC layer would generally be one hop away = from each other at that layer. Is that correct? However, I really don't = have sufficient experience with GTSM to craft specific text. If you = think it's important enough to include, could you propose some text for = me to include? =20 Thanks again, Andy =20 =20 On Thu, Feb 21, 2019 at 8:41 PM Carlos Pignataro (cpignata) = > wrote: Hi, Andy,=20 =20 On Feb 21, 2019, at 1:06 PM, Andrew G. Malis > wrote: =20 Carlos, =20 Many thanks for your review! I'm also including the SFC WG on my reply. =20 Thanks for the quick response, and for considering the comments! =20 I enjoyed reading this document =E2=80=94 please see below. =20 Comments inline. =20 On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro > wrote: Reviewer: Carlos Pignataro Review result: Has Issues Reviewer: Carlos Pignataro Review Result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. = These comments were written with the intent of improving the operational = aspects of the IETF drafts. Comments that are not addressed in last call may be = included in AD reviews during the IESG review. Document editors and WG chairs = should treat these comments just like any other last call comments. This document is highly readable, includes very clear textual = descriptions, and is very well organized. Easy to read in its simplicity. However, it = would benefit from a more explicit connection to the transport encap mechanics = from RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding a Figure = or an SFF NSH Mapping Table example, to depict and/or exemplify the SFF = function. =20 I'm trying to envision what would make a good figure here. We could add = an additional line to Table 1 of RFC 8300 and reference that table: =20 +------+------+---------------------+-------------------------+ | SPI | SI | Next Hop(s) | Transport Encapsulation | +------+------+---------------------+-------------------------+ | 25 | 220 | Label 5467 | MPLS | +------+------+---------------------+-------------------------+ =20 Is that what you had in mind? If not, I'm open to other suggestions. =20 If you think it helps, this would be a good addition. =20 >From an Operational standpoint, the document seems largely appropriate = in terms of dataplane considerations. Some key considerations are explicitly out = of scope: The method used by the downstream receiving node to advertise SFF Labels to the upstream sending node is out of scope of this document. This really seems to mean that, with the simple definition in this Informational document, interoperable implementations cannot yet exist. = If there is no mechanism to advertise the SFF Label or to manage the = semantics of this particular label, how will it know? Static configuration, which is = not covered anyway, is not in my humble opinion a manageable scalable = approach. =20 Actually, while it is outside the scope of this document, it is within = the scope of draft-ietf-bess-nsh-bgp-control-plane, and text is being = added to the next revision of that draft to show how it can be used to = signal the encapsulation defined here. This was worked out after this = draft was forwarded to the IESG, but we can now add a reference to that = draft seeing as we'll be doing a post-last-call update. =20 I think that will help, as an Informative =E2=80=9Cone = embodiment=E2=80=9D type of link. =20 Title: MPLS Encapsulation For The SFC NSH RFC 8300 makes an explicit distinction between the terms 'encapsulation' = and 'transport encapsulation' (see e.g., Figure 1, Section 1.5 5., and = Section 4 of RFC 8300). It seems to me that this is the "MPLS Transport Encapsulation for the = SFC NSH" =20 Thanks, we'll fix that. =20 2. MPLS Encapsulation Using an SFF Label Similarly, "2. MPLS Transport Encapsulation Using an SFF Label" The encapsulation is a standard MPLS label stack [RFC3032] with an SFF Label at the bottom of the stack, followed by a NSH as defined by [RFC8300] and the NSH payload. Insteadf of "NSH payload" I think "orignal packet" is meant. =20 RFC 8300 uses both "payload" and "original packet/frame", but the latter = more than the former. So we can change "payload" to "original = packet/frame". =20 Also, this encapsulation is Underdefined: What is the value of TTL? TC? =20 I've been looking back at other related RFCs (such as PW and IP VPN = label definitions) and they're also mostly silent on these values. I did = find the following in RFC 6073: =20 The setting of the TTL of the PW MPLS label is a matter of local policy on the originating PE, but SHOULD be set to 255. =20 Regarding the TC, we can follow the example of RFC 6391: =20 This document does not define a use for the Traffic Class (TC) field [RFC5462 ] (formerly known as = the Experimental Use (EXP) bits [RFC3032 ]) in the flow label. = Future documents may define a use for these bits; therefore, implementations conforming to this specification MUST set the TC field to zero at the ingress and MUST ignore them at the egress. =20 Do you have any alternative suggestions? =20 These two approaches sounds good to me. And Ack to the other previous = responses. =20 Much like a pseudowire label, an SFF Label is allocated by the downstream receiver of the NSH from its per-platform label space. A PW Label is more restrictive. RFC 8077 says it MUST be allocated as per-platform: egress LSR only. Note that the PW label must always be at the bottom of the packet's label stack, and labels MUST be allocated from the per-platform label space. Is this the case for the SFF Label as well? If so, what is the = implication of the MUST? If not, why is it different than other equivalent similar = labels? =20 We can change the text to: =20 Much like a pseudowire label, an SFF Label MUST be allocated by the = downstream receiver of the NSH from its per-platform label space, since = the meaning of the label is identical independent of which incoming = interface it is received [RFC3031]. =20 =20 That=E2=80=99s a great improvement. 2. Push the SFF Label to identify the desired SFF in the receiving MPLS node. TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here. =20 As I noted above, 255, although I used RFC 6073 as my source rather than = 5082. We'll add that here as well. =20 =20 Sounds good. These protocols use 5082 in one form or another: = https://datatracker.ietf.org/doc/rfc5082/referencedby/ 4. Operations, Administration, and Maintenance (OAM) Considerations OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. However, OAM may be required at the MPLS transport layer. If so, then standard MPLS-layer OAM mechanisms such as the Generic Associated Channel [RFC5586] label may be used. RFC 5586 is _not_ an OAM mechanism. It is an associated channel creation mechanism, over which OAM could be carried. Thus, what traditional MPLS OAM can be carried here? Things like RFC = 4379 / RFC 8029 would need the definition of an SFF Label FEC (which does not = exist). Which other one? IP/ICMP seems of very limited value. =20 That's a good point about RFC 5586. The intention is that the MPLS OAM = would be at the transport label layer above the SFF label, so most any = MPLS-layer OAM would be applicable. So how about rewording to make that = more clear: =20 OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. = However, OAM may be required at the MPLS transport layer. If so, then = standard MPLS-layer OAM mechanisms may be used at the transport label = layer (the labels above the SFF label). =20 Looks good to me, thank you. =20 6. Security Considerations Have you considered the use of GTSM? =20 No, we hadn't. Can you point me to any examples of GTSM being used in an = MPLS or PW context? =20 Yes, see above. =20 8. References [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . SHould RFC 7665 be Normative? It defines the "SFF" which is quite = central to understanding this document. =20 Good point. It was there because 7665 is an Informational RFC, but RFC = 8067 does allow normative references to informational RFCs, so I'll move = it. =20 =20 Thank you. Other Nits and Editorials: SFF Labels are similar to other service labels at the bottom of an MPLS label stack that denote the contents of the MPLS payload being other than IP, such as a layer 2 pseudowire, an IP packet that is routed in a VPN context with a private address, or an Ethernet virtual private wire service. This says "being other than IP, such as IP", which seems to be self-contradictory :-) :-) =20 How about we change "other than IP," to "other than a normally routed IP = packet=E2=80=9D, =20 That would disambiguate it. =20 Thanks again. =20 To me, the control plane / advertisement was the most important = operationally-relevant comment. =20 Thanks, =20 Carlos. =20 Thanks again, Andy =20 ------=_NextPart_001_0129_01D4CA9A.EBF1E560 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

More = generally, I do not think there is a requirement that SFF be only one = MPLS-hop apart.=C2=A0 So I tend to doubt whether a reference to GTSM = will be helpful. =C2=A0=C2=A0Maybe I am missing the = applicability?

Yours,

Joel

 

From: = Andrew G. Malis <agmalis@gmail.com>
Sent: Friday, = February 22, 2019 9:28 AM
To: Carlos Pignataro (cpignata) = <cpignata@cisco.com>
Cc: ops-dir@ietf.org; mpls = <mpls@ietf.org>; draft-ietf-mpls-sfc-encapsulation.all@ietf.org; = IETF Discussion <ietf@ietf.org>; sfc@ietf.org
Subject: = Re: [mpls] Opsdir last call review of = draft-ietf-mpls-sfc-encapsulation-02

 

Carlos,

 

Looks good on all but one point - I think I see why = you're referencing GTSM, since packets at the SFC layer would = generally be one hop away from each other at that layer. Is that = correct? However, I really don't have sufficient experience with GTSM to = craft specific text. If you think it's important enough to include, = could you propose some text for me to = include?

 

Thanks again,

Andy

 

 

On = Thu, Feb 21, 2019 at 8:41 PM Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Hi, = Andy,

 

On Feb 21, 2019, at 1:06 PM, Andrew G. Malis <agmalis@gmail.com> = wrote:

 

Carlos,=

 <= /o:p>

Many thanks = for your review! I'm also including the SFC WG on my = reply.

 

Thanks for the quick response, and for considering the = comments!

 

I = enjoyed reading this document =E2=80=94 please see = below.



 <= /o:p>

Comments = inline.

 <= /o:p>

On Wed, Feb = 20, 2019 at 10:58 PM Carlos Pignataro <cpignata@cisco.com> = wrote:

Reviewer: = Carlos Pignataro
Review result: Has Issues

Reviewer: Carlos = Pignataro
Review Result: Has Issues

I have reviewed this = document as part of the Operational directorate's
ongoing effort to = review all IETF documents being processed by the IESG.  = These
comments were written with the intent of improving the = operational aspects of
the IETF drafts. Comments that are not = addressed in last call may be included
in AD reviews during the IESG = review.  Document editors and WG chairs should
treat these = comments just like any other last call comments.

This document is = highly readable, includes very clear textual descriptions, and
is = very well organized. Easy to read in its simplicity. However, it = would
benefit from a more explicit connection to the transport encap = mechanics from
RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend = adding a Figure or an
SFF NSH Mapping Table example, to depict and/or = exemplify the SFF function.

 <= /o:p>

I'm trying = to envision what would make a good figure here. We could add an = additional line to Table 1 of RFC 8300 and reference that = table:

 <= /o:p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+------+------+---------------------+-------------------------+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | =
SPI=C2=A0 | SI=C2=A0=C2=A0 | Next =
Hop(s)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Transport =
Encapsulation |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+------+------+---------------------+-------------------------+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | =
25=C2=A0=C2=A0 | 220=C2=A0 | Label =
5467=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | =
MPLS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+------+------+---------------------+-------------------------+

 <= /o:p>

Is that = what you had in mind? If not, I'm open to other = suggestions.

 

If you think it helps, this would be a good = addition.



<= p class=3DMsoNormal> <= /o:p>


>From= an Operational standpoint, the document seems largely appropriate in = terms
of dataplane considerations. Some key considerations are = explicitly out of
scope:
   The method used by the = downstream receiving node to advertise SFF
   Labels to the = upstream sending node is out of scope of this document.

This = really seems to mean that, with the simple definition in = this
Informational document, interoperable implementations cannot yet = exist. If
there is no mechanism to advertise the SFF Label or to = manage the semantics of
this particular label, how will it know? = Static configuration, which is not
covered anyway, is not in my = humble opinion a manageable scalable = approach.

 <= /o:p>

Actually, = while it is outside the scope of this document, it is within the scope = of draft-ietf-bess-nsh-bgp-control-plane, and text is being added = to the next revision of that draft to show how it can be used to signal = the encapsulation defined here. This was worked out after this draft was = forwarded to the IESG, but we can now add a reference to that draft = seeing as we'll be doing a post-last-call = update.

<= div>

 

I think that will help, as an Informative =E2=80=9Cone = embodiment=E2=80=9D type of link.



<= p class=3DMsoNormal> <= /o:p>


Title: = MPLS Encapsulation For The SFC NSH

RFC 8300 makes an explicit = distinction between the terms 'encapsulation' and
'transport = encapsulation' (see e.g., Figure 1, Section 1.5 5., and Section 4 = of
RFC 8300).

It seems to me that this is the "MPLS = Transport Encapsulation for the SFC = NSH"

 <= /o:p>

Thanks, = we'll fix that.

 <= /o:p>


2. = MPLS Encapsulation Using an SFF Label

Similarly, "2. MPLS = Transport Encapsulation Using an SFF Label"

   The = encapsulation is a standard MPLS label stack [RFC3032] with an
  =  SFF Label at the bottom of the stack, followed by a NSH as defined = by
   [RFC8300] and the NSH payload.

Insteadf of = "NSH payload" I think "orignal packet" is = meant.

 <= /o:p>

RFC 8300 = uses both "payload" and "original packet/frame", but = the latter more than the former. So we can change "payload" to = "original packet/frame".

 <= /o:p>


Also, = this encapsulation is Underdefined: What is the value of TTL? = TC?

 <= /o:p>

I've been = looking back at other related RFCs (such as PW and IP VPN label = definitions) and they're also mostly silent on these values. I did find = the following in RFC 6073:

 <= /o:p>

=C2=A0=C2=A0 =
The setting of the TTL of the PW MPLS
=C2=A0=C2=A0 =
label is a matter of local policy on the originating PE, but =
SHOULD
=C2=A0=C2=A0 be set to =
255.

 <= /o:p>

Regarding = the TC, we can follow the example of RFC = 6391:

 <= /o:p>

=C2=A0=C2=A0 =
This document does not define a use for the Traffic Class (TC) =
field
=C2=A0=C2=A0 [RFC5462] (formerly known as the Experimental Use (EXP) =
bits
=C2=A0=C2=A0 [RFC3032]) in the =
flow label.=C2=A0 Future documents may define a use =
for
=C2=A0=C2=A0 these bits; therefore, =
implementations conforming to this
=C2=A0=C2=A0 =
specification MUST set the TC field to zero at the ingress and =
MUST
=C2=A0=C2=A0 ignore them at the =
egress.

 <= /o:p>

Do you have = any alternative = suggestions?

 

These two approaches sounds good to me. And Ack to the = other previous responses.



<= p class=3DMsoNormal> <= /o:p>


  =  Much like a pseudowire label, an SFF Label is allocated by = the
   downstream receiver of the NSH from its per-platform = label space.

A PW Label is more restrictive. RFC 8077 says it = MUST be allocated as
per-platform:

   egress LSR = only.  Note that the PW label must always be at the = bottom
   of the packet's label stack, and labels MUST be = allocated from the
   per-platform label space.

Is = this the case for the SFF Label as well? If so, what is the implication = of
the MUST? If not, why is it different than other equivalent = similar labels?

 <= /o:p>

We can = change the text to:

 <= /o:p>

 Much = like a pseudowire label, an SFF Label MUST be allocated by the = downstream receiver of the NSH from its per-platform label space, since = the meaning of the label is identical independent of which incoming = interface it is received [RFC3031].

 <= /o:p>

 

That=E2=80=99s a great = improvement.




  =  2.  Push the SFF Label to identify the desired SFF in the = receiving
       MPLS node.

TTL value? 1? = 2? 255 for GTSM? GTSM RFC 5082 could be used = here.

 <= /o:p>

As I noted = above, 255, although I used RFC 6073 as my source rather than 5082. = We'll add that here as well.

 <= /o:p>

 

Sounds good.

These protocols use 5082 in one form or = another: https://datatracker.ietf.org/doc/rfc5082/referencedby/<= /a>



<= div>

 

Looks good to me, thank = you.



<= p class=3DMsoNormal> <= /o:p>


6. = Security Considerations

Have you considered the use of = GTSM?

 <= /o:p>

No, we = hadn't. Can you point me to any examples of GTSM being used in an MPLS = or PW = context?

=

 

Yes, see above.

That would disambiguate = it.

 

------=_NextPart_001_0129_01D4CA9A.EBF1E560-- ------=_NextPart_000_0128_01D4CA9A.EBF1E560 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVZzCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF+DCCA+CgAwIBAgIQ Rm7dpb6xLpDDWuklrtLDgTANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTgwMTA5 MTc1MDMxWhcNMjEwMTA5MTc1MDMwWjBmMREwDwYDVQQKDAhFcmljc3NvbjEVMBMGA1UEAwwMSm9l bCBIYWxwZXJuMSgwJgYJKoZIhvcNAQkBFhlqb2VsLmhhbHBlcm5AZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlaGFyam9lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyy2JgvRsHX1BlLY9 MsoWvInQ+gxmOCJOkcQ0KMcMKp5BosxeAajKJma3EGAxJh3M+Vj1FyjV5lT6rFRbn4Wk83Av2A2j kjIVSjhhmoZKIvi9U14I6K1Swo6citkrXxMNRxYlsGnPX9Zz68QZE2LJpxzHfxRpecrZDucOIFxR 7jGRvLKK+pfKOrtFwz/hnTG+shmPP7lZ7CEpukIKpz/wRfzVaX9zKLU7ORWoUeJ9aw19pOsEXxEn bW2Ra2qYPmqaA1HfDkEOJMmabq1Qt+0b6TgOcmy5qKzQd8uV8LhOH3ID1DE51q3QFT4Y1tDJuW5P 3D+Nj+90i/0WZaWtumO5lQIDAQABo4IBvzCCAbswSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2My5jZXIwJAYDVR0RBB0wG4EZam9lbC5oYWxwZXJuQGVyaWNzc29uLmNvbTBVBgNVHSAETjBM MEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3Qu dGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0O BBYEFH16/zJ9JH26dPyf8spTDrZy+WTuMB8GA1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZT MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAAfc8UKdtqvT0HtMgIOCwY5YN1l1I oU47l6nwym1jy8A+k/ZM5M5RsrSaNoALuDlSrDhyPFsIwAxeWXcuxzPJTTE+CptMkfTZg6CEfXY0 YiR7CiZfDCul36xBVQtXD3+8RyE8/4J+gbvArBkXkJTpqK9RhGBDyXLShNGQZVqQMQApLdnvTklF quy9b8VByKNjDBSGPnIAc3D6YGJYjOkPdR8P3B6Iv7/ysYnhUzy1d/6K1TDHghkSfNY5InD+h8Zm +F15n2WRc8mvQ8ZeYJ9uGT0C+cvh3oMFBm4BjOLxmGoF7bczT/ToIWFLYBYPRRhWAprUmVWBsmkl ZzYOJ80+W0oGIHT14YniJysOZaVrdkQEWzwJ4g9Xz4uzWaB6ThVcmkFCuoMMwQpCmobWz+EktXX5 bqMxPmtUvmAqueQsDzXhxFYCgawN9px2HbFPiz+vd/XiWJp+5F4xkNlAyyDu/l9PyhvyZ7vz1V5s 03FO5hOabZ7c4wgbo0VYU0zuhLIhabwVw/p2t3wsN/T6Ma8H/RjbfVWPaVYR4Rz1y/imF/26SuMe WzTnMGfytdA+rzAagxZUmtzg3yN7MHGsdbB9RtNH/0g4Q57s3CUNmnGrJzx8ciui9oFGKegdDFeu GqcAqC5Dlp83BQpngkFtFmrRa+Gutq6HsXL6LgyIo0ZYPB8wggbCMIIEqqADAgECAhBTuH6D4ZyZ KJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0Nlow RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKn u9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQ of1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/f DL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36p nb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U +86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiM j9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt 7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9u WhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2l FJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgw ggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlh c29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25l cmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0g BE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRy dXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA92Nzj kWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOC AgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkj TFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGg e5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx 0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDD TDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A +w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGj zZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJC mpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN 4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmP lpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UE AwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQRm7dpb6xLpDDWuklrtLDgTAJBgUrDgMC GgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTAyMjIx NTM5NDNaMCMGCSqGSIb3DQEJBDEWBBQcyTrXverzEfcxuCZegzPwvZf+3zBDBgkqhkiG9w0BCQ8x NjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjBq BgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UE AwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQRm7dpb6xLpDDWuklrtLDgTBsBgsqhkiG 9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBGbt2lvrEukMNa6SWu0sOBMA0GCSqGSIb3DQEB AQUABIIBABVdxR2tZ1oBCsUI7NPCeFpwZ2Q3V1ka7IbXg1WxIGM5OsZdGKqQTuZV76CcyKgKmfWP nnQZ1qJkUnlH5mAb5N+mWjCLfUpAEDEioHnh/nm4T1wVI2ZVLcH6/kINSv9zBK6GwjoZ7ICk4b+V Aj+u5e7WGF2NK+IuZAndEdntgBuD1dZZevTHx+Wj5y45AuqnFqzK19B9HBAg7S0fliSjoaCq22Pa /7YLlp0bCS1rYdESDajY+M5eWmIYAoqzHnciDiU+AU7pABz1XPC3QO35hJZuBBWU9oEbGovFLCI4 +wqWlxLUIJYi5RFH1csrXFUxxZNZUAvJXNlfmwJfPPQ26KcAAAAAAAA= ------=_NextPart_000_0128_01D4CA9A.EBF1E560--