From nobody Wed Aug 2 10:34:52 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE12131F3C; Wed, 2 Aug 2017 10:34:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org, teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150169528547.5719.14326487474057494500.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 10:34:45 -0700 Archived-At: Subject: [Teas] Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 17:34:45 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-teas-gmpls-lsp-fastreroute-10: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- What stops me from just providing a random IP address that I don't control in BYPASS_ASSIGNMENT and thus causing them to get spammed? I am assuming there are mechanisms to prevent them, but it's not immediately clear to me what those are, so they at minimum need to spelled out in security considerations. This section from RFC 4090 is not encouraging: This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RSVP] remain relevant. Note that the facility backup method requires that a PLR and its selected merge point trust RSVP messages received from each other. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- You refer to Figure 2 on page 3 and it appears on page 12. Probably either you should move it up or make a copy. From nobody Wed Aug 2 11:32:14 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2935131CC6; Wed, 2 Aug 2017 11:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPpqRnYvqVbc; Wed, 2 Aug 2017 11:32:05 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D7F131CB5; Wed, 2 Aug 2017 11:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3240; q=dns/txt; s=iport; t=1501698724; x=1502908324; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=quapxZzHTW+0+9uPnygUGZca9Rx0UsJKEzalZLUpR9Q=; b=aQFVuFvN144quEU5QK04vZWMiiFw5SK6pFKjw1jgyQU3UYexHwLF0OoI +SllfGIdgY6u1XSXsVHRZyGxwz8Kh4p0wozZaQjlJ3hdPl+AfE+sxUH5I 81hg0DAXke7L6sPTFEiZgSPOEZOdL+ZQ4kU2CNh+goMWlpWL8ftG6q6ze 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwAAAgGYJZ/5xdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkgRQHjgeQA5d+DoIELIUbAhqEGz8YAQIBAQEBAQEBayiFGQYjEUU?= =?us-ascii?q?QAgEIDgwCHwcCAgIwFRACBAENBYovEK4LgiaLSwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFgQuCHYICgUyCDoJ8hDEPARIBNiECglkwgjEFiWyWEAKHUYxZgg2FVop?= =?us-ascii?q?hlXoBHzh/C3cVWwGFOYFOdgGHOYEjgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,312,1498521600"; d="scan'208";a="463455132" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2017 18:32:04 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v72IW34G000357 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2017 18:32:03 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Aug 2017 13:32:03 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Wed, 2 Aug 2017 13:32:02 -0500 From: "Rakesh Gandhi (rgandhi)" To: Eric Rescorla , The IESG CC: "draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org" , "teas-chairs@ietf.org" , "vbeeram@juniper.net" , "teas@ietf.org" , DEBORAH BRUNGARD Thread-Topic: Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) Thread-Index: AQHTC7WkdEEClqfHX0mIbjS16X5NwaJxdPGA Date: Wed, 2 Aug 2017 18:32:02 +0000 Message-ID: References: <150169528547.5719.14326487474057494500.idtracker@ietfa.amsl.com> In-Reply-To: <150169528547.5719.14326487474057494500.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.247.50] Content-Type: text/plain; charset="utf-8" Content-ID: <00581035CA3503498EA9DF6589A85A10@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 18:32:07 -0000 SGkgRXJpYywNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IGFuZCB5b3VyIGNvbW1lbnRzLiBQ bGVhc2Ugc2VlIGluLWxpbmUgd2l0aCA8Ukc+Lg0KDQpPbiAyMDE3LTA4LTAyLCAxOjM0IFBNLCAi RXJpYyBSZXNjb3JsYSIgPGVrckBydGZtLmNvbT4gd3JvdGU6DQoNCiAgICBFcmljIFJlc2Nvcmxh IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgIGRyYWZ0 LWlldGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGUtMTA6IERpc2N1c3MNCiAgICANCiAgICBX aGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCBy ZXBseSB0byBhbGwNCiAgICBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBD QyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KICAgIGludHJvZHVjdG9yeSBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KICAgIA0KICAgIA0KICAgIFBsZWFzZSByZWZlciB0byBodHRwczovL3d3 dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCiAgICBmb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z Lg0KICAgIA0KICAgIA0KICAgIFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLXRlYXMtZ21wbHMtbHNwLWZhc3RyZXJvdXRlLw0KICAgIA0K ICAgIA0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBESVNDVVNTOg0KICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCiAgICANCiAgICBXaGF0IHN0b3BzIG1lIGZyb20ganVzdCBwcm92aWRpbmcgYSByYW5k b20gSVAgYWRkcmVzcw0KICAgIHRoYXQgSSBkb24ndCBjb250cm9sIGluIEJZUEFTU19BU1NJR05N RU5UIGFuZCB0aHVzDQogICAgY2F1c2luZyB0aGVtIHRvIGdldCBzcGFtbWVkPyBJIGFtIGFzc3Vt aW5nIHRoZXJlIGFyZQ0KICAgIG1lY2hhbmlzbXMgdG8gcHJldmVudCB0aGVtLCBidXQgaXQncyBu b3QgaW1tZWRpYXRlbHkNCiAgICBjbGVhciB0byBtZSB3aGF0IHRob3NlIGFyZSwgc28gdGhleSBh dCBtaW5pbXVtIG5lZWQNCiAgICB0byBzcGVsbGVkIG91dCBpbiBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucy4gVGhpcyBzZWN0aW9uDQogICAgZnJvbSBSRkMgNDA5MCBpcyBub3QgZW5jb3VyYWdpbmc6 DQogICAgDQogICAgICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbnRyb2R1Y2UgbmV3IHNlY3Vy aXR5IGlzc3Vlcy4gIFRoZSBzZWN1cml0eQ0KICAgICAgIGNvbnNpZGVyYXRpb25zIHBlcnRhaW5p bmcgdG8gdGhlIG9yaWdpbmFsIFJTVlAgcHJvdG9jb2wgW1JTVlBdIHJlbWFpbg0KICAgICAgIHJl bGV2YW50Lg0KICAgIA0KICAgICAgIE5vdGUgdGhhdCB0aGUgZmFjaWxpdHkgYmFja3VwIG1ldGhv ZCByZXF1aXJlcyB0aGF0IGEgUExSIGFuZCBpdHMNCiAgICAgICBzZWxlY3RlZCBtZXJnZSBwb2lu dCB0cnVzdCBSU1ZQIG1lc3NhZ2VzIHJlY2VpdmVkIGZyb20gZWFjaCBvdGhlci4NCiAgICANCg0K PFJHPiBPaywgaG93IGFib3V0IGFkZGluZyBmb2xsb3dpbmcgdGV4dCBpbiB0aGUgc2VjdXJpdHkg c2VjdGlvbj8NCg0K4oCcVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHBlcnRhaW5pbmcgdG8g dGhlIG9yaWdpbmFsIFJTVlAgcHJvdG9jb2wgW1JGQzIyMDVdIGFzIHdlbGwgYXMgRmFzdCBSZXJv dXRlIHByb2NlZHVyZXMgZGVzY3JpYmVkIGluIFtSRkM0MDkwXSByZW1haW4gcmVsZXZhbnQgdG8g dGhlIHVwZGF0ZXMgaW4gdGhpcyBkb2N1bWVudC7igJ0NCg0KDQogICAgDQogICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KICAgIENPTU1FTlQ6DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgIFlvdSByZWZl ciB0byBGaWd1cmUgMiBvbiBwYWdlIDMgYW5kIGl0IGFwcGVhcnMgb24gcGFnZSAxMi4NCiAgICBQ cm9iYWJseSBlaXRoZXIgeW91IHNob3VsZCBtb3ZlIGl0IHVwIG9yIG1ha2UgYSBjb3B5Lg0KICAg IA0KICAgIA0KPFJHPiBPaywgd2UgY2FuIGZpeCBpdCBhcyBwYXJ0IG9mIHRoZSBuZXh0IGVkaXRz Lg0KDQpUaGFua3MsDQpSYWtlc2gNCg0KDQoNCg0K From nobody Wed Aug 2 12:00:58 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AAB13215D; Wed, 2 Aug 2017 12:00:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org, teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150170045164.5759.13003373677933598821.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 12:00:51 -0700 Archived-At: Subject: [Teas] Alia Atlas' Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 19:00:52 -0000 Alia Atlas has entered the following ballot position for draft-ietf-teas-gmpls-lsp-fastreroute-10: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1) In Sec 4.5.1: "The downstream PLR can assign a bypass tunnel when processing the first Path message of the protected LSP, however, it can not update the forwarding plane until it receives the Resv message containing the downstream MP label." Please explain how the downstream PLR can assign a bypass tunnel if the LSP has a loose ERO - so the downstream PLR does not know the next-next-hop that would be the MP for a node-protecting LSP. 2) Sec 4.5.1: "An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT subobjects in the Path RRO in order to assign a reverse bypass tunnel. The upstream PLR that detects a BYPASS_ASSIGNMENT subobject, selects a reverse bypass tunnel that terminates locally with the destination address and tunnel-ID from the subobject, and has a source address matching the Node-ID address." This isn't very clear - particularly given that there will be many BYPASS_ASSIGNMENT subobjects in the path RRO. The case of BYPASS_ASSIGNMENT sub-objects being removed or changed is not addressed at all. In addition, I *assume* that the failure to treat the destination IP address in the BYPASS_ASSIGNMENT as the source IP address for the upstream Bypass tunnel is an oversight? I believe that what is meant is: "An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT sub-objects in the Path RRO to see if the destination IP address in the BYPASS_ASSIGNMENT matches an address of the upstream PLR. For each BYPASS_ASSIGNMENT sub-object that matches, the upstream PLR looks for a local bypass tunnel that has a destination matching the downstream PLR that inserted the BYPASS_ASSIGNMENT, as indicated by the Node-ID address, and the same tunnel-ID as indicated in the BYPASS_ASSIGNMENT." I recall that tunnel-ID is usually scoped by the address of the ingress LSR; this seems to assume that the same tunnel-ID is provided to both the downstream PLR and upstream PLR??? Alternately, I am misunderstanding - and the information in the BYPASS_ASSIGNMENT is really intended to be bypass tunnel to be used by the upstream PLR, which the downstream PLR somehow(??details, hints in the document please) knows . Then there needs to be text to handle the case where the previous PATH message contained a particular BYPASS_ASSIGNMENT sub-object and that sub-object has been removed or changed. 3) Sec 4.5.3: "In both examples above, the upstream PLR SHOULD send a Notify message [RFC3473] with Error-code - FRR Bypass Assignment Error (value: TBA1) and Sub-code - Bypass Assignment Cannot Be Used (value: TBA2) to the downstream PLR to indicate that it cannot use the bypass tunnel assignment in the reverse direction. Upon receiving this error, the downstream PLR MAY remove the bypass tunnel assignment and select an alternate bypass tunnel if one available." This section is problematic because it creates the use of local policy when the ingress has a clear way to signal what type of protection is desired and because it provides an error message to where it will only cause pointless churn (the MP is the MP based on the type of protection desired - certainly for bypass) rather than to the ingress where it could at least be acted upon. The dynamics at time of failure also do not seem to be well considered; asymmetry is unfortunate, but worse is lack of protection. Consider the case in Example 1. If R5 suffers a node failure, then there is no protection for the upstream LSP from R6 if it prefers the link protection. It simply doesn't matter what bypass tunnel R4 picks! Sending a Notify message to R4 asking for a different tunnel is not productive. If the ingress has requested node-protection, then there is simply nothing that can be done for this topology by R5. It could be helpful to send a Notify to the ingress or have a flag set in the RESV RRO to indicate the issue, but that's about it. For the question about creating local policy, how are the SESSION_ATTRIBUTES used? Obviously, they are available in the PATH message that has the BYPASS_ASSIGNMENTs. Why would the "Node Protection Desired" flag not be relevant here? 4) Sec 5: " o Upstream PLR reroutes traffic upon detecting the link failure or upon receiving RSVP Path message over the bidirectional bypass tunnel. o Upstream PLR also reroutes RSVP Resv signaling after receiving RSVP Path message over the bidirectional bypass tunnel. " How does the upstream PLR detect that the message was received over the bypass tunnel? Is the assumption that the bypass LSP doesn't do penultimate hop popping? Is the assumption that the PLR can tell because RSVP indicates the downstream PLR as the previous hop in its signaling? Please clarify and describe how this detection is done - to ease interoperability. 5) In Sec 5.1.2: "When upstream PLR R4 receives the protected LSP Path messages over the restored link, if not already done, it starts sending Resv messages and traffic flow of the protected LSP over the restored link and stops sending them over the bypass tunnel." Is there a reason that "when the downstream PLR receives the protected LSP RESV messages over the restored link, if not already done, it starts sending Path messages and traffic flow of the protected LSP over the restored link and stops sending them over the bypass tunnel." doesn't also make sense to put in this section? If this is not a good idea, please explain clearly the issues that it causes. I am assuming that "after the link is restored" implies that bidirectional communication has been successfully tested - not merely that the physical layer is up but also that an IGP or BFD is successful across it. (But this is standard for RSVP-TE FRR). 6) Sec 5.2.2: The behavior of R4 is not described. When the link from R3-R4 fails, R4 will redirect traffic to R2. As written at the start of Sec 5, R4 does not start sending its Resv across the bypass tunnel and R2 is thus not triggered to use its bypass tunnel. Please clearly describe this and why. It is this asymmetry in behavior for the downstream PLR and upstream PLR that causes the downstream PLR's bypass tunnel to be prioritized. 7) Sec 5.2.2: The need for the PRR to look up the bypass tunnel and then reprogram the forwarding plane is quite concerning for having this operate at significant scale. What could be done if one assumes that the selected bypass tunnel - from the BYPASS_PROTECTION handling - is used? Is there a reason that decision has to be redone here? What is the issue that the solution is trying to work around? I can certainly imagine scenarios with BFD sessions so that the PRR can be rapidly failed over as the result of the BFD session going down. What scale of LSPs are you expecting this scenario to handle? 8) Sec 5.2.2: Given that the PRR will TEAR DOWN the LSP if it can't find a matching bypass tunnel, it would be quite useful for the ingress to have visibility as to the protection available. In RFC 4090, Sec 4.4 defines both "local protection available" and "local protection in use" flags in the IPv4/IPv6 sub-objects. Clearly, that isn't sufficient for the co-routed case because the ingress needs to know also that "local upstream protection available" and perhaps "local upstream protection in use". 9) Sec 5.2.3: " o The upstream PLR R4 starts sending the traffic flow of the protected LSP over the restored link towards downstream PLR R3 and forwarding the Path messages towards PRR R5 and stops sending the traffic over the bypass tunnel. o When upstream PLR R4 receives the protected LSP Path messages over the restored link, if not already done, it starts sending Resv messages and traffic flow over the restored link towards downstream PLR R3 and forwarding the Path messages towards PRR R5 and stops sending them over the bypass tunnel." In the referenced figures, R4 is NOT an upstream PLR; that is R5. R4 could have forgotten all state associated with the bi-directional LSP. Please fix the text to actually describe the behavior. 10) Sec 5.3: " Unidirectional link failures can result in the traffic flowing on asymmetric paths in the forward and reverse directions. In addition, unidirectional link failures can cause RSVP soft-state timeout in the control-plane in some cases. As an example, if the unidirectional link failure is in the upstream direction (from R4 to R3 in Figures 1 and 2), the downstream PLR (node R3) can stop receiving the Resv messages of the protected LSP from the upstream PLR (node R4 in Figures 1 and 2) and this can cause RSVP soft-state timeout to occur on the downstream PLR (node R3)." Is the assumption that there is no IGP or BFD running on the link? If not, then the IGP or BFD session will go down on the link first, making it unavailable to RSVP-TE and should trigger the fast-reroute. Also - given this issue, why does the upstream MP not start using the bypass tunnel when receiving Resv through a bypass tunnel? There is no explanation in the draft and there should be - to prevent incorrect "optimizations". Ideally, the draft would specify something like MUST NOT or SHOULD NOT with explanation - if that is the case. 11) Sec 7.1: The description for the BYPASS_ASSIGNMENT completely fails to be clear as to whether the contents are for the bypass tunnel used by the node inserting it into the RRO or whether the contents are a direction for the node that receives it - based on the Node ID that is included. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- a) Sec 5.2.2.1: The approach suggested here seems fairly intensive from a forwarding plane perspective. It would be very helpful to indicate the range of expected/desired time for the fail-over. b) Sec 5.2: This section is about node failures - but while the bypass tunnels are node-protecting, the failures discussed are only link. A brief example that describes the expected signaling for an actual node failure would be helpful. From nobody Wed Aug 2 12:45:18 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE238132163 for ; Wed, 2 Aug 2017 12:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebN9rSfX2h6V for ; Wed, 2 Aug 2017 12:45:11 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 76555132164 for ; Wed, 2 Aug 2017 12:45:09 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l82so35452800ywc.2 for ; Wed, 02 Aug 2017 12:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6j+exfrvVSyWvZdS/scNhw5Y9wgMuCuflpYzszhLr68=; b=OFTu0lRUaR2Cp849UxtmcM1+w7EO0tbOrFpcBY/f/lXKriEa9Nj8PFZs4zU0g0+Qb/ DsM2KXj30L/NipM2pUPsu0iShXZhDmdZBwwk2pdZwyEzGHc7Ug/0k0/c9uNHYA+SMGli rmWoojDWZV//TahmfUJb3a0kH6PvPAGCOT506Qd8Ax6uLNqz6PZDttXB3I9p7xWhPnAy F5wxwr8EFEmxq9VcoR3SfGG9yYXutbOJPzjKgmFWFqSx2brscSvOBrzZJ/5spPsgtdKP pQ8EzjqqMnY/8OQ2nsiEBx4uLCekeZxn6fpOnR1uxktZkIlYb7HdL+0M29qU12PRtZ8z KwKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6j+exfrvVSyWvZdS/scNhw5Y9wgMuCuflpYzszhLr68=; b=GaExBfVqPLAQmAP8u7qFXBHES2nTvTqIcz7lgKry8qIp/l2HzuLYRAqt/diI8PNZTT vfQV0pexujnjYkKNMeNGcYriI0yJ3fkSnqhWjq7YZDCUWuRhYjNkGtz3DLyrX8a//v4M JRtOBSAUJSNUnQTH1NsxVg0q7x4JVloZetfcfCDrgVwZ3X+WRq5rXr7aGbG0aifwVqug qMdBvfe2ZSxObWkUsvtKmDcfn/xIFIqlA7PBLVIN8nCF5/WfmJfdhbbYWDgRUToD4uQt qwoyFss8nBpr3GD297HroGI7F4xgf8yTkYJLHNF9iIZlDS1HVr8YCgo0PzzmmOnUh9v3 Tjpg== X-Gm-Message-State: AIVw112XYc9zHEQP4IoNbDjpxbHaqOC9Y/iEQ7G81Eo/K0s2smvhGQze aBmXxbyoI4RtbU5qYISGrYxtF7RStyK+ X-Received: by 10.37.181.25 with SMTP id p25mr19309142ybj.249.1501703108630; Wed, 02 Aug 2017 12:45:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.36.12 with HTTP; Wed, 2 Aug 2017 12:44:28 -0700 (PDT) In-Reply-To: References: <150169528547.5719.14326487474057494500.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 2 Aug 2017 12:44:28 -0700 Message-ID: To: "Rakesh Gandhi (rgandhi)" Cc: The IESG , "draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org" , "teas-chairs@ietf.org" , "vbeeram@juniper.net" , "teas@ietf.org" , DEBORAH BRUNGARD Content-Type: multipart/alternative; boundary="f403045e6ed05982690555ca80b2" Archived-At: Subject: Re: [Teas] Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 19:45:13 -0000 --f403045e6ed05982690555ca80b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 2, 2017 at 11:32 AM, Rakesh Gandhi (rgandhi) wrote: > Hi Eric, > > Thank you for the review and your comments. Please see in-line with . > > On 2017-08-02, 1:34 PM, "Eric Rescorla" wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-teas-gmpls-lsp-fastreroute-10: 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 th= is > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp- > fastreroute/ > > > > ---------------------------------------------------------------------= - > DISCUSS: > ---------------------------------------------------------------------= - > > What stops me from just providing a random IP address > that I don't control in BYPASS_ASSIGNMENT and thus > causing them to get spammed? I am assuming there are > mechanisms to prevent them, but it's not immediately > clear to me what those are, so they at minimum need > to spelled out in security considerations. This section > from RFC 4090 is not encouraging: > > This document does not introduce new security issues. The securit= y > considerations pertaining to the original RSVP protocol [RSVP] > remain > relevant. > > Note that the facility backup method requires that a PLR and its > selected merge point trust RSVP messages received from each other. > > > Ok, how about adding following text in the security section? > > =E2=80=9CThe security considerations pertaining to the original RSVP prot= ocol > [RFC2205] as well as Fast Reroute procedures described in [RFC4090] remai= n > relevant to the updates in this document.=E2=80=9D > I'm really looking for something subtantive, rather than just a pointer. > > > > ---------------------------------------------------------------------= - > COMMENT: > ---------------------------------------------------------------------= - > > You refer to Figure 2 on page 3 and it appears on page 12. > Probably either you should move it up or make a copy. > > > Ok, we can fix it as part of the next edits. > > Thanks, > Rakesh > > > > > --f403045e6ed05982690555ca80b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 2, 2017 at 11:32 AM, Rakesh Gandhi (rgandhi) <rgandhi@cisc= o.com> wrote:
Hi Eric,

Thank you for the review and your comments. Please see in-line with <RG&= gt;.

On 2017-08-02, 1:34 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:

=C2=A0 =C2=A0 Eric Rescorla has entered the following ballot position for =C2=A0 =C2=A0 draft-ietf-teas-gmpls-lsp-fastreroute-10: Discuss

=C2=A0 =C2=A0 When responding, please keep the subject line intact and repl= y to all
=C2=A0 =C2=A0 email addresses included in the To and CC lines. (Feel free t= o cut this
=C2=A0 =C2=A0 introductory paragraph, however.)


=C2=A0 =C2=A0 Please refer to https://www.i= etf.org/iesg/statement/discuss-criteria.html
=C2=A0 =C2=A0 for more information about IESG DISCUSS and COMMENT positions= .


=C2=A0 =C2=A0 The document, along with other ballot positions, can be found= here:
=C2=A0 =C2=A0 https://datatra= cker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/



=C2=A0 =C2=A0 --------------------------------------------------------= --------------
=C2=A0 =C2=A0 DISCUSS:
=C2=A0 =C2=A0 --------------------------------------------------------= --------------

=C2=A0 =C2=A0 What stops me from just providing a random IP address
=C2=A0 =C2=A0 that I don't control in BYPASS_ASSIGNMENT and thus
=C2=A0 =C2=A0 causing them to get spammed? I am assuming there are
=C2=A0 =C2=A0 mechanisms to prevent them, but it's not immediately
=C2=A0 =C2=A0 clear to me what those are, so they at minimum need
=C2=A0 =C2=A0 to spelled out in security considerations. This section
=C2=A0 =C2=A0 from RFC 4090 is not encouraging:

=C2=A0 =C2=A0 =C2=A0 =C2=A0This document does not introduce new security is= sues.=C2=A0 The security
=C2=A0 =C2=A0 =C2=A0 =C2=A0considerations pertaining to the original RSVP p= rotocol [RSVP] remain
=C2=A0 =C2=A0 =C2=A0 =C2=A0relevant.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Note that the facility backup method requires th= at a PLR and its
=C2=A0 =C2=A0 =C2=A0 =C2=A0selected merge point trust RSVP messages receive= d from each other.


<RG> Ok, how about adding following text in the security = section?

=E2=80=9CThe security considerations pertaining to the original RSVP protoc= ol [RFC2205] as well as Fast Reroute procedures described in [RFC4090] rema= in relevant to the updates in this document.=E2=80=9D
=
I'm really looking for something subtantive, rather than= just a pointer.
=C2=A0



=C2=A0 =C2=A0 --------------------------------------------------------= --------------
=C2=A0 =C2=A0 COMMENT:
=C2=A0 =C2=A0 --------------------------------------------------------= --------------

=C2=A0 =C2=A0 You refer to Figure 2 on page 3 and it appears on page 12. =C2=A0 =C2=A0 Probably either you should move it up or make a copy.


<RG> Ok, we can fix it as part of the next edits.

Thanks,
Rakesh





--f403045e6ed05982690555ca80b2-- From nobody Wed Aug 2 13:59:22 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAB9132174; Wed, 2 Aug 2017 13:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbbcLhPT8-Ht; Wed, 2 Aug 2017 13:59:12 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91827132176; Wed, 2 Aug 2017 13:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16324; q=dns/txt; s=iport; t=1501707552; x=1502917152; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nggr+m7wfNG9JZtRS5lJy9Y6H5TApjiA6akXRAfPBp0=; b=e8HSQDVAyqJEEAQp8w/CsPOwoc8D9KuYm4AM6IYGomSfrftwKk52m0cu LmYZZI0p5y1d3Ll3VLPxBqisLKgeK/jOLJ54dwLq+vDInoILEswioEpYx 7TDa9DLLj72CGt63x8KWDpL2qhSl9CP6ubAKu7uSPu7oQMzbbtiYgOryB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQD3O4JZ/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEUB44HkASBTCKQX4UxDoIELIUbAhqEGz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQEDI1YQAgEIDgMDAQIkBAMCAgIwFAkIAgQOBYlLZBCtZYImJ4siA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDKIICgUyBYysLgnGEMQ8BEgE2CRYCgls?= =?us-ascii?q?wgjEFiWyWEAKHUYxZgg2FVophlXoBHzh/C3cVWwGFOYFOdgGHOYEjgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,313,1498521600"; d="scan'208,217";a="465665938" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Aug 2017 20:59:11 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v72KxBYe015309 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2017 20:59:11 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Aug 2017 15:59:10 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Wed, 2 Aug 2017 15:59:10 -0500 From: "Rakesh Gandhi (rgandhi)" To: Eric Rescorla CC: The IESG , "draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org" , "teas-chairs@ietf.org" , "vbeeram@juniper.net" , "teas@ietf.org" , DEBORAH BRUNGARD Thread-Topic: Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) Thread-Index: AQHTC7WkdEEClqfHX0mIbjS16X5NwaJxdPGAgABW9gD//9IlgA== Date: Wed, 2 Aug 2017 20:59:10 +0000 Message-ID: References: <150169528547.5719.14326487474057494500.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.247.50] Content-Type: multipart/alternative; boundary="_000_CD8D4B1301A0490C838232A858F90EA1ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 20:59:15 -0000 --_000_CD8D4B1301A0490C838232A858F90EA1ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KUGxlYXNlIHNlZSBpbmxpbmUgd2l0aCA8UkcyPg0KDQpGcm9tOiBFcmljIFJl c2NvcmxhIDxla3JAcnRmbS5jb20+DQpEYXRlOiBXZWRuZXNkYXksIEF1Z3VzdCAyLCAyMDE3IGF0 IDM6NDQgUE0NClRvOiAiPVNNVFA6cmdhbmRoaUBjaXNjby4gY29tIiA8cmdhbmRoaUBjaXNjby5j b20+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi10ZWFzLWdtcGxz LWxzcC1mYXN0cmVyb3V0ZUBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtdGVhcy1nbXBscy1sc3AtZmFz dHJlcm91dGVAaWV0Zi5vcmc+LCAidGVhcy1jaGFpcnNAaWV0Zi5vcmciIDx0ZWFzLWNoYWlyc0Bp ZXRmLm9yZz4sICJ2YmVlcmFtQGp1bmlwZXIubmV0IiA8dmJlZXJhbUBqdW5pcGVyLm5ldD4sICJ0 ZWFzQGlldGYub3JnIiA8dGVhc0BpZXRmLm9yZz4sIERFQk9SQUggQlJVTkdBUkQgPGRiMzU0NkBh dHQuY29tPg0KU3ViamVjdDogUmU6IEVyaWMgUmVzY29ybGEncyBEaXNjdXNzIG9uIGRyYWZ0LWll dGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGUtMTA6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1F TlQpDQoNCg0KDQpPbiBXZWQsIEF1ZyAyLCAyMDE3IGF0IDExOjMyIEFNLCBSYWtlc2ggR2FuZGhp IChyZ2FuZGhpKSA8cmdhbmRoaUBjaXNjby5jb208bWFpbHRvOnJnYW5kaGlAY2lzY28uY29tPj4g d3JvdGU6DQpIaSBFcmljLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcgYW5kIHlvdXIgY29t bWVudHMuIFBsZWFzZSBzZWUgaW4tbGluZSB3aXRoIDxSRz4uDQoNCk9uIDIwMTctMDgtMDIsIDE6 MzQgUE0sICJFcmljIFJlc2NvcmxhIiA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+ PiB3cm90ZToNCg0KICAgIEVyaWMgUmVzY29ybGEgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBi YWxsb3QgcG9zaXRpb24gZm9yDQogICAgZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLWxzcC1mYXN0cmVy b3V0ZS0xMDogRGlzY3Vzcw0KDQogICAgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUg c3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQogICAgZW1haWwgYWRkcmVzc2Vz IGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMN CiAgICBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQogICAgUGxlYXNlIHJl ZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbA0KICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQg Q09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KICAgIFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhl ciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCiAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRlYXMtZ21wbHMtbHNwLWZhc3RyZXJvdXRl Lw0KDQoNCg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBESVNDVVNTOg0KICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KICAgIFdoYXQgc3RvcHMgbWUgZnJvbSBqdXN0IHByb3ZpZGluZyBhIHJhbmRvbSBJUCBh ZGRyZXNzDQogICAgdGhhdCBJIGRvbid0IGNvbnRyb2wgaW4gQllQQVNTX0FTU0lHTk1FTlQgYW5k IHRodXMNCiAgICBjYXVzaW5nIHRoZW0gdG8gZ2V0IHNwYW1tZWQ/IEkgYW0gYXNzdW1pbmcgdGhl cmUgYXJlDQogICAgbWVjaGFuaXNtcyB0byBwcmV2ZW50IHRoZW0sIGJ1dCBpdCdzIG5vdCBpbW1l ZGlhdGVseQ0KICAgIGNsZWFyIHRvIG1lIHdoYXQgdGhvc2UgYXJlLCBzbyB0aGV5IGF0IG1pbmlt dW0gbmVlZA0KICAgIHRvIHNwZWxsZWQgb3V0IGluIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLg0K DQo8UkcyPiBBcyBtZW50aW9uZWQgaW4gdGhlIFJGQzQwOTAsIOKAnFBMUiBhbmQgTVAgdHJ1c3Qg dGhlIFJTVlAgbWVzc2FnZXMgcmVjZWl2ZWQgZnJvbSBlYWNoIG90aGVy4oCdLiBXZSBjYW4gYWRk IHRoaXMgdGV4dCBpbiB0aGUgZG9jdW1lbnQuDQrigJxJZiBhIE1QIGRvZXMgbm90IGZpbmQgYSBt YXRjaGluZyBieXBhc3MgdHVubmVsIHdpdGggZ2l2ZW4gc291cmNlIGFuZCBkZXN0aW5hdGlvbiBh ZGRyZXNzZXMgbG9jYWxseSwgaXQgaWdub3JlcyB0aGUgQllQQVNTX0FTU0lHTk1FTlQgc3ViLW9i amVjdC7igJ0gIER1ZSB0byB0aGlzLCBzZWN1cml0eSByaXNrIGludHJvZHVjZWQgaXMgbWluaW1h bC4NClRoYW5rcywNClJha2VzaA0KDQoNCg0KVGhpcyBzZWN0aW9uDQogICAgZnJvbSBSRkMgNDA5 MCBpcyBub3QgZW5jb3VyYWdpbmc6DQoNCiAgICAgICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGlu dHJvZHVjZSBuZXcgc2VjdXJpdHkgaXNzdWVzLiAgVGhlIHNlY3VyaXR5DQogICAgICAgY29uc2lk ZXJhdGlvbnMgcGVydGFpbmluZyB0byB0aGUgb3JpZ2luYWwgUlNWUCBwcm90b2NvbCBbUlNWUF0g cmVtYWluDQogICAgICAgcmVsZXZhbnQuDQoNCiAgICAgICBOb3RlIHRoYXQgdGhlIGZhY2lsaXR5 IGJhY2t1cCBtZXRob2QgcmVxdWlyZXMgdGhhdCBhIFBMUiBhbmQgaXRzDQogICAgICAgc2VsZWN0 ZWQgbWVyZ2UgcG9pbnQgdHJ1c3QgUlNWUCBtZXNzYWdlcyByZWNlaXZlZCBmcm9tIGVhY2ggb3Ro ZXIuDQoNCjxSRz4gT2ssIGhvdyBhYm91dCBhZGRpbmcgZm9sbG93aW5nIHRleHQgaW4gdGhlIHNl Y3VyaXR5IHNlY3Rpb24/DQoNCuKAnFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBwZXJ0YWlu aW5nIHRvIHRoZSBvcmlnaW5hbCBSU1ZQIHByb3RvY29sIFtSRkMyMjA1XSBhcyB3ZWxsIGFzIEZh c3QgUmVyb3V0ZSBwcm9jZWR1cmVzIGRlc2NyaWJlZCBpbiBbUkZDNDA5MF0gcmVtYWluIHJlbGV2 YW50IHRvIHRoZSB1cGRhdGVzIGluIHRoaXMgZG9jdW1lbnQu4oCdDQoNCkknbSByZWFsbHkgbG9v a2luZyBmb3Igc29tZXRoaW5nIHN1YnRhbnRpdmUsIHJhdGhlciB0aGFuIGp1c3QgYSBwb2ludGVy Lg0KDQoNCg0KDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIENPTU1FTlQ6DQogICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQogICAgWW91IHJlZmVyIHRvIEZpZ3VyZSAyIG9uIHBhZ2UgMyBhbmQgaXQgYXBwZWFy cyBvbiBwYWdlIDEyLg0KICAgIFByb2JhYmx5IGVpdGhlciB5b3Ugc2hvdWxkIG1vdmUgaXQgdXAg b3IgbWFrZSBhIGNvcHkuDQoNCg0KPFJHPiBPaywgd2UgY2FuIGZpeCBpdCBhcyBwYXJ0IG9mIHRo ZSBuZXh0IGVkaXRzLg0KDQpUaGFua3MsDQpSYWtlc2gNCg0KDQoNCg0K --_000_CD8D4B1301A0490C838232A858F90EA1ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6603F205DBF39B4CABA2755322466F88@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5IaSBFcmljLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlBsZWFz ZSBzZWUgaW5saW5lIHdpdGggJmx0O1JHMiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5FcmljIFJlc2NvcmxhICZsdDtla3JAcnRm bS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgQXVndXN0IDIsIDIwMTcgYXQg Mzo0NCBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PVNNVFA6cmdhbmRoaUBjaXNjby4gY29tJnF1 b3Q7ICZsdDtyZ2FuZGhpQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPlRoZSBJRVNHICZs dDtpZXNnQGlldGYub3JnJmd0OywgJnF1b3Q7ZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLWxzcC1mYXN0 cmVyb3V0ZUBpZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLWxzcC1mYXN0 cmVyb3V0ZUBpZXRmLm9yZyZndDssICZxdW90O3RlYXMtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZs dDt0ZWFzLWNoYWlyc0BpZXRmLm9yZyZndDssICZxdW90O3ZiZWVyYW1AanVuaXBlci5uZXQmcXVv dDsgJmx0O3ZiZWVyYW1AanVuaXBlci5uZXQmZ3Q7LCAmcXVvdDt0ZWFzQGlldGYub3JnJnF1b3Q7 ICZsdDt0ZWFzQGlldGYub3JnJmd0OywNCiBERUJPUkFIIEJSVU5HQVJEICZsdDtkYjM1NDZAYXR0 LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IEVyaWMgUmVzY29ybGEncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGUtMTA6ICh3aXRoIERJU0NV U1MgYW5kIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBXZWQsIEF1ZyAyLCAyMDE3IGF0IDExOjMyIEFNLCBSYWtlc2ggR2FuZGhpIChy Z2FuZGhpKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJnYW5kaGlAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+cmdhbmRoaUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBFcmljLDxicj4NCjxicj4NClRoYW5r IHlvdSBmb3IgdGhlIHJldmlldyBhbmQgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZSBpbi1saW5l IHdpdGggJmx0O1JHJmd0Oy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAyMDE3LTA4 LTAyLCAxOjM0IFBNLCAmcXVvdDtFcmljIFJlc2NvcmxhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7IEVyaWMgUmVzY29ybGEgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxs b3QgcG9zaXRpb24gZm9yPGJyPg0KJm5ic3A7ICZuYnNwOyBkcmFmdC1pZXRmLXRlYXMtZ21wbHMt bHNwLWZhc3RyZXJvdXRlLTEwOiBEaXNjdXNzPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0byBhbGw8YnI+DQombmJzcDsgJm5ic3A7IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0 aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPGJyPg0KJm5ic3A7ICZu YnNwOyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnI+DQo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7IFBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRt bDwvYT48YnI+DQombmJzcDsgJm5ic3A7IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cg RElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu IGJlIGZvdW5kIGhlcmU6PGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRlYXMtZ21wbHMtbHNwLWZhc3RyZXJvdXRl LyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi10ZWFzLWdtcGxzLWxzcC1mYXN0cmVyb3V0ZS88L2E+PGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJm5ic3A7ICZuYnNwOyBESVND VVNTOjxicj4NCiZuYnNwOyAmbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgV2hhdCBzdG9wcyBtZSBmcm9tIGp1c3QgcHJvdmlkaW5nIGEgcmFuZG9tIElQIGFkZHJl c3M8YnI+DQombmJzcDsgJm5ic3A7IHRoYXQgSSBkb24ndCBjb250cm9sIGluIEJZUEFTU19BU1NJ R05NRU5UIGFuZCB0aHVzPGJyPg0KJm5ic3A7ICZuYnNwOyBjYXVzaW5nIHRoZW0gdG8gZ2V0IHNw YW1tZWQ/IEkgYW0gYXNzdW1pbmcgdGhlcmUgYXJlPGJyPg0KJm5ic3A7ICZuYnNwOyBtZWNoYW5p c21zIHRvIHByZXZlbnQgdGhlbSwgYnV0IGl0J3Mgbm90IGltbWVkaWF0ZWx5PGJyPg0KJm5ic3A7 ICZuYnNwOyBjbGVhciB0byBtZSB3aGF0IHRob3NlIGFyZSwgc28gdGhleSBhdCBtaW5pbXVtIG5l ZWQ8YnI+DQombmJzcDsgJm5ic3A7IHRvIHNwZWxsZWQgb3V0IGluIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZsdDtSRzImZ3Q7IEFzIG1lbnRpb25l ZCBpbiB0aGUgUkZDNDA5MCwg4oCcUExSIGFuZCBNUCB0cnVzdCB0aGUgUlNWUCBtZXNzYWdlcyBy ZWNlaXZlZCBmcm9tIGVhY2ggb3RoZXLigJ0uIFdlIGNhbiBhZGQgdGhpcyB0ZXh0IGluIHRoZSBk b2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+4oCcSWYgYSBNUCBkb2VzIG5vdCBmaW5kIGEgbWF0Y2hpbmcgYnlw YXNzIHR1bm5lbCB3aXRoIGdpdmVuIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gYWRkcmVzc2VzIGxv Y2FsbHksIGl0IGlnbm9yZXMgdGhlIEJZUEFTU19BU1NJR05NRU5UIHN1Yi1vYmplY3Qu4oCdICZu YnNwO0R1ZSB0byB0aGlzLCBzZWN1cml0eSByaXNrIGludHJvZHVjZWQgaXMgbWluaW1hbC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5SYWtlc2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhpcyBzZWN0aW9uPGJyPg0KJm5ic3A7ICZu YnNwOyBmcm9tIFJGQyA0MDkwIGlzIG5vdCBlbmNvdXJhZ2luZzo8YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBuZXcg c2VjdXJpdHkgaXNzdWVzLiZuYnNwOyBUaGUgc2VjdXJpdHk8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtjb25zaWRlcmF0aW9ucyBwZXJ0YWluaW5nIHRvIHRoZSBvcmlnaW5hbCBSU1ZQ IHByb3RvY29sIFtSU1ZQXSByZW1haW48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDty ZWxldmFudC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtOb3RlIHRoYXQg dGhlIGZhY2lsaXR5IGJhY2t1cCBtZXRob2QgcmVxdWlyZXMgdGhhdCBhIFBMUiBhbmQgaXRzPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VsZWN0ZWQgbWVyZ2UgcG9pbnQgdHJ1c3Qg UlNWUCBtZXNzYWdlcyByZWNlaXZlZCBmcm9tIGVhY2ggb3RoZXIuPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O1JHJmd0 OyBPaywgaG93IGFib3V0IGFkZGluZyBmb2xsb3dpbmcgdGV4dCBpbiB0aGUgc2VjdXJpdHkgc2Vj dGlvbj88YnI+DQo8YnI+DQrigJxUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcGVydGFpbmlu ZyB0byB0aGUgb3JpZ2luYWwgUlNWUCBwcm90b2NvbCBbUkZDMjIwNV0gYXMgd2VsbCBhcyBGYXN0 IFJlcm91dGUgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4gW1JGQzQwOTBdIHJlbWFpbiByZWxldmFu dCB0byB0aGUgdXBkYXRlcyBpbiB0aGlzIGRvY3VtZW50LuKAnTxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHJlYWxseSBsb29r aW5nIGZvciBzb21ldGhpbmcgc3VidGFudGl2ZSwgcmF0aGVyIHRoYW4ganVzdCBhIHBvaW50ZXIu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJm5ic3A7ICZuYnNwOyBDT01NRU5UOjxicj4NCiZu YnNwOyAmbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgWW91IHJl ZmVyIHRvIEZpZ3VyZSAyIG9uIHBhZ2UgMyBhbmQgaXQgYXBwZWFycyBvbiBwYWdlIDEyLjxicj4N CiZuYnNwOyAmbmJzcDsgUHJvYmFibHkgZWl0aGVyIHlvdSBzaG91bGQgbW92ZSBpdCB1cCBvciBt YWtlIGEgY29weS48YnI+DQo8YnI+DQo8YnI+DQombHQ7UkcmZ3Q7IE9rLCB3ZSBjYW4gZml4IGl0 IGFzIHBhcnQgb2YgdGhlIG5leHQgZWRpdHMuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClJha2Vz aDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CD8D4B1301A0490C838232A858F90EA1ciscocom_-- From nobody Wed Aug 2 14:05:39 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E30E13217E for ; Wed, 2 Aug 2017 14:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM3qEO7xLtoA for ; Wed, 2 Aug 2017 14:05:34 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 D1D99132178 for ; Wed, 2 Aug 2017 14:05:30 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id s143so36721794ywg.1 for ; Wed, 02 Aug 2017 14:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ecG2+H6v/3ygPJ0MRoVeNkNDIRZXjYE5h53pYsQ+/F4=; b=ZhvlJC9b+cjRO2DDVzvvydvWpjmNeLW/neem/sT8QiRBo9d9orp8dIQEgdscUfGpui BpTBiMathhszKNdsFCLCrzALbXWYDNJavdAjD+++5i9T2m75u2yXiyk/nEcKkKyDWScS DcfTnXGcraE0tEVuB7Ty/uLLbhTfV8M4U41QKDKyEu3sdOlpmUI+b7pIagQs4dkRK47T WJlEyxSvcpWysXwS/vzYJSTCu4+mn3nrv9W3eVJuqY1kMDXv8D8DeuHEEsELKNWibyJQ gD91NthIkrvXrLX1q+NF53GocL5DaumO7Md9qzTQFdPKRWO3ukf60HGRB9UXDpx02d0n QOYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ecG2+H6v/3ygPJ0MRoVeNkNDIRZXjYE5h53pYsQ+/F4=; b=HQF1I6ssW8TV2ifwkRT2FqJ4qc1aQ/97RNv2Wb8LGHgLeXbAVh5CD1mknWUgQ7hGsj Hm9986rYXfMJnC2EuYZJJ7zlsk/NZ5uY5WUbMMrP6QtsIzvVifDVFXgqZ0Q8eEXr1xbC 4UWRbBTrH00UBSvfD2dB3YieeQPc0yKpcdWtlojrak/QY3cL1u+e4iiYqw6IdOeqpe7/ w5A57JeVN2tH+fnNUMMANikNZbiB62uV5Fk7neZfv4/Loob0yGPUzorfp9S1C7wCXE3l 9LhlPoETvsGnv3HlihfMeWxzgP9kBsyFIg5BkNl8fa97wCWYnC2IySH0Q72eTwdKMWti dWRQ== X-Gm-Message-State: AIVw1114v/qNGScAXO8DTJLfn3AZ1Ur7XxI+wcYaHry0AH0ZPWGoHZSQ PFV36DBu565jcbb47YA+iP7ou2uNc4xu X-Received: by 10.129.172.21 with SMTP id k21mr13536910ywh.321.1501707929979; Wed, 02 Aug 2017 14:05:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.36.12 with HTTP; Wed, 2 Aug 2017 14:04:49 -0700 (PDT) In-Reply-To: References: <150169528547.5719.14326487474057494500.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 2 Aug 2017 14:04:49 -0700 Message-ID: To: "Rakesh Gandhi (rgandhi)" Cc: The IESG , "draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org" , "teas-chairs@ietf.org" , "vbeeram@juniper.net" , "teas@ietf.org" , DEBORAH BRUNGARD Content-Type: multipart/alternative; boundary="f4030436885eb99ef70555cb9f43" Archived-At: Subject: Re: [Teas] Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 21:05:35 -0000 --f4030436885eb99ef70555cb9f43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That seems fine On Wed, Aug 2, 2017 at 1:59 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Eric, > > > > Please see inline with > > > > *From: *Eric Rescorla > *Date: *Wednesday, August 2, 2017 at 3:44 PM > *To: *"=3DSMTP:rgandhi@cisco. com" > *Cc: *The IESG , "draft-ietf-teas-gmpls-lsp- > fastreroute@ietf.org" , " > teas-chairs@ietf.org" , "vbeeram@juniper.net" < > vbeeram@juniper.net>, "teas@ietf.org" , DEBORAH BRUNGARD < > db3546@att.com> > *Subject: *Re: Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastr= eroute-10: > (with DISCUSS and COMMENT) > > > > > > > > On Wed, Aug 2, 2017 at 11:32 AM, Rakesh Gandhi (rgandhi) < > rgandhi@cisco.com> wrote: > > Hi Eric, > > Thank you for the review and your comments. Please see in-line with . > > > On 2017-08-02, 1:34 PM, "Eric Rescorla" wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-teas-gmpls-lsp-fastreroute-10: 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 th= is > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp- > fastreroute/ > > > > ---------------------------------------------------------------------= - > DISCUSS: > ---------------------------------------------------------------------= - > > What stops me from just providing a random IP address > that I don't control in BYPASS_ASSIGNMENT and thus > causing them to get spammed? I am assuming there are > mechanisms to prevent them, but it's not immediately > clear to me what those are, so they at minimum need > to spelled out in security considerations. > > > > As mentioned in the RFC4090, =E2=80=9CPLR and MP trust the RSVP mes= sages > received from each other=E2=80=9D. We can add this text in the document. > > =E2=80=9CIf a MP does not find a matching bypass tunnel with given source= and > destination addresses locally, it ignores the BYPASS_ASSIGNMENT > sub-object.=E2=80=9D Due to this, security risk introduced is minimal. > > Thanks, > > Rakesh > > > > > > > > This section > from RFC 4090 is not encouraging: > > This document does not introduce new security issues. The securit= y > considerations pertaining to the original RSVP protocol [RSVP] > remain > relevant. > > Note that the facility backup method requires that a PLR and its > selected merge point trust RSVP messages received from each other. > > Ok, how about adding following text in the security section? > > =E2=80=9CThe security considerations pertaining to the original RSVP prot= ocol > [RFC2205] as well as Fast Reroute procedures described in [RFC4090] remai= n > relevant to the updates in this document.=E2=80=9D > > > > I'm really looking for something subtantive, rather than just a pointer. > > > > > > > ---------------------------------------------------------------------= - > COMMENT: > ---------------------------------------------------------------------= - > > You refer to Figure 2 on page 3 and it appears on page 12. > Probably either you should move it up or make a copy. > > > Ok, we can fix it as part of the next edits. > > Thanks, > Rakesh > > > > > --f4030436885eb99ef70555cb9f43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That seems fine

On Wed, Aug 2, 2017 at 1:59 PM, Rakesh Gandhi (rgandhi= ) <rgandhi@cisco.com> wrote:

Hi Eric,

=C2=A0

Please see inline with <RG2>

=C2=A0

F= rom: Eric Rescorla <ekr@rtfm.com>
Date: Wednesday, August 2, 2017 at 3:44 PM
To: "=3DSMTP:rgandhi@cisco. com" <rgandhi@cisco.com>
Cc: The IESG <= iesg@ietf.org>, "draft-ietf-teas-gmpls-lsp-fastre= route@ietf.org" <draft-ietf-teas-gmpls-lsp-fastre= route@ietf.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "vbeeram@juniper.net&q= uot; <vbeeram@j= uniper.net>, "teas@ietf.org" <teas@ietf.org>, DEBORAH BRUNGARD <d= b3546@att.com>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-teas-gmpls-ls= p-fastreroute-10: (with DISCUSS and COMMENT)

=C2=A0

=C2=A0

=C2=A0

On Wed, Aug 2, 2017 at 11:32 AM, Rakesh Gandhi (rgan= dhi) <rgandhi@cis= co.com> wrote:

Hi Eric,

Thank you for the review and your comments. Please see in-line with <RG&= gt;.


On 2017-08-02, 1:34 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:

=C2=A0 =C2=A0 Eric Rescorla has entered the following ballot position for =C2=A0 =C2=A0 draft-ietf-teas-gmpls-lsp-fastreroute-10: Discuss

=C2=A0 =C2=A0 When responding, please keep the subject line intact and repl= y to all
=C2=A0 =C2=A0 email addresses included in the To and CC lines. (Feel free t= o cut this
=C2=A0 =C2=A0 introductory paragraph, however.)


=C2=A0 =C2=A0 Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
=C2=A0 =C2=A0 for more information about IESG DISCUSS and COMMENT positions= .


=C2=A0 =C2=A0 The document, along with other ballot positions, can be found= here:
=C2=A0 =C2=A0 https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastre= route/



=C2=A0 =C2=A0 --------------------------------------------------------= --------------
=C2=A0 =C2=A0 DISCUSS:
=C2=A0 =C2=A0 --------------------------------------------------------= --------------

=C2=A0 =C2=A0 What stops me from just providing a random IP address
=C2=A0 =C2=A0 that I don't control in BYPASS_ASSIGNMENT and thus
=C2=A0 =C2=A0 causing them to get spammed? I am assuming there are
=C2=A0 =C2=A0 mechanisms to prevent them, but it's not immediately
=C2=A0 =C2=A0 clear to me what those are, so they at minimum need
=C2=A0 =C2=A0 to spelled out in security considerations.

=C2=A0<= /p>

<RG2> As= mentioned in the RFC4090, =E2=80=9CPLR and MP trust the RSVP messages rece= ived from each other=E2=80=9D. We can add this text in the document.=

=E2=80=9CIf a MP does= not find a matching bypass tunnel with given source and destination addres= ses locally, it ignores the BYPASS_ASSIGNMENT sub-object.=E2=80=9D =C2=A0Du= e to this, security risk introduced is minimal.

Thanks,=

Rakesh<= /p>

=C2=A0<= /p>

=C2=A0<= /p>

=C2=A0<= /p>

This section
=C2=A0 =C2=A0 from RFC 4090 is not encouraging:

=C2=A0 =C2=A0 =C2=A0 =C2=A0This document does not introduce new security is= sues.=C2=A0 The security
=C2=A0 =C2=A0 =C2=A0 =C2=A0considerations pertaining to the original RSVP p= rotocol [RSVP] remain
=C2=A0 =C2=A0 =C2=A0 =C2=A0relevant.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Note that the facility backup method requires th= at a PLR and its
=C2=A0 =C2=A0 =C2=A0 =C2=A0selected merge point trust RSVP messages receive= d from each other.

<RG> Ok, how about adding following text in th= e security section?

=E2=80=9CThe security considerations pertaining to the original RSVP protoc= ol [RFC2205] as well as Fast Reroute procedures described in [RFC4090] rema= in relevant to the updates in this document.=E2=80=9D

=C2=A0

I'm really looking for something subtantive, rat= her than just a pointer.

=C2=A0




=C2=A0 =C2=A0 --------------------------------------------------------= --------------
=C2=A0 =C2=A0 COMMENT:
=C2=A0 =C2=A0 --------------------------------------------------------= --------------

=C2=A0 =C2=A0 You refer to Figure 2 on page 3 and it appears on page 12. =C2=A0 =C2=A0 Probably either you should move it up or make a copy.


<RG> Ok, we can fix it as part of the next edits.

Thanks,
Rakesh



=C2=A0


--f4030436885eb99ef70555cb9f43-- From nobody Wed Aug 2 14:20:53 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFE513217F; Wed, 2 Aug 2017 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0JF9xlhKWSn; Wed, 2 Aug 2017 14:20:46 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B656132177; Wed, 2 Aug 2017 14:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29908; q=dns/txt; s=iport; t=1501708846; x=1502918446; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AKapxW/PzXEEDsID+zMpbp3JjSrSTOP36ElOKvmF7TQ=; b=gS/eADfmXasVVyMQ7om2al80R58h00u49nLpIocaTI2ffrcvP3fAKAZl oZ5sfIT6K/jpkEK3L8JkavMmyhLNpnfNUd/ODzktrRLW3eZprI/73ykOW eAQz2OQMwYGB0QCLYXxFrBECRUC4eeCDHtbETY8UzOuffAwdc4SZV3Y7a Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AADgQYJZ/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEUB44HkAWBbpYQDoIELIUbAhqEGz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEDI0QSEAIBCA4DAwECIQMEAwICAjAUCQgCBA4FiUtkEK1cgiYniyMBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYMoggKBTIFiASuCfIQxDwESASYQCQYQAoJ?= =?us-ascii?q?bMIIxBYlslhACh1GMWYINhVaKYYlajCABHzh/C3cVWwGFOYFOdgGHOYEjgQ8BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.41,313,1498521600"; d="scan'208,217";a="460673936" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Aug 2017 21:20:45 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v72LKj9c030479 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2017 21:20:45 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Aug 2017 16:20:44 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Wed, 2 Aug 2017 16:20:44 -0500 From: "Rakesh Gandhi (rgandhi)" To: Eric Rescorla CC: The IESG , "draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org" , "teas-chairs@ietf.org" , "vbeeram@juniper.net" , "teas@ietf.org" , DEBORAH BRUNGARD Thread-Topic: Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) Thread-Index: AQHTC7WkdEEClqfHX0mIbjS16X5NwaJxdPGAgABW9gD//9IlgIAARE6A///BuYA= Date: Wed, 2 Aug 2017 21:20:44 +0000 Message-ID: <29D11F29-BA3E-49E6-A4E6-FD0FF61E9088@cisco.com> References: <150169528547.5719.14326487474057494500.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.247.50] Content-Type: multipart/alternative; boundary="_000_29D11F29BA3E49E6A4E6FD0FF61E9088ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Eric Rescorla's Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 21:20:51 -0000 --_000_29D11F29BA3E49E6A4E6FD0FF61E9088ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEVyaWMuIEZZSSwgV2lsbCB1cGRhdGUgdGhlIFNlY3VyaXR5IFNlY3Rpb24gYXMgZm9s bG93aW5nIHRoYXQgaW5jb3Jwb3JhdGVzIHlvdXIgc3VnZ2VzdGlvbnMuDQoNCg0KDQrigJxUaGlz IGRvY3VtZW50IGludHJvZHVjZXMgYSBuZXcgQllQQVNTX0FTU0lHTk1FTlQgc3Vib2JqZWN0IGZv ciB0aGUgUkVDT1JEX1JPVVRFIE9iamVjdCB0aGF0IGlzIGNhcnJpZWQgaW4gYW4gUlNWUCBzaWdu YWxpbmcgbWVzc2FnZS4gIFRodXMgaW4gdGhlIGV2ZW50IG9mIHRoZSBpbnRlcmNlcHRpb24gb2Yg YSBzaWduYWxpbmcgbWVzc2FnZSwgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBMU1AncyBmYXN0IHJl cm91dGUgcHJvdGVjdGlvbiBjYW4gYmUgZGVkdWNlZCB0aGFuIHdhcyBwcmV2aW91c2x5IHRoZSBj YXNlLiAgVGhpcyBpcyBqdWRnZWQgdG8gYmUgYSB2ZXJ5IG1pbm9yIHNlY3VyaXR5IHJpc2sgYXMg dGhpcyBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IGF2YWlsYWJsZSBieSBvdGhlciBtZWFucy4gIElm IGEgTVAgZG9lcyBub3QgZmluZCBhIG1hdGNoaW5nIGJ5cGFzcyB0dW5uZWwgd2l0aCBnaXZlbiBz b3VyY2UgYW5kIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBsb2NhbGx5LCBpdCBpZ25vcmVzIHRoZSBC WVBBU1NfQVNTSUdOTUVOVCBzdWJvYmplY3QuICBEdWUgdG8gdGhpcywgc2VjdXJpdHkgcmlzayBp bnRyb2R1Y2VkIGJ5IGluc2VydGluZyBhIHJhbmRvbSBhZGRyZXNzIGluIHRoaXMgc3Vib2JqZWN0 IGlzIG1pbmltYWwuICBUaGUgTm90aWZ5IG1lc3NhZ2UgZm9yIEZSUiBCeXBhc3MgQXNzaWdubWVu dCBFcnJvciBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgcmVzdWx0IGluIHRlYXIt ZG93biBvZiB0aGUgcHJvdGVjdGVkIExTUCBhbmQgaXMgbm90IHNlcnZpY2UgYWZmZWN0aW5nLg0K DQoNCg0KU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIFJTVlAtVEUgYW5kIEdNUExTIHNpZ25h bGluZyBleHRlbnNpb25zIGFyZSBjb3ZlcmVkIGluIFtSRkMzMjA5PGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmMzMjA5Pl0gYW5kIFtSRkMzNDczPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmMzNDczPl0uICBGdXJ0aGVyLCBnZW5lcmFsIGNvbnNpZGVyYXRpb25zIGZvciBzZWN1 cmluZyBSU1ZQLVRFIGluIE1QTFMtVEUgYW5kIEdNUExTIG5ldHdvcmtzIGNhbiBiZSBmb3VuZCBp biBbUkZDNTkyMDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTkyMD5dLiAgVGhpcyBk b2N1bWVudCB1cGRhdGVzIHRoZSBtZWNoYW5pc21zIGRlZmluZWQgaW4gW1JGQzQwOTBdLCB3aGlj aCBhbHNvIGRpc2N1c3NlcyByZWxhdGVkIHNlY3VyaXR5IG1lYXN1cmVzIGFuZCBhcmUgYWxzbyBh cHBsaWNhYmxlIHRvIHRoaXMgZG9jdW1lbnQuICBBcyBzcGVjaWZpZWQgaW4gW1JGQzQwOTBdLCBh IFBMUiBhbmQgaXRzIHNlbGVjdGVkIG1lcmdlIHBvaW50IHRydXN0IFJTVlAgbWVzc2FnZXMgcmVj ZWl2ZWQgZnJvbSBlYWNoIG90aGVyLiAgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHBlcnRh aW5pbmcgdG8gdGhlIG9yaWdpbmFsIFJTVlAgcHJvdG9jb2wgW1JGQzIyMDVdIGFsc28gcmVtYWlu IHJlbGV2YW50IHRvIHRoZSB1cGRhdGVzIGluIHRoaXMgZG9jdW1lbnQu4oCdDQoNCg0KDQoNClRo YW5rcywNClJha2VzaA0KDQoNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPg0K RGF0ZTogV2VkbmVzZGF5LCBBdWd1c3QgMiwgMjAxNyBhdCA1OjA0IFBNDQpUbzogIj1TTVRQOnJn YW5kaGlAY2lzY28uIGNvbSIgPHJnYW5kaGlAY2lzY28uY29tPg0KQ2M6IFRoZSBJRVNHIDxpZXNn QGlldGYub3JnPiwgImRyYWZ0LWlldGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGVAaWV0Zi5v cmciIDxkcmFmdC1pZXRmLXRlYXMtZ21wbHMtbHNwLWZhc3RyZXJvdXRlQGlldGYub3JnPiwgInRl YXMtY2hhaXJzQGlldGYub3JnIiA8dGVhcy1jaGFpcnNAaWV0Zi5vcmc+LCAidmJlZXJhbUBqdW5p cGVyLm5ldCIgPHZiZWVyYW1AanVuaXBlci5uZXQ+LCAidGVhc0BpZXRmLm9yZyIgPHRlYXNAaWV0 Zi5vcmc+LCBERUJPUkFIIEJSVU5HQVJEIDxkYjM1NDZAYXR0LmNvbT4NClN1YmplY3Q6IFJlOiBF cmljIFJlc2NvcmxhJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRlYXMtZ21wbHMtbHNwLWZhc3Ry ZXJvdXRlLTEwOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpUaGF0IHNlZW1zIGZpbmUN Cg0KT24gV2VkLCBBdWcgMiwgMjAxNyBhdCAxOjU5IFBNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhp KSA8cmdhbmRoaUBjaXNjby5jb208bWFpbHRvOnJnYW5kaGlAY2lzY28uY29tPj4gd3JvdGU6DQpI aSBFcmljLA0KDQpQbGVhc2Ugc2VlIGlubGluZSB3aXRoIDxSRzI+DQoNCkZyb206IEVyaWMgUmVz Y29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4NCkRhdGU6IFdlZG5lc2Rh eSwgQXVndXN0IDIsIDIwMTcgYXQgMzo0NCBQTQ0KVG86ICI9U01UUDpyZ2FuZGhpQGNpc2NvLiBj b20iIDxyZ2FuZGhpQGNpc2NvLmNvbTxtYWlsdG86cmdhbmRoaUBjaXNjby5jb20+Pg0KQ2M6IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPj4sICJkcmFmdC1pZXRm LXRlYXMtZ21wbHMtbHNwLWZhc3RyZXJvdXRlQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRl YXMtZ21wbHMtbHNwLWZhc3RyZXJvdXRlQGlldGYub3JnPiIgPGRyYWZ0LWlldGYtdGVhcy1nbXBs cy1sc3AtZmFzdHJlcm91dGVAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtdGVhcy1nbXBscy1s c3AtZmFzdHJlcm91dGVAaWV0Zi5vcmc+PiwgInRlYXMtY2hhaXJzQGlldGYub3JnPG1haWx0bzp0 ZWFzLWNoYWlyc0BpZXRmLm9yZz4iIDx0ZWFzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86dGVhcy1j aGFpcnNAaWV0Zi5vcmc+PiwgInZiZWVyYW1AanVuaXBlci5uZXQ8bWFpbHRvOnZiZWVyYW1AanVu aXBlci5uZXQ+IiA8dmJlZXJhbUBqdW5pcGVyLm5ldDxtYWlsdG86dmJlZXJhbUBqdW5pcGVyLm5l dD4+LCAidGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4iIDx0ZWFzQGlldGYub3Jn PG1haWx0bzp0ZWFzQGlldGYub3JnPj4sIERFQk9SQUggQlJVTkdBUkQgPGRiMzU0NkBhdHQuY29t PG1haWx0bzpkYjM1NDZAYXR0LmNvbT4+DQpTdWJqZWN0OiBSZTogRXJpYyBSZXNjb3JsYSdzIERp c2N1c3Mgb24gZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLWxzcC1mYXN0cmVyb3V0ZS0xMDogKHdpdGgg RElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KDQoNCk9uIFdlZCwgQXVnIDIsIDIwMTcgYXQgMTE6MzIg QU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIDxyZ2FuZGhpQGNpc2NvLmNvbTxtYWlsdG86cmdh bmRoaUBjaXNjby5jb20+PiB3cm90ZToNCkhpIEVyaWMsDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJl dmlldyBhbmQgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZSBpbi1saW5lIHdpdGggPFJHPi4NCg0K T24gMjAxNy0wOC0wMiwgMTozNCBQTSwgIkVyaWMgUmVzY29ybGEiIDxla3JAcnRmbS5jb208bWFp bHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KDQogICAgRXJpYyBSZXNjb3JsYSBoYXMgZW50ZXJl ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICBkcmFmdC1pZXRmLXRlYXMt Z21wbHMtbHNwLWZhc3RyZXJvdXRlLTEwOiBEaXNjdXNzDQoNCiAgICBXaGVuIHJlc3BvbmRpbmcs IHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCiAg ICBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwg ZnJlZSB0byBjdXQgdGhpcw0KICAgIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0K DQoNCiAgICBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQogICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQogICAgVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0K ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGVhcy1nbXBs cy1sc3AtZmFzdHJlcm91dGUvDQoNCg0KDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIERJU0NVU1M6 DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgV2hhdCBzdG9wcyBtZSBmcm9tIGp1c3QgcHJvdmlk aW5nIGEgcmFuZG9tIElQIGFkZHJlc3MNCiAgICB0aGF0IEkgZG9uJ3QgY29udHJvbCBpbiBCWVBB U1NfQVNTSUdOTUVOVCBhbmQgdGh1cw0KICAgIGNhdXNpbmcgdGhlbSB0byBnZXQgc3BhbW1lZD8g SSBhbSBhc3N1bWluZyB0aGVyZSBhcmUNCiAgICBtZWNoYW5pc21zIHRvIHByZXZlbnQgdGhlbSwg YnV0IGl0J3Mgbm90IGltbWVkaWF0ZWx5DQogICAgY2xlYXIgdG8gbWUgd2hhdCB0aG9zZSBhcmUs IHNvIHRoZXkgYXQgbWluaW11bSBuZWVkDQogICAgdG8gc3BlbGxlZCBvdXQgaW4gc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMuDQoNCjxSRzI+IEFzIG1lbnRpb25lZCBpbiB0aGUgUkZDNDA5MCwg4oCc UExSIGFuZCBNUCB0cnVzdCB0aGUgUlNWUCBtZXNzYWdlcyByZWNlaXZlZCBmcm9tIGVhY2ggb3Ro ZXLigJ0uIFdlIGNhbiBhZGQgdGhpcyB0ZXh0IGluIHRoZSBkb2N1bWVudC4NCuKAnElmIGEgTVAg ZG9lcyBub3QgZmluZCBhIG1hdGNoaW5nIGJ5cGFzcyB0dW5uZWwgd2l0aCBnaXZlbiBzb3VyY2Ug YW5kIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBsb2NhbGx5LCBpdCBpZ25vcmVzIHRoZSBCWVBBU1Nf QVNTSUdOTUVOVCBzdWItb2JqZWN0LuKAnSAgRHVlIHRvIHRoaXMsIHNlY3VyaXR5IHJpc2sgaW50 cm9kdWNlZCBpcyBtaW5pbWFsLg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KDQpUaGlzIHNlY3Rpb24N CiAgICBmcm9tIFJGQyA0MDkwIGlzIG5vdCBlbmNvdXJhZ2luZzoNCg0KICAgICAgIFRoaXMgZG9j dW1lbnQgZG9lcyBub3QgaW50cm9kdWNlIG5ldyBzZWN1cml0eSBpc3N1ZXMuICBUaGUgc2VjdXJp dHkNCiAgICAgICBjb25zaWRlcmF0aW9ucyBwZXJ0YWluaW5nIHRvIHRoZSBvcmlnaW5hbCBSU1ZQ IHByb3RvY29sIFtSU1ZQXSByZW1haW4NCiAgICAgICByZWxldmFudC4NCg0KICAgICAgIE5vdGUg dGhhdCB0aGUgZmFjaWxpdHkgYmFja3VwIG1ldGhvZCByZXF1aXJlcyB0aGF0IGEgUExSIGFuZCBp dHMNCiAgICAgICBzZWxlY3RlZCBtZXJnZSBwb2ludCB0cnVzdCBSU1ZQIG1lc3NhZ2VzIHJlY2Vp dmVkIGZyb20gZWFjaCBvdGhlci4NCjxSRz4gT2ssIGhvdyBhYm91dCBhZGRpbmcgZm9sbG93aW5n IHRleHQgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24/DQoNCuKAnFRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBwZXJ0YWluaW5nIHRvIHRoZSBvcmlnaW5hbCBSU1ZQIHByb3RvY29sIFtSRkMyMjA1 XSBhcyB3ZWxsIGFzIEZhc3QgUmVyb3V0ZSBwcm9jZWR1cmVzIGRlc2NyaWJlZCBpbiBbUkZDNDA5 MF0gcmVtYWluIHJlbGV2YW50IHRvIHRoZSB1cGRhdGVzIGluIHRoaXMgZG9jdW1lbnQu4oCdDQoN CkknbSByZWFsbHkgbG9va2luZyBmb3Igc29tZXRoaW5nIHN1YnRhbnRpdmUsIHJhdGhlciB0aGFu IGp1c3QgYSBwb2ludGVyLg0KDQoNCg0KDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIENPTU1FTlQ6 DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgWW91IHJlZmVyIHRvIEZpZ3VyZSAyIG9uIHBhZ2Ug MyBhbmQgaXQgYXBwZWFycyBvbiBwYWdlIDEyLg0KICAgIFByb2JhYmx5IGVpdGhlciB5b3Ugc2hv dWxkIG1vdmUgaXQgdXAgb3IgbWFrZSBhIGNvcHkuDQoNCg0KPFJHPiBPaywgd2UgY2FuIGZpeCBp dCBhcyBwYXJ0IG9mIHRoZSBuZXh0IGVkaXRzLg0KDQpUaGFua3MsDQpSYWtlc2gNCg0KDQoNCg0K --_000_29D11F29BA3E49E6A4E6FD0FF61E9088ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4151B4426A975E408F4960E3AF608059@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5zMQ0KCXtt c28tc3R5bGUtbmFtZTpzMTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0K CWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MgRXJpYy4gRllJLCBXaWxs IHVwZGF0ZSB0aGUgU2VjdXJpdHkgU2VjdGlvbiBhcyBmb2xsb3dpbmcgdGhhdCBpbmNvcnBvcmF0 ZXMgeW91ciBzdWdnZXN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPuKA nFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBhIG5ldyBCWVBBU1NfQVNTSUdOTUVOVCBzdWJvYmpl Y3QgZm9yIHRoZSBSRUNPUkRfUk9VVEUgT2JqZWN0IHRoYXQgaXMgY2FycmllZCBpbiBhbiBSU1ZQ IHNpZ25hbGluZyBtZXNzYWdlLiZuYnNwOyBUaHVzIGluIHRoZSBldmVudCBvZiB0aGUgaW50ZXJj ZXB0aW9uIG9mIGEgc2lnbmFsaW5nIG1lc3NhZ2UsIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgTFNQ J3MgZmFzdCByZXJvdXRlIHByb3RlY3Rpb24gY2FuIGJlIGRlZHVjZWQgdGhhbiB3YXMgcHJldmlv dXNseSB0aGUgY2FzZS4mbmJzcDsgVGhpcyBpcyBqdWRnZWQgdG8gYmUgYSB2ZXJ5IG1pbm9yIHNl Y3VyaXR5IHJpc2sgYXMgdGhpcyBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IGF2YWlsYWJsZSBieSBv dGhlciBtZWFucy4mbmJzcDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPklmIGEgTVAgZG9lcyBub3QgZmluZCBhIG1hdGNoaW5nIGJ5cGFz cyB0dW5uZWwgd2l0aCBnaXZlbiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBsb2Nh bGx5LCBpdCBpZ25vcmVzIHRoZSBCWVBBU1NfQVNTSUdOTUVOVCBzdWJvYmplY3QuICZuYnNwO0R1 ZSB0byB0aGlzLCBzZWN1cml0eSByaXNrIGludHJvZHVjZWQgYnkgaW5zZXJ0aW5nIGEgcmFuZG9t IGFkZHJlc3MgaW4gdGhpcyBzdWJvYmplY3QgaXMgbWluaW1hbC48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7IFRoZSBOb3RpZnkg bWVzc2FnZSBmb3IgRlJSIEJ5cGFzcyBBc3NpZ25tZW50IEVycm9yIGRlZmluZWQgaW4gdGhpcyBk b2N1bWVudCBkb2VzIG5vdCByZXN1bHQgaW4gdGVhci1kb3duIG9mIHRoZSBwcm90ZWN0ZWQgTFNQ IGFuZCBpcyBub3Qgc2VydmljZSBhZmZlY3RpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5TZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3Ig UlNWUC1URSBhbmQgR01QTFMgc2lnbmFsaW5nIGV4dGVuc2lvbnMgYXJlIGNvdmVyZWQgaW4gWzxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMjA5IiB0aXRsZT0iJnF1b3Q7 UlNWUC1URTogRXh0ZW5zaW9ucyB0byBSU1ZQIGZvciBMU1AgVHVubmVscyZxdW90OyI+UkZDMzIw OTwvYT5dIGFuZCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM0NzMi IHRpdGxlPSImcXVvdDtHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcg KEdNUExTKSBTaWduYWxpbmcgUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wtIFRyYWZmaWMg RW5naW5lZXJpbmcgKFJTVlAtVEUpIEV4dGVuc2lvbnMmcXVvdDsiPlJGQzM0NzM8L2E+XS4mbmJz cDsgRnVydGhlciwgZ2VuZXJhbCBjb25zaWRlcmF0aW9ucyBmb3Igc2VjdXJpbmcgUlNWUC1URSBp biBNUExTLVRFIGFuZCBHTVBMUyBuZXR3b3JrcyBjYW4gYmUgZm91bmQgaW4gWzxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1OTIwIiB0aXRsZT0iJnF1b3Q7U2VjdXJpdHkg RnJhbWV3b3JrIGZvciBNUExTIGFuZCBHTVBMUyBOZXR3b3JrcyZxdW90OyI+UkZDNTkyMDwvYT5d LiZuYnNwOyBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgdGhlIG1lY2hhbmlzbXMgZGVmaW5lZCBpbiBb UkZDNDA5MF0sIHdoaWNoIGFsc28gZGlzY3Vzc2VzIHJlbGF0ZWQgc2VjdXJpdHkgbWVhc3VyZXMg YW5kIGFyZSBhbHNvIGFwcGxpY2FibGUgdG8gdGhpcyBkb2N1bWVudC4gJm5ic3A7QXMgc3BlY2lm aWVkIGluIFtSRkM0MDkwXSwgPHNwYW4gY2xhc3M9InMxIj5hIFBMUiBhbmQgaXRzPC9zcGFuPiA8 c3BhbiBjbGFzcz0iczEiPnNlbGVjdGVkIG1lcmdlIHBvaW50IHRydXN0IFJTVlAgbWVzc2FnZXMg cmVjZWl2ZWQgZnJvbSBlYWNoIG90aGVyLiA8L3NwYW4+Jm5ic3A7PHNwYW4gY2xhc3M9InMxIj5U aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcGVydGFpbmluZyB0byB0aGUgb3JpZ2luYWwgUlNW UCBwcm90b2NvbCBbUkZDMjIwNV0gYWxzbyByZW1haW4gcmVsZXZhbnQgdG8gdGhlIHVwZGF0ZXMg aW4gdGhpcyBkb2N1bWVudC7igJ08L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+UmFr ZXNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTtjb2xvcjpibGFjayI+RXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEF1Z3VzdCAyLCAyMDE3IGF0IDU6MDQgUE08YnI+DQo8 Yj5UbzogPC9iPiZxdW90Oz1TTVRQOnJnYW5kaGlAY2lzY28uIGNvbSZxdW90OyAmbHQ7cmdhbmRo aUBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5UaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9y ZyZndDssICZxdW90O2RyYWZ0LWlldGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGVAaWV0Zi5v cmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGVAaWV0Zi5v cmcmZ3Q7LCAmcXVvdDt0ZWFzLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7dGVhcy1jaGFpcnNA aWV0Zi5vcmcmZ3Q7LCAmcXVvdDt2YmVlcmFtQGp1bmlwZXIubmV0JnF1b3Q7ICZsdDt2YmVlcmFt QGp1bmlwZXIubmV0Jmd0OywgJnF1b3Q7dGVhc0BpZXRmLm9yZyZxdW90OyAmbHQ7dGVhc0BpZXRm Lm9yZyZndDssDQogREVCT1JBSCBCUlVOR0FSRCAmbHQ7ZGIzNTQ2QGF0dC5jb20mZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPlJlOiBFcmljIFJlc2NvcmxhJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm LXRlYXMtZ21wbHMtbHNwLWZhc3RyZXJvdXRlLTEwOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhdCBzZWVtcyBmaW5lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyAyLCAyMDE3IGF0IDE6NTkgUE0sIFJha2VzaCBHYW5kaGkg KHJnYW5kaGkpICZsdDs8YSBocmVmPSJtYWlsdG86cmdhbmRoaUBjaXNjby5jb20iIHRhcmdldD0i X2JsYW5rIj5yZ2FuZGhpQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSBFcmljLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5QbGVhc2Ugc2VlIGlubGluZSB3aXRoICZsdDtSRzIm Z3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNr Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjpibGFjayI+RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldl ZG5lc2RheSwgQXVndXN0IDIsIDIwMTcgYXQgMzo0NCBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7 PVNNVFA6cmdhbmRoaUBjaXNjby4gY29tJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmdhbmRo aUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5yZ2FuZGhpQGNpc2NvLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5UaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pZXNnQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLXRlYXMtZ21wbHMtbHNwLWZhc3RyZXJvdXRlQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLWxzcC1mYXN0cmVyb3V0ZUBpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXRlYXMtZ21wbHMtbHNw LWZhc3RyZXJvdXRlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi10ZWFzLWdt cGxzLWxzcC1mYXN0cmVyb3V0ZUBpZXRmLm9yZzwvYT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1h aWx0bzp0ZWFzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRlYXMtY2hhaXJzQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlYXMtY2hhaXJzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+dGVhcy1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEg aHJlZj0ibWFpbHRvOnZiZWVyYW1AanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj52YmVlcmFt QGp1bmlwZXIubmV0PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZiZWVyYW1AanVuaXBl ci5uZXQiIHRhcmdldD0iX2JsYW5rIj52YmVlcmFtQGp1bmlwZXIubmV0PC9hPiZndDssDQogJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50ZWFzQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj50ZWFzQGlldGYub3JnPC9hPiZndDssIERFQk9SQUggQlJVTkdBUkQgJmx0Ozxh IGhyZWY9Im1haWx0bzpkYjM1NDZAYXR0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRiMzU0NkBhdHQu Y29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IEVyaWMgUmVzY29ybGEncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGUtMTA6ICh3aXRoIERJ U0NVU1MgYW5kIENPTU1FTlQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgQXVnIDIsIDIwMTcgYXQgMTE6MzIgQU0sIFJha2Vz aCBHYW5kaGkgKHJnYW5kaGkpICZsdDs8YSBocmVmPSJtYWlsdG86cmdhbmRoaUBjaXNjby5jb20i IHRhcmdldD0iX2JsYW5rIj5yZ2FuZGhpQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEVyaWMsPGJyPg0KPGJyPg0KVGhhbmsgeW91IGZv ciB0aGUgcmV2aWV3IGFuZCB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIGluLWxpbmUgd2l0aCAm bHQ7UkcmZ3Q7LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCk9uIDIwMTctMDgtMDIsIDE6MzQgUE0sICZxdW90O0VyaWMgUmVzY29ybGEmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRm bS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEVyaWMgUmVzY29y bGEgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJyPg0KJm5i c3A7ICZuYnNwOyBkcmFmdC1pZXRmLXRlYXMtZ21wbHMtbHNwLWZhc3RyZXJvdXRlLTEwOiBEaXNj dXNzPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVw IHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGw8YnI+DQombmJzcDsgJm5i c3A7IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVl bCBmcmVlIHRvIGN1dCB0aGlzPGJyPg0KJm5ic3A7ICZuYnNwOyBpbnRyb2R1Y3RvcnkgcGFyYWdy YXBoLCBob3dldmVyLik8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFBsZWFzZSByZWZl ciB0byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNz LWNyaXRlcmlhLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbDwvYT48YnI+DQombmJzcDsgJm5ic3A7 IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3Np dGlvbnMuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KJm5i c3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXRlYXMtZ21wbHMtbHNwLWZhc3RyZXJvdXRlLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLWxzcC1m YXN0cmVyb3V0ZS88L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KJm5ic3A7ICZuYnNwOyBESVNDVVNTOjxicj4NCiZuYnNwOyAmbmJzcDsg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgV2hhdCBzdG9wcyBtZSBmcm9t IGp1c3QgcHJvdmlkaW5nIGEgcmFuZG9tIElQIGFkZHJlc3M8YnI+DQombmJzcDsgJm5ic3A7IHRo YXQgSSBkb24ndCBjb250cm9sIGluIEJZUEFTU19BU1NJR05NRU5UIGFuZCB0aHVzPGJyPg0KJm5i c3A7ICZuYnNwOyBjYXVzaW5nIHRoZW0gdG8gZ2V0IHNwYW1tZWQ/IEkgYW0gYXNzdW1pbmcgdGhl cmUgYXJlPGJyPg0KJm5ic3A7ICZuYnNwOyBtZWNoYW5pc21zIHRvIHByZXZlbnQgdGhlbSwgYnV0 IGl0J3Mgbm90IGltbWVkaWF0ZWx5PGJyPg0KJm5ic3A7ICZuYnNwOyBjbGVhciB0byBtZSB3aGF0 IHRob3NlIGFyZSwgc28gdGhleSBhdCBtaW5pbXVtIG5lZWQ8YnI+DQombmJzcDsgJm5ic3A7IHRv IHNwZWxsZWQgb3V0IGluIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PiZsdDtSRzImZ3Q7IEFzIG1lbnRpb25lZCBpbiB0aGUgUkZDNDA5MCwg4oCcUExSIGFuZCBNUCB0 cnVzdCB0aGUgUlNWUCBtZXNzYWdlcyByZWNlaXZlZCBmcm9tIGVhY2ggb3RoZXLigJ0uIFdlIGNh biBhZGQgdGhpcyB0ZXh0IGluIHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+4oCcSWYgYSBNUCBkb2VzIG5vdCBmaW5kIGEgbWF0Y2hpbmcgYnlwYXNzIHR1bm5l bCB3aXRoIGdpdmVuIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gYWRkcmVzc2VzIGxvY2FsbHksIGl0 IGlnbm9yZXMgdGhlIEJZUEFTU19BU1NJR05NRU5UIHN1Yi1vYmplY3Qu4oCdICZuYnNwO0R1ZSB0 byB0aGlzLCBzZWN1cml0eSByaXNrIGludHJvZHVjZWQNCiBpcyBtaW5pbWFsLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPlJha2VzaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGlz IHNlY3Rpb248YnI+DQombmJzcDsgJm5ic3A7IGZyb20gUkZDIDQwOTAgaXMgbm90IGVuY291cmFn aW5nOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQg ZG9lcyBub3QgaW50cm9kdWNlIG5ldyBzZWN1cml0eSBpc3N1ZXMuJm5ic3A7IFRoZSBzZWN1cml0 eTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbnNpZGVyYXRpb25zIHBlcnRhaW5p bmcgdG8gdGhlIG9yaWdpbmFsIFJTVlAgcHJvdG9jb2wgW1JTVlBdIHJlbWFpbjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlbGV2YW50Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO05vdGUgdGhhdCB0aGUgZmFjaWxpdHkgYmFja3VwIG1ldGhvZCByZXF1aXJl cyB0aGF0IGEgUExSIGFuZCBpdHM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWxl Y3RlZCBtZXJnZSBwb2ludCB0cnVzdCBSU1ZQIG1lc3NhZ2VzIHJlY2VpdmVkIGZyb20gZWFjaCBv dGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZsdDtSRyZndDsgT2ssIGhvdyBhYm91dCBhZGRpbmcgZm9sbG93aW5nIHRleHQgaW4gdGhl IHNlY3VyaXR5IHNlY3Rpb24/PGJyPg0KPGJyPg0K4oCcVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIHBlcnRhaW5pbmcgdG8gdGhlIG9yaWdpbmFsIFJTVlAgcHJvdG9jb2wgW1JGQzIyMDVdIGFz IHdlbGwgYXMgRmFzdCBSZXJvdXRlIHByb2NlZHVyZXMgZGVzY3JpYmVkIGluIFtSRkM0MDkwXSBy ZW1haW4gcmVsZXZhbnQgdG8gdGhlIHVwZGF0ZXMgaW4gdGhpcyBkb2N1bWVudC7igJ08bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JJ20gcmVhbGx5IGxvb2tpbmcgZm9yIHNvbWV0aGluZyBzdWJ0YW50aXZlLCByYXRoZXIgdGhh biBqdXN0IGEgcG9pbnRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQombmJzcDsg Jm5ic3A7IENPTU1FTlQ6PGJyPg0KJm5ic3A7ICZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyBZb3UgcmVmZXIgdG8gRmlndXJlIDIgb24gcGFnZSAzIGFuZCBpdCBh cHBlYXJzIG9uIHBhZ2UgMTIuPGJyPg0KJm5ic3A7ICZuYnNwOyBQcm9iYWJseSBlaXRoZXIgeW91 IHNob3VsZCBtb3ZlIGl0IHVwIG9yIG1ha2UgYSBjb3B5Ljxicj4NCjxicj4NCjxicj4NCiZsdDtS RyZndDsgT2ssIHdlIGNhbiBmaXggaXQgYXMgcGFydCBvZiB0aGUgbmV4dCBlZGl0cy48YnI+DQo8 YnI+DQpUaGFua3MsPGJyPg0KUmFrZXNoPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_29D11F29BA3E49E6A4E6FD0FF61E9088ciscocom_-- From nobody Wed Aug 2 15:07:54 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFA0131A4F; Wed, 2 Aug 2017 15:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtCFQIH6bxfK; Wed, 2 Aug 2017 15:07:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D6713218B; Wed, 2 Aug 2017 15:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19620; q=dns/txt; s=iport; t=1501711665; x=1502921265; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v+A+8qQa+0T4tkHBfCxfY8y8sZZ3f9Jx7fd2v4/wmsg=; b=koFT4OohJeERrbPEmLveZ2rxLnQzHmt85/AWWRoTLo4kS/MysFR3fasp qx9uhtlWcYI5lrWB23mV6ujFrjGLDmuYW/PdB8fSdDjlGPWwk+Fife7yK iFZzEUgZ2mKjobuMC8q2WSZjj5+tz+4CxvpxhtpJQoIDa3CxqisHSNq7O A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgAAA5TIJZ/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tZG0nB44HkAWBTIhWjVwOggQhC4UbAhqEGz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGQIBAwEBIRETIAcLEAIBCA4MAh8HAgICHwYLFRACBAENBRuJfAMVEK1Tg?= =?us-ascii?q?iaDPoNwDYQPAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4IdggKBTIFiLAuCcYJ?= =?us-ascii?q?XgWIHARIBBx8QIQKCWTCCMQWJZQeIZoxuPAKHUYNMhByEcYINhVaKYYlagkmJV?= =?us-ascii?q?wEfOH8LdxVJEgGFOYFNAXYBh0yBI4EPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,313,1498521600"; d="scan'208";a="277905415" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Aug 2017 22:07:43 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v72M7hXb012356 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2017 22:07:43 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Aug 2017 17:07:43 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Wed, 2 Aug 2017 17:07:43 -0500 From: "Rakesh Gandhi (rgandhi)" To: Alia Atlas , The IESG CC: "draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" , "vbeeram@juniper.net" , DEBORAH BRUNGARD Thread-Topic: [Teas] Alia Atlas' Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) Thread-Index: AQHTC8HQ5BvS+sJat0CLC5Cos2/nu6JxsRqA Date: Wed, 2 Aug 2017 22:07:42 +0000 Message-ID: <0666F681-D84D-4AA3-8538-9A5BDDD4FAED@cisco.com> References: <150170045164.5759.13003373677933598821.idtracker@ietfa.amsl.com> In-Reply-To: <150170045164.5759.13003373677933598821.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.247.50] Content-Type: text/plain; charset="utf-8" Content-ID: <26E64CD2A8E4874E8B123864F721852A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Alia Atlas' Discuss on draft-ietf-teas-gmpls-lsp-fastreroute-10: (with DISCUSS and COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 22:07:48 -0000 SGkgQWxpYSwNCg0KVGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3IG9mIHRoZSBkb2N1 bWVudCBhbmQgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZSBpbmxpbmUgd2l0aCA8Ukc+Lg0KDQpP biAyMDE3LTA4LTAyLCAzOjAwIFBNLCAiVGVhcyBvbiBiZWhhbGYgb2YgQWxpYSBBdGxhcyIgPHRl YXMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWthdGxhc0BnbWFpbC5jb20+IHdyb3Rl Og0KDQogICAgQWxpYSBBdGxhcyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCiAgICBkcmFmdC1pZXRmLXRlYXMtZ21wbHMtbHNwLWZhc3RyZXJvdXRlLTEwOiBE aXNjdXNzDQogICAgDQogICAgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVj dCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQogICAgZW1haWwgYWRkcmVzc2VzIGluY2x1 ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCiAgICBp bnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCiAgICANCiAgICANCiAgICBQbGVhc2Ug cmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0 ZXJpYS5odG1sDQogICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFu ZCBDT01NRU5UIHBvc2l0aW9ucy4NCiAgICANCiAgICANCiAgICBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLWxzcC1m YXN0cmVyb3V0ZS8NCiAgICANCiAgICANCiAgICANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgRElT Q1VTUzoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQogICAgMSkgSW4gU2VjIDQuNS4xOiAiVGhl IGRvd25zdHJlYW0gUExSIGNhbiBhc3NpZ24gYSBieXBhc3MgdHVubmVsIHdoZW4NCiAgICAgICBw cm9jZXNzaW5nIHRoZSBmaXJzdCBQYXRoIG1lc3NhZ2Ugb2YgdGhlIHByb3RlY3RlZCBMU1AsIGhv d2V2ZXIsIGl0DQogICAgICAgY2FuIG5vdCB1cGRhdGUgdGhlIGZvcndhcmRpbmcgcGxhbmUgdW50 aWwgaXQgcmVjZWl2ZXMgdGhlIFJlc3YNCiAgICAgICBtZXNzYWdlIGNvbnRhaW5pbmcgdGhlIGRv d25zdHJlYW0gTVAgbGFiZWwuIg0KICAgIA0KICAgIFBsZWFzZSBleHBsYWluIGhvdyB0aGUgZG93 bnN0cmVhbSBQTFIgY2FuIGFzc2lnbiBhIGJ5cGFzcyB0dW5uZWwgaWYgdGhlIExTUA0KICAgIGhh cyBhIGxvb3NlIEVSTyAtIHNvIHRoZSBkb3duc3RyZWFtIFBMUiBkb2VzIG5vdCBrbm93IHRoZSBu ZXh0LW5leHQtaG9wIHRoYXQNCiAgICB3b3VsZCBiZSB0aGUgTVAgZm9yIGEgbm9kZS1wcm90ZWN0 aW5nIExTUC4NCiAgICANCjxSRz4gVGhpcyBzZW50ZW5jZSBzaG91bGQgYmUgdXBkYXRlZCBhcyDi gJxXaXRoIGV4Y2VwdGlvbiBvZiB0aGUgQUJSIG5vZGUgcHJvdGVjdGlvbiBjYXNlLCB3aGVyZSB0 aGUgYnlwYXNzIHR1bm5lbCBzdGFydHMgYW5kIGVuZHMgaW4gZGlmZmVyZW50IGRvbWFpbnMs4oCd DQoNCg0KICAgIDIpIFNlYyA0LjUuMTogIkFuIHVwc3RyZWFtIFBMUiAoZG93bnN0cmVhbSBNUCkg U0hPVUxEIGNoZWNrIGFsbA0KICAgIEJZUEFTU19BU1NJR05NRU5UDQogICAgICAgc3Vib2JqZWN0 cyBpbiB0aGUgUGF0aCBSUk8gaW4gb3JkZXIgdG8gYXNzaWduIGEgcmV2ZXJzZSBieXBhc3MNCiAg ICAgICB0dW5uZWwuICBUaGUgdXBzdHJlYW0gUExSIHRoYXQgZGV0ZWN0cyBhIEJZUEFTU19BU1NJ R05NRU5UIHN1Ym9iamVjdCwNCiAgICAgICBzZWxlY3RzIGEgcmV2ZXJzZSBieXBhc3MgdHVubmVs IHRoYXQgdGVybWluYXRlcyBsb2NhbGx5IHdpdGggdGhlDQogICAgICAgZGVzdGluYXRpb24gYWRk cmVzcyBhbmQgdHVubmVsLUlEIGZyb20gdGhlIHN1Ym9iamVjdCwgYW5kIGhhcyBhDQogICAgICAg c291cmNlIGFkZHJlc3MgbWF0Y2hpbmcgdGhlIE5vZGUtSUQgYWRkcmVzcy4iDQogICAgDQogICAg VGhpcyBpc24ndCB2ZXJ5IGNsZWFyIC0gcGFydGljdWxhcmx5IGdpdmVuIHRoYXQgdGhlcmUgd2ls bCBiZSBtYW55DQogICAgQllQQVNTX0FTU0lHTk1FTlQgc3Vib2JqZWN0cyBpbiB0aGUgcGF0aCBS Uk8uICBUaGUgY2FzZSBvZiBCWVBBU1NfQVNTSUdOTUVOVA0KICAgIHN1Yi1vYmplY3RzIGJlaW5n IHJlbW92ZWQgb3IgY2hhbmdlZCBpcyBub3QgYWRkcmVzc2VkIGF0IGFsbC4gIEluIGFkZGl0aW9u LCBJDQogICAgKmFzc3VtZSogdGhhdCB0aGUgZmFpbHVyZSB0byB0cmVhdCB0aGUgZGVzdGluYXRp b24gSVAgYWRkcmVzcyBpbiB0aGUNCiAgICBCWVBBU1NfQVNTSUdOTUVOVCBhcyB0aGUgc291cmNl IElQIGFkZHJlc3MgZm9yIHRoZSB1cHN0cmVhbSBCeXBhc3MgdHVubmVsIGlzIGFuDQogICAgb3Zl cnNpZ2h0Pw0KICAgIA0KICAgIEkgYmVsaWV2ZSB0aGF0IHdoYXQgaXMgbWVhbnQgIGlzOg0KICAg IA0KICAgICJBbiB1cHN0cmVhbSBQTFIgKGRvd25zdHJlYW0gTVApIFNIT1VMRCBjaGVjayBhbGwg QllQQVNTX0FTU0lHTk1FTlQgc3ViLW9iamVjdHMNCiAgICBpbiB0aGUgUGF0aCBSUk8gdG8gc2Vl IGlmIHRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzIGluIHRoZSBCWVBBU1NfQVNTSUdOTUVOVA0K ICAgIG1hdGNoZXMgYW4gYWRkcmVzcyBvZiB0aGUgdXBzdHJlYW0gUExSLiAgRm9yIGVhY2ggQllQ QVNTX0FTU0lHTk1FTlQgc3ViLW9iamVjdA0KICAgIHRoYXQgbWF0Y2hlcywgdGhlIHVwc3RyZWFt IFBMUiBsb29rcyBmb3IgYSBsb2NhbCBieXBhc3MgdHVubmVsIHRoYXQgaGFzIGENCiAgICBkZXN0 aW5hdGlvbiBtYXRjaGluZyB0aGUgZG93bnN0cmVhbSBQTFIgdGhhdCBpbnNlcnRlZCB0aGUgQllQ QVNTX0FTU0lHTk1FTlQsIGFzDQogICAgaW5kaWNhdGVkIGJ5IHRoZSBOb2RlLUlEIGFkZHJlc3Ms IGFuZCB0aGUgc2FtZSB0dW5uZWwtSUQgYXMgaW5kaWNhdGVkIGluIHRoZQ0KICAgIEJZUEFTU19B U1NJR05NRU5ULiINCiAgICANCjxSRz4gWW91ciBzdWdnZXN0ZWQgdGV4dCBsb29rcyBnb29kLg0K DQogICAgSSByZWNhbGwgdGhhdCB0dW5uZWwtSUQgaXMgdXN1YWxseSBzY29wZWQgYnkgdGhlIGFk ZHJlc3Mgb2YgdGhlIGluZ3Jlc3MgTFNSOw0KICAgIHRoaXMgc2VlbXMgdG8gYXNzdW1lIHRoYXQg dGhlIHNhbWUgdHVubmVsLUlEIGlzIHByb3ZpZGVkIHRvIGJvdGggdGhlIGRvd25zdHJlYW0NCiAg ICBQTFIgYW5kIHVwc3RyZWFtIFBMUj8/PyBBbHRlcm5hdGVseSwgSSBhbSBtaXN1bmRlcnN0YW5k aW5nIC0gYW5kIHRoZQ0KICAgIGluZm9ybWF0aW9uIGluIHRoZSBCWVBBU1NfQVNTSUdOTUVOVCBp cyByZWFsbHkgaW50ZW5kZWQgdG8gYmUgYnlwYXNzIHR1bm5lbCB0bw0KICAgIGJlIHVzZWQgYnkg dGhlIHVwc3RyZWFtIFBMUiwgd2hpY2ggdGhlIGRvd25zdHJlYW0gUExSIHNvbWVob3coPz9kZXRh aWxzLCBoaW50cw0KICAgIGluIHRoZSBkb2N1bWVudCBwbGVhc2UpIGtub3dzIC4NCg0KPFJHPiBU aGUgUExSIGFkZHMgdGhlIEZFQyBvZiB0aGUgYnlwYXNzIHR1bm5lbCAoU291cmNlL0Rlc3RpbmF0 aW9uL3R1bm5lbC1JRCkuIFRoZSBNUCB1c2VzIHRoZSBGRUMgZm9yIGxvb2t1cC4NCiAgICANCiAg ICBUaGVuIHRoZXJlIG5lZWRzIHRvIGJlIHRleHQgdG8gaGFuZGxlIHRoZSBjYXNlIHdoZXJlIHRo ZSBwcmV2aW91cyBQQVRIIG1lc3NhZ2UNCiAgICBjb250YWluZWQgYSBwYXJ0aWN1bGFyIEJZUEFT U19BU1NJR05NRU5UIHN1Yi1vYmplY3QgYW5kIHRoYXQgc3ViLW9iamVjdCBoYXMNCiAgICBiZWVu IHJlbW92ZWQgb3IgY2hhbmdlZC4NCg0KPFJHPiBZZXMsIHdlIGNhbiBhZGQgYSBzZW50ZW5jZSB0 byBjbGFyaWZ5Lg0KICAgIA0KICAgIDMpIFNlYyA0LjUuMzogIkluIGJvdGggZXhhbXBsZXMgYWJv dmUsIHRoZSB1cHN0cmVhbSBQTFIgU0hPVUxEIHNlbmQgYSBOb3RpZnkNCiAgICBtZXNzYWdlDQog ICAgICAgW1JGQzM0NzNdIHdpdGggRXJyb3ItY29kZSAtIEZSUiBCeXBhc3MgQXNzaWdubWVudCBF cnJvciAodmFsdWU6IFRCQTEpDQogICAgICAgYW5kIFN1Yi1jb2RlIC0gQnlwYXNzIEFzc2lnbm1l bnQgQ2Fubm90IEJlIFVzZWQgKHZhbHVlOiBUQkEyKSB0byB0aGUNCiAgICAgICBkb3duc3RyZWFt IFBMUiB0byBpbmRpY2F0ZSB0aGF0IGl0IGNhbm5vdCB1c2UgdGhlIGJ5cGFzcyB0dW5uZWwNCiAg ICAgICBhc3NpZ25tZW50IGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbi4gIFVwb24gcmVjZWl2aW5n IHRoaXMgZXJyb3IsIHRoZQ0KICAgICAgIGRvd25zdHJlYW0gUExSIE1BWSByZW1vdmUgdGhlIGJ5 cGFzcyB0dW5uZWwgYXNzaWdubWVudCBhbmQgc2VsZWN0IGFuDQogICAgICAgYWx0ZXJuYXRlIGJ5 cGFzcyB0dW5uZWwgaWYgb25lIGF2YWlsYWJsZS4iDQogICAgDQogICAgVGhpcyBzZWN0aW9uIGlz IHByb2JsZW1hdGljIGJlY2F1c2UgaXQgY3JlYXRlcyB0aGUgdXNlIG9mIGxvY2FsIHBvbGljeSB3 aGVuIHRoZQ0KICAgIGluZ3Jlc3MgaGFzIGEgY2xlYXIgd2F5IHRvIHNpZ25hbCB3aGF0IHR5cGUg b2YgcHJvdGVjdGlvbiBpcyBkZXNpcmVkIGFuZA0KICAgIGJlY2F1c2UgaXQgcHJvdmlkZXMgYW4g ZXJyb3IgbWVzc2FnZSB0byB3aGVyZSBpdCB3aWxsIG9ubHkgY2F1c2UgcG9pbnRsZXNzDQogICAg Y2h1cm4gKHRoZSBNUCBpcyB0aGUgTVAgYmFzZWQgb24gdGhlIHR5cGUgb2YgcHJvdGVjdGlvbiBk ZXNpcmVkIC0gY2VydGFpbmx5IGZvcg0KICAgIGJ5cGFzcykgcmF0aGVyIHRoYW4gdG8gdGhlIGlu Z3Jlc3Mgd2hlcmUgaXQgY291bGQgYXQgbGVhc3QgYmUgYWN0ZWQgdXBvbi4gIFRoZQ0KICAgIGR5 bmFtaWNzIGF0IHRpbWUgb2YgZmFpbHVyZSBhbHNvIGRvIG5vdCBzZWVtIHRvIGJlIHdlbGwgY29u c2lkZXJlZDsgYXN5bW1ldHJ5DQogICAgaXMgdW5mb3J0dW5hdGUsIGJ1dCB3b3JzZSBpcyBsYWNr IG9mIHByb3RlY3Rpb24uDQogICAgDQogICAgQ29uc2lkZXIgdGhlIGNhc2UgaW4gRXhhbXBsZSAx LiAgSWYgUjUgc3VmZmVycyBhIG5vZGUgZmFpbHVyZSwgdGhlbiB0aGVyZSBpcyBubw0KICAgIHBy b3RlY3Rpb24gZm9yIHRoZSB1cHN0cmVhbSBMU1AgZnJvbSBSNiBpZiBpdCBwcmVmZXJzIHRoZSBs aW5rIHByb3RlY3Rpb24uICBJdA0KICAgIHNpbXBseSBkb2Vzbid0IG1hdHRlciB3aGF0IGJ5cGFz cyB0dW5uZWwgUjQgcGlja3MhIFNlbmRpbmcgYSBOb3RpZnkgbWVzc2FnZSB0bw0KICAgIFI0IGFz a2luZyBmb3IgYSBkaWZmZXJlbnQgdHVubmVsIGlzIG5vdCBwcm9kdWN0aXZlLiAgSWYgdGhlIGlu Z3Jlc3MgaGFzDQogICAgcmVxdWVzdGVkIG5vZGUtcHJvdGVjdGlvbiwgdGhlbiB0aGVyZSBpcyBz aW1wbHkgbm90aGluZyB0aGF0IGNhbiBiZSBkb25lIGZvcg0KICAgIHRoaXMgdG9wb2xvZ3kgYnkg UjUuICBJdCBjb3VsZCBiZSBoZWxwZnVsIHRvIHNlbmQgYSBOb3RpZnkgdG8gdGhlIGluZ3Jlc3Mg b3INCiAgICBoYXZlIGEgZmxhZyBzZXQgaW4gdGhlIFJFU1YgUlJPIHRvIGluZGljYXRlIHRoZSBp c3N1ZSwgYnV0IHRoYXQncyBhYm91dCBpdC4NCiAgICANCiAgICBGb3IgdGhlIHF1ZXN0aW9uIGFi b3V0IGNyZWF0aW5nIGxvY2FsIHBvbGljeSwgaG93IGFyZSB0aGUgU0VTU0lPTl9BVFRSSUJVVEVT DQogICAgdXNlZD8gIE9idmlvdXNseSwgdGhleSBhcmUgYXZhaWxhYmxlIGluIHRoZSBQQVRIIG1l c3NhZ2UgdGhhdCBoYXMgdGhlDQogICAgQllQQVNTX0FTU0lHTk1FTlRzLiAgV2h5IHdvdWxkIHRo ZSAiTm9kZSBQcm90ZWN0aW9uIERlc2lyZWQiIGZsYWcgbm90IGJlDQogICAgcmVsZXZhbnQgaGVy ZT8NCg0KPFJHPiBUaGUgZG9jdW1lbnQgaGlnaC1saWdodHMgdGhlIGlzc3VlIHRoYXQgY2FuIG9j Y3VyIGR1ZSB0byBkaWZmZXJlbnQgbG9jYWwgcG9saWNpZXMgb24gUExSIGFuZCBNUCBub2RlcyBh bmQgaGVuY2UgdGhleSBzaG91bGQgbm90IGJlIHByb3Zpc2lvbmVkIHRoYXQgd2F5IHRvIGF2b2lk IGl04pi6DQo8Ukc+IFdlIGNhbiBhZGQgYSBzZW50ZW5jZSB0byBpbmRpY2F0ZSB0aGF0IFNlc3Np b24gYXR0cmlidXRlcyBmbGFncyBhcmUgY2FycmllZCBpbiB0aGUgZm9yd2FyZCBhbmQgcmV2ZXJz ZSBkaXJlY3Rpb25zIGFuZCBjYW4gYmUgdXNlZCBieSB0aGUgUExSIGFuZCBNUCBub2RlcyBpbiBj YXNlIHRoZXJlIGFyZSBkaWZmZXJlbnQgbG9jYWwgcG9saWNpZXMuDQoNCiAgICANCiAgICA0KSBT ZWMgNTogIiAgIG8gIFVwc3RyZWFtIFBMUiByZXJvdXRlcyB0cmFmZmljIHVwb24gZGV0ZWN0aW5n IHRoZSBsaW5rIGZhaWx1cmUNCiAgICBvcg0KICAgICAgICAgIHVwb24gcmVjZWl2aW5nIFJTVlAg UGF0aCBtZXNzYWdlIG92ZXIgdGhlIGJpZGlyZWN0aW9uYWwgYnlwYXNzDQogICAgICAgICAgdHVu bmVsLg0KICAgIA0KICAgICAgIG8gIFVwc3RyZWFtIFBMUiBhbHNvIHJlcm91dGVzIFJTVlAgUmVz diBzaWduYWxpbmcgYWZ0ZXIgcmVjZWl2aW5nDQogICAgICAgICAgUlNWUCBQYXRoIG1lc3NhZ2Ug b3ZlciB0aGUgYmlkaXJlY3Rpb25hbCBieXBhc3MgdHVubmVsLiAiDQogICAgDQogICAgSG93IGRv ZXMgdGhlIHVwc3RyZWFtIFBMUiBkZXRlY3QgdGhhdCB0aGUgbWVzc2FnZSB3YXMgcmVjZWl2ZWQg b3ZlciB0aGUgYnlwYXNzDQogICAgdHVubmVsPyAgSXMgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUg YnlwYXNzIExTUCBkb2Vzbid0IGRvIHBlbnVsdGltYXRlIGhvcA0KICAgIHBvcHBpbmc/IElzIHRo ZSBhc3N1bXB0aW9uIHRoYXQgdGhlIFBMUiBjYW4gdGVsbCBiZWNhdXNlIFJTVlAgaW5kaWNhdGVz IHRoZQ0KICAgIGRvd25zdHJlYW0gUExSIGFzIHRoZSBwcmV2aW91cyBob3AgaW4gaXRzIHNpZ25h bGluZz8gIFBsZWFzZSBjbGFyaWZ5IGFuZA0KICAgIGRlc2NyaWJlIGhvdyB0aGlzIGRldGVjdGlv biBpcyBkb25lIC0gdG8gZWFzZSBpbnRlcm9wZXJhYmlsaXR5Lg0KDQo8Ukc+IFJGQyA0MDkwIGhh cyBkZXRhaWxzIG9uIHdoYXQgaXMgY2hhbmdlZCB3aGVuIHByaW1hcnkgTFNQIG1lc3NhZ2VzIGFy ZSBzZW50IG92ZXIgdGhlIGJ5cGFzcy4gTm8gY2hhbmdlIGluIHRoZSBwcm9jZXNzaW5nIHJlcXVp cmVkIGluIHRoaXMgZG9jdW1lbnQgZm9yIHRoaXMgY2FzZSBmb3IgTVAgdG8gZGV0ZWN0IEZSUi4N CjxSRz4gV2UgY291bGQgaW5kaWNhdGUg4oCcdXNpbmcgdGhlIHByb2NlZHVyZSBkZWZpbmVkIGlu IFtSRkM0MDkwXeKAnS4NCiAgICANCiAgICA1KSBJbiBTZWMgNS4xLjI6ICAiV2hlbiB1cHN0cmVh bSBQTFIgUjQgcmVjZWl2ZXMgdGhlIHByb3RlY3RlZCBMU1AgUGF0aA0KICAgIG1lc3NhZ2VzIG92 ZXINCiAgICAgICAgICB0aGUgcmVzdG9yZWQgbGluaywgaWYgbm90IGFscmVhZHkgZG9uZSwgaXQg c3RhcnRzIHNlbmRpbmcgUmVzdg0KICAgICAgICAgIG1lc3NhZ2VzIGFuZCB0cmFmZmljIGZsb3cg b2YgdGhlIHByb3RlY3RlZCBMU1Agb3ZlciB0aGUgcmVzdG9yZWQNCiAgICAgICAgICBsaW5rIGFu ZCBzdG9wcyBzZW5kaW5nIHRoZW0gb3ZlciB0aGUgYnlwYXNzIHR1bm5lbC4iDQogICAgDQogICAg SXMgdGhlcmUgYSByZWFzb24gdGhhdCAid2hlbiB0aGUgZG93bnN0cmVhbSBQTFIgcmVjZWl2ZXMg dGhlIHByb3RlY3RlZCBMU1AgUkVTVg0KICAgIG1lc3NhZ2VzIG92ZXIgdGhlIHJlc3RvcmVkIGxp bmssIGlmIG5vdCBhbHJlYWR5IGRvbmUsIGl0IHN0YXJ0cyBzZW5kaW5nIFBhdGgNCiAgICBtZXNz YWdlcyBhbmQgdHJhZmZpYyBmbG93IG9mIHRoZSBwcm90ZWN0ZWQgTFNQIG92ZXIgdGhlIHJlc3Rv cmVkIGxpbmsgYW5kIHN0b3BzDQogICAgc2VuZGluZyB0aGVtIG92ZXIgdGhlIGJ5cGFzcyB0dW5u ZWwuIiBkb2Vzbid0IGFsc28gbWFrZSBzZW5zZSB0byBwdXQgaW4gdGhpcw0KICAgIHNlY3Rpb24/ DQogICAgDQogICAgSWYgdGhpcyBpcyBub3QgYSBnb29kIGlkZWEsIHBsZWFzZSBleHBsYWluIGNs ZWFybHkgdGhlIGlzc3VlcyB0aGF0IGl0IGNhdXNlcy4NCg0KPFJHPiBUaGlzIHdhcyB1cGRhdGVk IGluIHRoZSBsYXN0IHJldmlzaW9uIHRvIGtlZXAgdGhlIHByb2Nlc3Npbmcgc3ltbWV0cmljIOKA kyBiZWZvcmUgRlJSIGFuZCBmb3IgcmVzdG9yYXRpb24gYWZ0ZXIgRlJSLg0KICAgIA0KICAgIEkg YW0gYXNzdW1pbmcgdGhhdCAiYWZ0ZXIgdGhlIGxpbmsgaXMgcmVzdG9yZWQiIGltcGxpZXMgdGhh dCBiaWRpcmVjdGlvbmFsDQogICAgY29tbXVuaWNhdGlvbiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg dGVzdGVkIC0gbm90IG1lcmVseSB0aGF0IHRoZSBwaHlzaWNhbCBsYXllcg0KICAgIGlzIHVwIGJ1 dCBhbHNvIHRoYXQgYW4gSUdQIG9yIEJGRCBpcyBzdWNjZXNzZnVsIGFjcm9zcyBpdC4gKEJ1dCB0 aGlzIGlzDQogICAgc3RhbmRhcmQgZm9yIFJTVlAtVEUgRlJSKS4NCiAgICANCiAgICA2KSBTZWMg NS4yLjI6IFRoZSBiZWhhdmlvciBvZiBSNCBpcyBub3QgZGVzY3JpYmVkLiAgV2hlbiB0aGUgbGlu ayBmcm9tIFIzLVI0DQogICAgZmFpbHMsIFI0IHdpbGwgcmVkaXJlY3QgdHJhZmZpYyB0byBSMi4g QXMgd3JpdHRlbiBhdCB0aGUgc3RhcnQgb2YgU2VjIDUsIFI0DQogICAgZG9lcyBub3Qgc3RhcnQg c2VuZGluZyBpdHMgUmVzdiBhY3Jvc3MgdGhlIGJ5cGFzcyB0dW5uZWwgYW5kIFIyIGlzIHRodXMg bm90DQogICAgdHJpZ2dlcmVkIHRvIHVzZSBpdHMgYnlwYXNzIHR1bm5lbC4gIFBsZWFzZSBjbGVh cmx5IGRlc2NyaWJlIHRoaXMgYW5kIHdoeS4gIEl0DQogICAgaXMgdGhpcyBhc3ltbWV0cnkgaW4g YmVoYXZpb3IgZm9yIHRoZSBkb3duc3RyZWFtIFBMUiBhbmQgdXBzdHJlYW0gUExSIHRoYXQNCiAg ICBjYXVzZXMgdGhlIGRvd25zdHJlYW0gUExSJ3MgYnlwYXNzIHR1bm5lbCB0byBiZSBwcmlvcml0 aXplZC4NCg0KPFJHPiBSNCBpcyBub3QgaW52b2x2ZWQgaW4gcmUtY29yb3V0aW5nIHBoYXNlLiBJ dCBkb2VzIG5vcm1hbCBGUlIgcHJvY2Vzc2luZyAoZS5nLiBTZWN0aW9uIDUuMS4xKS4NCg0KICAg IA0KICAgIDcpIFNlYyA1LjIuMjogVGhlIG5lZWQgZm9yIHRoZSBQUlIgdG8gbG9vayB1cCB0aGUg YnlwYXNzIHR1bm5lbCBhbmQgdGhlbg0KICAgIHJlcHJvZ3JhbSB0aGUgZm9yd2FyZGluZyBwbGFu ZSBpcyBxdWl0ZSBjb25jZXJuaW5nIGZvciBoYXZpbmcgdGhpcyBvcGVyYXRlIGF0DQogICAgc2ln bmlmaWNhbnQgc2NhbGUuICBXaGF0IGNvdWxkIGJlIGRvbmUgaWYgb25lIGFzc3VtZXMgdGhhdCB0 aGUgc2VsZWN0ZWQgYnlwYXNzDQogICAgdHVubmVsIC0gZnJvbSB0aGUgQllQQVNTX1BST1RFQ1RJ T04gaGFuZGxpbmcgLSBpcyB1c2VkPyAgSXMgdGhlcmUgYSByZWFzb24gdGhhdA0KICAgIGRlY2lz aW9uIGhhcyB0byBiZSByZWRvbmUgaGVyZT8gV2hhdCBpcyB0aGUgaXNzdWUgdGhhdCB0aGUgc29s dXRpb24gaXMgdHJ5aW5nDQogICAgdG8gd29yayBhcm91bmQ/ICAgSSBjYW4gY2VydGFpbmx5IGlt YWdpbmUgc2NlbmFyaW9zIHdpdGggQkZEIHNlc3Npb25zIHNvIHRoYXQNCiAgICB0aGUgUFJSIGNh biBiZSByYXBpZGx5IGZhaWxlZCBvdmVyIGFzIHRoZSByZXN1bHQgb2YgdGhlIEJGRCBzZXNzaW9u IGdvaW5nIGRvd24uDQogICAgIFdoYXQgc2NhbGUgb2YgTFNQcyBhcmUgeW91IGV4cGVjdGluZyB0 aGlzIHNjZW5hcmlvIHRvIGhhbmRsZT8NCg0KPFJHPiBUaGlzIGlzIG5vdCBhIOKAnG5vcm1hbOKA nSBjYXNlLiANCg0KICAgIA0KICAgIDgpIFNlYyA1LjIuMjogR2l2ZW4gdGhhdCB0aGUgUFJSIHdp bGwgVEVBUiBET1dOIHRoZSBMU1AgaWYgaXQgY2FuJ3QgZmluZCBhDQogICAgbWF0Y2hpbmcgYnlw YXNzIHR1bm5lbCwgaXQgd291bGQgYmUgcXVpdGUgdXNlZnVsIGZvciB0aGUgaW5ncmVzcyB0byBo YXZlDQogICAgdmlzaWJpbGl0eSBhcyB0byB0aGUgcHJvdGVjdGlvbiBhdmFpbGFibGUuICBJbiBS RkMgNDA5MCwgU2VjIDQuNCBkZWZpbmVzIGJvdGgNCiAgICAibG9jYWwgcHJvdGVjdGlvbiBhdmFp bGFibGUiIGFuZCAibG9jYWwgcHJvdGVjdGlvbiBpbiB1c2UiIGZsYWdzIGluIHRoZQ0KICAgIElQ djQvSVB2NiBzdWItb2JqZWN0cy4gIENsZWFybHksIHRoYXQgaXNuJ3Qgc3VmZmljaWVudCBmb3Ig dGhlIGNvLXJvdXRlZCBjYXNlDQogICAgYmVjYXVzZSB0aGUgaW5ncmVzcyBuZWVkcyB0byBrbm93 IGFsc28gdGhhdCAibG9jYWwgdXBzdHJlYW0gcHJvdGVjdGlvbg0KICAgIGF2YWlsYWJsZSIgYW5k IHBlcmhhcHMgImxvY2FsIHVwc3RyZWFtIHByb3RlY3Rpb24gaW4gdXNlIi4NCg0KPFJHPiBZZXMs IHRoZXNlIGZsYWdzIGFyZSBkZWZpbml0ZWx5IHVzZWQsIHNlZSBTZWN0aW9uIDQuNC4NCg0KICAg IA0KICAgIDkpIFNlYyA1LjIuMzogIiAgIG8gIFRoZSB1cHN0cmVhbSBQTFIgUjQgc3RhcnRzIHNl bmRpbmcgdGhlIHRyYWZmaWMgZmxvdyBvZiB0aGUNCiAgICAgICAgICBwcm90ZWN0ZWQgTFNQIG92 ZXIgdGhlIHJlc3RvcmVkIGxpbmsgdG93YXJkcyBkb3duc3RyZWFtIFBMUiBSMyBhbmQNCiAgICAg ICAgICBmb3J3YXJkaW5nIHRoZSBQYXRoIG1lc3NhZ2VzIHRvd2FyZHMgUFJSIFI1IGFuZCBzdG9w cyBzZW5kaW5nIHRoZQ0KICAgICAgICAgIHRyYWZmaWMgb3ZlciB0aGUgYnlwYXNzIHR1bm5lbC4N CiAgICANCiAgICAgICBvICBXaGVuIHVwc3RyZWFtIFBMUiBSNCByZWNlaXZlcyB0aGUgcHJvdGVj dGVkIExTUCBQYXRoIG1lc3NhZ2VzIG92ZXINCiAgICAgICAgICB0aGUgcmVzdG9yZWQgbGluaywg aWYgbm90IGFscmVhZHkgZG9uZSwgaXQgc3RhcnRzIHNlbmRpbmcgUmVzdg0KICAgICAgICAgIG1l c3NhZ2VzIGFuZCB0cmFmZmljIGZsb3cgb3ZlciB0aGUgcmVzdG9yZWQgbGluayB0b3dhcmRzDQog ICAgICAgICAgZG93bnN0cmVhbSBQTFIgUjMgYW5kIGZvcndhcmRpbmcgdGhlIFBhdGggbWVzc2Fn ZXMgdG93YXJkcyBQUlIgUjUNCiAgICAgICAgICBhbmQgc3RvcHMgc2VuZGluZyB0aGVtIG92ZXIg dGhlIGJ5cGFzcyB0dW5uZWwuIg0KICAgIA0KICAgIEluIHRoZSByZWZlcmVuY2VkIGZpZ3VyZXMs IFI0IGlzIE5PVCBhbiB1cHN0cmVhbSBQTFI7IHRoYXQgaXMgUjUuICBSNCBjb3VsZA0KICAgIGhh dmUgZm9yZ290dGVuIGFsbCBzdGF0ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGJpLWRpcmVjdGlvbmFs IExTUC4gICBQbGVhc2UgZml4DQogICAgdGhlIHRleHQgdG8gYWN0dWFsbHkgZGVzY3JpYmUgdGhl IGJlaGF2aW9yLg0KICAgIA0KDQo8UjQ+IFI0IGlzIHRoZSBub2RlIHdoZXJlIHJlc3RvcmVkIGxp bmsgaXMgZGV0ZWN0ZWQgaW4gRmlndXJlIDMuIFNvIGl0IGlzIGRvaW5nIHRoZSB1cHN0cmVhbSBQ TFIgcHJvY2Vzc2luZyBmb3IgbGluayByZXN0b3JhdGlvbiBjYXNlLg0KDQoNCiAgICAxMCkgU2Vj IDUuMzogIiAgIFVuaWRpcmVjdGlvbmFsIGxpbmsgZmFpbHVyZXMgY2FuIHJlc3VsdCBpbiB0aGUg dHJhZmZpYyBmbG93aW5nDQogICAgb24NCiAgICAgICBhc3ltbWV0cmljIHBhdGhzIGluIHRoZSBm b3J3YXJkIGFuZCByZXZlcnNlIGRpcmVjdGlvbnMuICBJbiBhZGRpdGlvbiwNCiAgICAgICB1bmlk aXJlY3Rpb25hbCBsaW5rIGZhaWx1cmVzIGNhbiBjYXVzZSBSU1ZQIHNvZnQtc3RhdGUgdGltZW91 dCBpbiB0aGUNCiAgICAgICBjb250cm9sLXBsYW5lIGluIHNvbWUgY2FzZXMuICBBcyBhbiBleGFt cGxlLCBpZiB0aGUgdW5pZGlyZWN0aW9uYWwNCiAgICAgICBsaW5rIGZhaWx1cmUgaXMgaW4gdGhl IHVwc3RyZWFtIGRpcmVjdGlvbiAoZnJvbSBSNCB0byBSMyBpbiBGaWd1cmVzIDENCiAgICAgICBh bmQgMiksIHRoZSBkb3duc3RyZWFtIFBMUiAobm9kZSBSMykgY2FuIHN0b3AgcmVjZWl2aW5nIHRo ZSBSZXN2DQogICAgICAgbWVzc2FnZXMgb2YgdGhlIHByb3RlY3RlZCBMU1AgZnJvbSB0aGUgdXBz dHJlYW0gUExSIChub2RlIFI0IGluDQogICAgICAgRmlndXJlcyAxIGFuZCAyKSBhbmQgdGhpcyBj YW4gY2F1c2UgUlNWUCBzb2Z0LXN0YXRlIHRpbWVvdXQgdG8gb2NjdXINCiAgICAgICBvbiB0aGUg ZG93bnN0cmVhbSBQTFIgKG5vZGUgUjMpLiINCiAgICANCiAgICBJcyB0aGUgYXNzdW1wdGlvbiB0 aGF0IHRoZXJlIGlzIG5vIElHUCBvciBCRkQgcnVubmluZyBvbiB0aGUgbGluaz8gSWYgbm90LCB0 aGVuDQogICAgdGhlIElHUCBvciBCRkQgc2Vzc2lvbiB3aWxsIGdvIGRvd24gb24gdGhlIGxpbmsg Zmlyc3QsIG1ha2luZyBpdCB1bmF2YWlsYWJsZSB0bw0KICAgIFJTVlAtVEUgYW5kIHNob3VsZCB0 cmlnZ2VyIHRoZSBmYXN0LXJlcm91dGUuDQogICAgDQogICAgQWxzbyAtIGdpdmVuIHRoaXMgaXNz dWUsIHdoeSBkb2VzIHRoZSB1cHN0cmVhbSBNUCBub3Qgc3RhcnQgdXNpbmcgdGhlIGJ5cGFzcw0K ICAgIHR1bm5lbCB3aGVuIHJlY2VpdmluZyBSZXN2IHRocm91Z2ggYSBieXBhc3MgdHVubmVsPyBU aGVyZSBpcyBubyBleHBsYW5hdGlvbiBpbg0KICAgIHRoZSBkcmFmdCBhbmQgdGhlcmUgc2hvdWxk IGJlIC0gdG8gcHJldmVudCBpbmNvcnJlY3QgIm9wdGltaXphdGlvbnMiLiAgSWRlYWxseSwNCiAg ICB0aGUgZHJhZnQgd291bGQgc3BlY2lmeSBzb21ldGhpbmcgbGlrZSBNVVNUIE5PVCBvciBTSE9V TEQgTk9UIHdpdGggZXhwbGFuYXRpb24NCiAgICAtIGlmIHRoYXQgaXMgdGhlIGNhc2UuDQoNCjxS Rz4gR01QTFMgc2lnbmFsaW5nIGhhcyBtYXN0ZXIvc2xhdmUgbW9kZWwuIFNvIEZvcndhcmQgZGly ZWN0aW9uIGlzIGFsd2F5cyBhIG1hc3RlciBhbmQgcmV2ZXJzZSBkaXJlY3Rpb24gaXMgc2xhdmUs IHRoaXMgaXMgdG8gYXZvaWQgb3NjaWxsYXRpb25zIHdoZXJlIHR3byBzaWRlcyBzdGFydHMgbWFr aW5nIGluZGVwZW5kZW50IGRlY2lzaW9ucy4NCiAgICANCiAgICAxMSkgU2VjIDcuMTogVGhlIGRl c2NyaXB0aW9uIGZvciB0aGUgQllQQVNTX0FTU0lHTk1FTlQgY29tcGxldGVseSBmYWlscyB0byBi ZQ0KICAgIGNsZWFyIGFzIHRvIHdoZXRoZXIgdGhlIGNvbnRlbnRzIGFyZSBmb3IgdGhlIGJ5cGFz cyB0dW5uZWwgdXNlZCBieSB0aGUgbm9kZQ0KICAgIGluc2VydGluZyBpdCBpbnRvIHRoZSBSUk8g b3Igd2hldGhlciB0aGUgY29udGVudHMgYXJlIGEgZGlyZWN0aW9uIGZvciB0aGUgbm9kZQ0KICAg IHRoYXQgcmVjZWl2ZXMgaXQgLSBiYXNlZCBvbiB0aGUgTm9kZSBJRCB0aGF0IGlzIGluY2x1ZGVk Lg0KICAgIA0KDQo8Ukc+IE5vZGUgaW5zZXJ0cyB0aGUgRkVDIG9mIHRoZSBieXBhc3MgdHVubmVs IGl0IGFzc2lnbnMgbG9jYWxseSB3aGljaCBpcyB0aGVuIHVzZWQgYnkgdGhlIE1QIGZvciBsb29r dXAuDQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIENPTU1FTlQ6DQogICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KICAgIA0KICAgIGEpIFNlYyA1LjIuMi4xOiBUaGUgYXBwcm9hY2ggc3VnZ2VzdGVkIGhl cmUgc2VlbXMgZmFpcmx5IGludGVuc2l2ZSBmcm9tIGENCiAgICBmb3J3YXJkaW5nIHBsYW5lIHBl cnNwZWN0aXZlLiAgSXQgd291bGQgYmUgdmVyeSBoZWxwZnVsIHRvIGluZGljYXRlIHRoZSByYW5n ZQ0KICAgIG9mIGV4cGVjdGVkL2Rlc2lyZWQgdGltZSBmb3IgdGhlIGZhaWwtb3Zlci4NCiAgICAN CjxSRz4gVGhpcyBpcyBzYW1lIGFzIGNvbnRyb2wtcGxhbmUgZXhjZXB0IHRoZSBGUlIgb24gTVAg c2lkZSBpcyBkZXRlY3RlZCBieSB0aGUgZGF0YS1wbGFuZS4NCg0KICAgIGIpIFNlYyA1LjI6ICBU aGlzIHNlY3Rpb24gaXMgYWJvdXQgbm9kZSBmYWlsdXJlcyAtIGJ1dCB3aGlsZSB0aGUgYnlwYXNz IHR1bm5lbHMNCiAgICBhcmUgbm9kZS1wcm90ZWN0aW5nLCB0aGUgZmFpbHVyZXMgZGlzY3Vzc2Vk IGFyZSBvbmx5IGxpbmsuICBBIGJyaWVmIGV4YW1wbGUNCiAgICB0aGF0IGRlc2NyaWJlcyB0aGUg ZXhwZWN0ZWQgc2lnbmFsaW5nIGZvciBhbiBhY3R1YWwgbm9kZSBmYWlsdXJlIHdvdWxkIGJlDQog ICAgaGVscGZ1bC4NCg0KPFJHPiBUaGVyZSBzaG91bGQgYmUgbm8gZGlmZmVyZW5jZSBpbiBwcm9j ZXNzaW5nIGlmIGxpbmsgb3Igbm9kZSBmYWlscywgYXMgbG9uZyBhcyBieXBhc3MgdHVubmVsIGlz IG5leHQtbmV4dC1ob3AuDQoNClRoYW5rcywNClJha2VzaA0KDQogICAgDQogICAgDQogICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBUZWFzIG1h aWxpbmcgbGlzdA0KICAgIFRlYXNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RlYXMNCiAgICANCg0K From nobody Wed Aug 2 15:54:28 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9151318A2; Wed, 2 Aug 2017 15:54:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-teas-gmpls-scsi@ietf.org, Vishnu Beeram , teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150171446174.5764.9578371193226819669.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 15:54:21 -0700 Archived-At: Subject: [Teas] Ben Campbell's No Objection on draft-ietf-teas-gmpls-scsi-03: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 22:54:22 -0000 Ben Campbell has entered the following ballot position for draft-ietf-teas-gmpls-scsi-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-scsi/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 6, paragraph 2: I think the draft needs to specify where IANA will put the registry, not leave it up to their discretion. From nobody Wed Aug 2 16:12:01 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E8D131C89; Wed, 2 Aug 2017 16:11:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-teas-gmpls-scsi@ietf.org, Vishnu Beeram , teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150171551836.5679.14360895881912372876.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 16:11:58 -0700 Archived-At: Subject: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-gmpls-scsi-03: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 23:11:58 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-teas-gmpls-scsi-03: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-scsi/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I do have a concern about error handling that should be pretty simple to fix. * Section 3 The document needs to specify the error handling on the receiver when the SCSI-TLV length is not a multiple of 4 octets. Are the following SCSI-TLVs processed or is everything ignored? Is there an error message sent? From nobody Wed Aug 2 16:12:13 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DDA131C89; Wed, 2 Aug 2017 16:11:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-teas-gmpls-scsi@ietf.org, Vishnu Beeram , teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150171551908.5787.8362563220697320399.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 16:11:59 -0700 Archived-At: Subject: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-gmpls-scsi-03: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 23:11:59 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-teas-gmpls-scsi-03: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-scsi/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I do have a concern about error handling that should be pretty simple to fix. * Section 3 The document needs to specify the error handling on the receiver when the SCSI-TLV length is not a multiple of 4 octets. Are the following SCSI-TLVs processed or is everything ignored? Is there an error message sent? From nobody Wed Aug 2 23:53:39 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05777126557; Wed, 2 Aug 2017 23:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-V-FGSDQ_Ct; Wed, 2 Aug 2017 23:53:28 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECA113146E; Wed, 2 Aug 2017 23:53:26 -0700 (PDT) X-AuditID: c1b4fb3a-bea2a9c000001b2f-ef-5982c8644beb Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4E.D6.06959.468C2895; Thu, 3 Aug 2017 08:53:24 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 3 Aug 2017 08:53:23 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V3rQotVvqXWhNXq6/geBQeZNFuhFwrkXyEU0ZUgRikU=; b=W8ioevuLkdBtK3uPV1Do+tjaQzLQSDd9gfWs9SAk6MxQzmN2va1UjwWGOGFPTSOIZM61cGmgPuKpUZbT2NmR3fWuUT4aXZTNsGgqxri2Du6EsMRBfWjsyF+VOa+MRrffVBrcZ6efqaIsKJh3+sW/rIunpjY7X+3wUW9CGSgcGI8= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0706.eurprd07.prod.outlook.com (10.160.56.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Thu, 3 Aug 2017 06:53:21 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::8512:cee5:a76e:ebf7]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::8512:cee5:a76e:ebf7%13]) with mapi id 15.01.1304.025; Thu, 3 Aug 2017 06:53:21 +0000 From: Daniele Ceccarelli To: Ben Campbell , The IESG CC: "draft-ietf-teas-gmpls-scsi@ietf.org" , Vishnu Beeram , "teas-chairs@ietf.org" , "vbeeram@juniper.net" , "teas@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-teas-gmpls-scsi-03: (with COMMENT) Thread-Index: AQHTC+JWBczWRIdLp0OyozI4EHFsSKJyMdPQ Date: Thu, 3 Aug 2017 06:53:21 +0000 Message-ID: References: <150171446174.5764.9578371193226819669.idtracker@ietfa.amsl.com> In-Reply-To: <150171446174.5764.9578371193226819669.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [93.40.1.108] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0706; 7:7DvN125pHdGauN0A/OvKB+G2LVsKPLlmcUE0sSXANxE9AyNZD557f5m+l9JRLoURnWP6G90KomkU5ZuCEqG8V1FWbEPnd+7hniUIpya98ma2mxCwiYJYZa6uEmeSa3BJQqhTf05LmxBnCw51ZGFdXA+90ozRwMROVjjk2DwZWR4doI3SqmbqxhFzKJFjsc6tthNaLLovEF9D56NfUu7/IdpR0fr1QLEshqnjfX268mAX+Kx5rljV3SAJtO6cTL6n5XAyVeanAtkX6eevEn/SY8wy0N1Z0yYkjX1GWbABSaJVViepDFI+sI4qnimiIstVi19I6wN055N7KPRZ38Oc9XI+gv9tz5hORTzPJqVrYqvYkW/g6MOGlMWUJNtaPqFUvd89zCQ+XQw0pZ0DhNHTtJu+nYdflmQegXUlgbGrDvqwE9oa4roSqiuP+ieXUmWdk1wPFmuK37AU7sFxbVKFJbX8lC5MgHekjqiWXVwYoKBIjwZUGCdJZOn+tGmcoeBJi8H8IFoFgBN6QFnw1A6v6DrgxgobsiQCVc1qskjq4MW3D7G89AfuFtfWT8O7mC7s1ikwQiBS0Qtf/s0ZdF5bnnhgbl0j9WkRNglb4Pm1wNEF8dsK8wrSiWm++fW+LJ1NJCxKGfNg/HG+kKAZxZYt+fU1P8nvxBTPozba2tib1XzH+a1I74CPCoPTW15TigQBtAVvt5LNRoZ7wpwDCRsYpwjXXLlLvx6BcZhtBX+X1QsTi17C67sc/Qb8CV8IBJJJdPl1kTlddhdD31gjVgAF3B60eXDi56J2Wlym5RSwBqY= x-ms-office365-filtering-correlation-id: fbff3098-627c-4a09-acf7-08d4da3c546a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0706; x-ms-traffictypediagnostic: AM2PR07MB0706: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(1591387915157); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0706; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0706; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(199003)(13464003)(189002)(51914003)(3846002)(50986999)(7696004)(2900100001)(86362001)(106356001)(105586002)(102836003)(6116002)(97736004)(230783001)(74316002)(81156014)(53546010)(8936002)(76176999)(81166006)(966005)(5660300001)(189998001)(38730400002)(101416001)(6246003)(54356999)(25786009)(66066001)(14454004)(54906002)(99286003)(4326008)(8666007)(9686003)(55016002)(6306002)(53936002)(33656002)(6436002)(8676002)(305945005)(2950100002)(3660700001)(68736007)(229853002)(6506006)(478600001)(2906002)(3280700002)(7736002)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0706; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 06:53:21.4002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0706 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SXUhTYRjHeXfOzjkbDY7L5ZNp1rAgSS3xYpiE3VmoeRNpajbbaZrfO9Pa 8kKmVn5ksyTcVm7oRDTTCL8VYdPKsnKIlS2C1KH5dVEgalq0eRS6+z3P7//yvs/DS2FiM9+X yshRM6oceZaUEOKGhB5JsGJUl3jiz0ikzFw+RsruVy0TsrqtGkyme9LPk5Wt9+IyS5sBiyKi rdYNXvRn3Ucy2tjnwuOxS8JIBZOVUcioQk9fEaZ/GNKRea3im1UDDqIYLXtVIAEFdDi0u95j FUhIiekRBMPvxhFXvEYwberieVI4fQ8DS/tBTjziwbreSXLFDIL6pTZ3iqIIOgJc9hjPAW86 EpptC4Qng9FrCFp+rZAesZdOgrr5GZILJUOfpXaHw6Bh6g7J3RYI1i923MMid6ZmqYXwsJiO gfbJMszDAjoWSkYntxnR/qAfaEAexmgfcLrMPG42GqyD4xjHEliY/cvn8mnQUda7kwmAb02P +Rz7w4S5cnt8oL8TsGjpQJyIhbm3u2KGB87FAZwTQbA6YCI4ToKSrec7/UzoflWHcQfsfOgY 1JOc8IOaH3qcE0YC2u0GUo+OG/97utG9Sow+Bh39oVz7MNRWTpPG7W14wRuDC7cgvBVJWIZl s5VhYSGMKuMqy+bmhOQw6hfI/W1snZsRvcg2f8aOaApJ94iq23SJYr68kNVk2xFQmNRbVG53 t0QKuUbLqHJTVQVZDGtHByhc6iOKGnIkiGmlXM1kMkweo9q1PErgW4xKb/82XROFBNZPF2jC HY2al+amlaViU7d26nyyoyFrU7ImnNunvajDBfn5XUdKe1cniq4frb41tzHcIEgMTmp+6DKe 49XGf3r2gH9Dfejr08sp2YoL/kVx2s40pyDu1HpA6v5GMsTRKk3pP/vT5jeWKRPO9ihtEz1s QW61Ersrxdl0+ckgTMXK/wH3rlnFMgMAAA== Archived-At: Subject: Re: [Teas] Ben Campbell's No Objection on draft-ietf-teas-gmpls-scsi-03: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 06:53:30 -0000 SGkgQmVuLA0KDQp0aGFua3MgZm9yIHRoZSByZXZpZXcuIElBTkEgYWxyZWFkeSB0b29rIGl0cyBk ZWNpc2lvbiBhcyBwYXJ0IG9mIGl0cyByZXZpZXc6IA0KDQoiQSBuZXcgcmVnaXN0cnkgaXMgdG8g YmUgY3JlYXRlZCBjYWxsZWQgdGhlICJHZW5lcmFsaXplZCBTQ1NJIChTd2l0Y2hpbmcgQ2FwYWJp bGl0eSBTcGVjaWZpYyBJbmZvcm1hdGlvbikgVExWcyBUeXBlcyIgcmVnaXN0cnkuIFRoaXMgbmV3 IHJlZ2lzdHJ5IHdpbGwgYmUgY3JlYXRlZCBvbiB0aGUgR2VuZXJhbGl6ZWQgTXVsdGktUHJvdG9j b2wgTGFiZWwgU3dpdGNoaW5nIChHTVBMUykgU2lnbmFsaW5nIFBhcmFtZXRlcnMgcmVnaXN0cnkg cGFnZSBsb2NhdGVkIGF0Og0KDQpodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9nbXBs cy1zaWctcGFyYW1ldGVycy8iDQoNCkkgdGhpbmsgd2UgY2FuIHVwZGF0ZSB0aGUgdGV4dCBhY2Nv cmRpbmdseS4NClRoYW5rcyBhIGxvdA0KRGFuaWVsZSAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1bS5jb21dIA0KU2Vu dDogZ2lvdmVkw6wgMyBhZ29zdG8gMjAxNyAwMDo1NA0KVG86IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPg0KQ2M6IGRyYWZ0LWlldGYtdGVhcy1nbXBscy1zY3NpQGlldGYub3JnOyBWaXNobnUgQmVl cmFtIDx2YmVlcmFtQGp1bmlwZXIubmV0PjsgdGVhcy1jaGFpcnNAaWV0Zi5vcmc7IHZiZWVyYW1A anVuaXBlci5uZXQ7IHRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IEJlbiBDYW1wYmVsbCdzIE5vIE9i amVjdGlvbiBvbiBkcmFmdC1pZXRmLXRlYXMtZ21wbHMtc2NzaS0wMzogKHdpdGggQ09NTUVOVCkN Cg0KQmVuIENhbXBiZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcg0KZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLXNjc2ktMDM6IE5vIE9iamVjdGlvbg0KDQpXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMu IChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4p DQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50 L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBE SVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdp dGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRlYXMtZ21wbHMtc2NzaS8NCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0gNiwgcGFyYWdyYXBo IDI6IEkgdGhpbmsgdGhlIGRyYWZ0IG5lZWRzIHRvIHNwZWNpZnkgd2hlcmUgSUFOQSB3aWxsIHB1 dCB0aGUgcmVnaXN0cnksIG5vdCBsZWF2ZSBpdCB1cCB0byB0aGVpciBkaXNjcmV0aW9uLg0KDQoN Cg== From nobody Thu Aug 3 01:08:21 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C0F126CB6; Thu, 3 Aug 2017 01:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7dGcDeAyTbF; Thu, 3 Aug 2017 01:08:17 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20D9132320; Thu, 3 Aug 2017 01:08:16 -0700 (PDT) X-AuditID: c1b4fb30-aeec49c000001664-53-5982d9eef94d Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.DE.05732.EE9D2895; Thu, 3 Aug 2017 10:08:14 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 3 Aug 2017 10:08:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cLebBL3aqwt7JmOO+454AFbwHFFbH8rCR7fT+tya1cw=; b=TdF/582yCrtzwDI1Ypk4GaHg3rD+pknhbYQyfBKuVrh/eVh3brQII9J7UVIYBtbCNf6yf5j0HPC9x4C21+QDpZzylkhT1qftSQ50JSBuvxyxJ0XgZf2xQfYoKj5H0z8oFF3No1r6LSTk2D/+0Ri4u+MwnkmrnzRQeV7dZZrpBug= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB1044.eurprd07.prod.outlook.com (10.162.38.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Thu, 3 Aug 2017 08:08:06 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::8512:cee5:a76e:ebf7]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::8512:cee5:a76e:ebf7%13]) with mapi id 15.01.1304.025; Thu, 3 Aug 2017 08:08:06 +0000 From: Daniele Ceccarelli To: Suresh Krishnan , The IESG CC: "draft-ietf-teas-gmpls-scsi@ietf.org" , Vishnu Beeram , "teas-chairs@ietf.org" , "vbeeram@juniper.net" , "teas@ietf.org" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-teas-gmpls-scsi-03: (with DISCUSS) Thread-Index: AQHTC+TcZ/ESc50AYUuBO+pBnvaX3qJyRPUQ Date: Thu, 3 Aug 2017 08:08:06 +0000 Message-ID: References: <150171551836.5679.14360895881912372876.idtracker@ietfa.amsl.com> In-Reply-To: <150171551836.5679.14360895881912372876.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [93.40.1.108] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB1044; 6:6uJmiKwi8C0LJV+sp51BmdFC5pCaO+PVpqPMNo8K6JwD2YNx4DeQ+CIMHjuXfanb+ANZKmGo/lZk+WEntdJvTCuEb+V14ZbyRH9ZcOI6M63MNNpAGIVK0UbqKYXdWA2TolHk8ZDV5DPuzeBFVN4HFR57BAs+8D5o1UJtRVHYXZfjjWCdAz2OG8KQj1J5sOGbaKyRwDd20dS+eWkDwfakTBhMNcCBHGXkIqkfJla+i4hnpvyy44ekRMcWDktzapY1RokX8Ksg4P0IU0VJZA6DZ0o/QTpLoKHQsAtqr+Tf7Kmwjspr5GKL2w7x2v48QAMzS1S9M8N6lMOKNcMPXzz6EA==; 5:alQYUl4/12E7A15Md9fxNY+UwxMmRFlc23RybO9uyNFeEbojGAtC12MEfcgWfQw4RZFF0dsW+Q7wyegReeraMD4Q+SNCLrCoCJpMqpHrY/kQJucfTuAqE2c3lNplnJsK2gGWv2PKE8DE+fPpymJSDQ==; 24:KCAuW/sGLkqYWQQhFUhiDbrYzGG5oFaX0POBjoGz/XaFWCea3fAWSnN4xMWOLqgWnc4/UMPC+vMy+QlKN9KfeL0jGCSY/1Mz+jcL0nCx/RA=; 7:3uU2c0PHaj2npq383yoMbxSwFbAqselFJcAZPwB0lAGKRSKtHfyD6j4iPWUnR5R/Z2bg++QoqKn1tvLlmXHqlVpF5ENkZO+vZfSGPAux3d2D9ZvD30SpxMMeLJ6yZgK0jedei4kgaMI5qGYHJbsBumUdJGzRvRfWLELDlXSUbqNnqTMYpGDExRFptSjBhcC36l4pp+b9LLBiwOYGJU/gUT+xqaSE/MxICKsh7FHSw2A= x-ms-office365-filtering-correlation-id: fe6183db-dfb4-4100-d0cf-08d4da46c5d3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB1044; x-ms-traffictypediagnostic: AM2PR07MB1044: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB1044; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB1044; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39840400002)(39410400002)(39450400003)(39400400002)(39850400002)(189002)(13464003)(199003)(4326008)(25786009)(8676002)(74316002)(478600001)(5250100002)(101416001)(54356999)(230783001)(68736007)(5660300001)(81156014)(3846002)(81166006)(6116002)(106356001)(105586002)(6506006)(102836003)(86362001)(3280700002)(966005)(7736002)(8666007)(229853002)(66066001)(8936002)(7696004)(305945005)(33656002)(6436002)(54906002)(3660700001)(55016002)(6306002)(99286003)(76176999)(50986999)(38730400002)(53546010)(2906002)(14454004)(53936002)(2950100002)(189998001)(9686003)(39060400002)(2900100001)(97736004)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB1044; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 08:08:06.5766 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB1044 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGObt3d3fm6DQ1X0z7GEFopWYRI0rSMC1c9Al+RDn1okudsqnl /klWSrhMhTId2Swm+NHyq49tSdEY2EgzitIs03Riq6YkYdpE23YN+u/3vs9znve8h0MTQh03 iJbJCxmFXJoronzI+qTHx7ZPf1AnR/Z8ihRXXf1BiesWawixtaOfK1Y3mDnisnkjKW68V0/s pxJM2hFegl6/wEkYVL/jHSVSfPZmMrmyYkYREZ3mk1020EYUWAMuVDhf8UrRon8F4tOAd0GT 6QVVgXxoIbYimPjZSbJFL4IrM8vegsSVBJheThGscoMDzl+1iC3GETR8r3cH0DSF94DdkujJ 9ceHoNbV7D1A4N8IWmadPI/gh5NhdKydYk0pYDNpeCxHQc98M8fDJN4Mj6waLwvwaSh13UEe FmIJ2OfU3j4fH4Fneq2XEQ6B6id3vR4CB8KwXcdhl8Og7xkgWA4Ax8QSl/WnQ3uZccWzAUaa bnFZDoE3Oo13McDlPBifaVwRJNA9PE2wwjgHPlsneJ6NAYdBb9N61pMIfx5OrgzLgRr9wkqQ hQs3u6pIVgiGmq/VJCu0UmCoM1DVaJv2v5tr3bkEDoV2cwTb3gTXNV94Wu9jrAFbvZ1sRGQr ClAyyvS8rKiocEYhy1Aq8+XhcqawC7m/zfMHrkgjckzFWBCmkchXYO9XJwu50mJlSZ4FAU2I /AXke3dLkCktUTGK/LOKolxGaUHraFIUKIh5+jpJiLOkhUwOwxQwin8qh+YHlaJ0+caIxFhN UVt3qorkx5y5nLuUd/yALTZ1eSm0hS/ulOwzDH281HH7/Co8Onhq64mog+MhqsOO1WW9Nsnk EFyU9hlzSnZnbAmLX8ucNFaq0m5Jkiq1+qFZR4rOEP3WIasL6nOp5r9V3Rc4/efidl7zM5Ph 5V3xY/w4rvmcb7CIVGZLd4QRCqX0L06qk98yAwAA Archived-At: Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-gmpls-scsi-03: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:08:20 -0000 SGkgU3VyZXNoLA0KDQp0aGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KDQpUaGUgR01QTFMgU0NTSSBp cyBhIHN1Yi1UTFYgb2YgdGhlIElTQ0QgKGludGVyZmFjZSBzd2l0Y2hpbmcgY2FwYWJpbGl0eSBk ZXNjcmlwdG9yLVJGQzQyMDMpLCB3aGljaCBpbiB0dXJuIGlzIGEgc3ViIFRMViBvZiB0aGUgTGlu ayBUTFYgKFJGQzM2MzApIC4uLiB5ZXMgd2UgbGlrZSBuZXN0aW5nIGluIEdNUExTIPCfmIoNCg0K UkZDIDM2MzAgKHNlY3Rpb24gMi40LjIuKSBzYXlzOiAiIFVucmVjb2duaXplZCBzdWItVExWcyBh cmUgaWdub3JlZC4iDQoNCkl0IHNlZW1zIG9idmlvdXMgYnV0IGl0IHRvb2sgbWUgYSB3aGlsZSB0 byBnbyBiYWNrIHRvIHRoZSByb290IG9mIHRoZSBwcm9ibGVtLCBoZW5jZSBmZXcgd29yZHMgIHdv dWxkIGhlbHAgdGhlIHJlYWRlci4gSG93IGFib3V0IHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMg b2Y6DQoNCiJNYWxmb3JtZWQgcGFja2V0cyBzaG91bGQgYmUgdHJlYXRlZCBhY2NvcmRpbmdseSB3 aXRoIGVycm9yIGhhbmRsaW5nIHByb2NlZHVyZXMgZGVmaW5lZCBpbiBSRkMzNjMwLiIgPw0KDQpD aGVlcnMNCkRhbmllbGUgIA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBT dXJlc2ggS3Jpc2huYW4gW21haWx0bzpzdXJlc2gua3Jpc2huYW5AZ21haWwuY29tXSANClNlbnQ6 IGdpb3ZlZMOsIDMgYWdvc3RvIDIwMTcgMDE6MTINClRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y Zz4NCkNjOiBkcmFmdC1pZXRmLXRlYXMtZ21wbHMtc2NzaUBpZXRmLm9yZzsgVmlzaG51IEJlZXJh bSA8dmJlZXJhbUBqdW5pcGVyLm5ldD47IHRlYXMtY2hhaXJzQGlldGYub3JnOyB2YmVlcmFtQGp1 bmlwZXIubmV0OyB0ZWFzQGlldGYub3JnDQpTdWJqZWN0OiBTdXJlc2ggS3Jpc2huYW4ncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtdGVhcy1nbXBscy1zY3NpLTAzOiAod2l0aCBESVNDVVNTKQ0KDQpT dXJlc2ggS3Jpc2huYW4gaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yDQpkcmFmdC1pZXRmLXRlYXMtZ21wbHMtc2NzaS0wMzogRGlzY3Vzcw0KDQpXaGVuIHJlc3Bv bmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBh bGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVs IGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0K UGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1 c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNT IGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3Ro ZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRlYXMtZ21wbHMtc2NzaS8NCg0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCkRJU0NVU1M6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkkgZG8gaGF2ZSBhIGNvbmNlcm4g YWJvdXQgZXJyb3IgaGFuZGxpbmcgdGhhdCBzaG91bGQgYmUgcHJldHR5IHNpbXBsZSB0byBmaXgu DQoNCiogU2VjdGlvbiAzDQoNClRoZSBkb2N1bWVudCBuZWVkcyB0byBzcGVjaWZ5IHRoZSBlcnJv ciBoYW5kbGluZyBvbiB0aGUgcmVjZWl2ZXIgd2hlbiB0aGUgU0NTSS1UTFYgbGVuZ3RoIGlzIG5v dCBhIG11bHRpcGxlIG9mIDQgb2N0ZXRzLiBBcmUgdGhlIGZvbGxvd2luZyBTQ1NJLVRMVnMgcHJv Y2Vzc2VkIG9yIGlzIGV2ZXJ5dGhpbmcgaWdub3JlZD8gSXMgdGhlcmUgYW4gZXJyb3IgbWVzc2Fn ZSBzZW50Pw0KDQoNCg0KDQo= From nobody Thu Aug 3 01:21:57 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F4212711E; Thu, 3 Aug 2017 01:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyG40jMk5E7e; Thu, 3 Aug 2017 01:21:48 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E00120724; Thu, 3 Aug 2017 01:21:47 -0700 (PDT) X-AuditID: c1b4fb30-71bff70000001664-84-5982dd193867 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FE.C1.05732.91DD2895; Thu, 3 Aug 2017 10:21:45 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 3 Aug 2017 10:21:44 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YwwkM0R1b30Pdyr9lL+5bgB8ICO0P3Th3pVj/IXrJmE=; b=PaC0YRQoNjRoPccYI0KSJ7oSGe1rrYJKnRXeini8UBOBOPRwEZ+QSgOiJMYJ86Pp3uIq2P2douisUZsRU/+jP5bhBua7mKwaGXsW1gd6/2r8ZSV+4pZuBlNU2aB6zzTPeF/6bTdyg0V36T0ar99yubvhcKHk4+NA6bxI9Ejq0ks= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0657.eurprd07.prod.outlook.com (10.160.55.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Thu, 3 Aug 2017 08:21:43 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::8512:cee5:a76e:ebf7]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::8512:cee5:a76e:ebf7%13]) with mapi id 15.01.1304.025; Thu, 3 Aug 2017 08:21:43 +0000 From: Daniele Ceccarelli To: Daniele Ceccarelli , Suresh Krishnan , The IESG CC: "draft-ietf-teas-gmpls-scsi@ietf.org" , Vishnu Beeram , "teas-chairs@ietf.org" , "vbeeram@juniper.net" , "teas@ietf.org" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-teas-gmpls-scsi-03: (with DISCUSS) Thread-Index: AQHTC+TcZ/ESc50AYUuBO+pBnvaX3qJyRPUQgAAGFpA= Date: Thu, 3 Aug 2017 08:21:43 +0000 Message-ID: References: <150171551836.5679.14360895881912372876.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [93.40.1.108] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0657; 6:0KgSVHXDdd5x2rv4sm961drjF/MeRNLoDxKg/KDHvpKxNiid+w73KxhVTWMwwtBsPSwc3aoSC8nKdsMS/Iq6Qn64xIfAMvRQcYScLwS6gzpz9IQHq3Vphx/jE/fBz6RFLXgStXf/FO9cDv6/iz2Dy5uaarRIypsseWxFEiLhOi3FgRvRfZm3Gg3SBUlr5qV2N+nog5aggRTE6HQzFEHje71PBzLE9+0f9v5Rs+ySAlm7YxwyxFpB21HRh8bVdxIHTNwU+mPP/jbFN1TvBL26yQyaBvYXnVI1uC9OjuPwtFnE/thTaBGia9QxmC1DgTwTkrVmnQfl3KD1MO25F7uVJg==; 5:F4FUtHbqUVSjKcMtURIBlUJpav9WyfV+18DzMpMnUCz/G51twUpZO9lhjsX9mVYYr2H7P56vDqbFNK4+h6rXCzWUV1bYXTomjxfZW8mAQVuwvV3rkDwmrNL5UKz3mXZDM2ILRYclPCNKKqC4eW5tCA==; 24:l0wGwZtdwW4n9AmEqLJqu4NDx4g2QKISIMVF1Qrp/bKRQweEls3ldTd+6JP8mkObCGvtc2YUFKZtxKALg65GEWD6VE9ROzCF3hPk4t5mRVs=; 7:veK320Yw+xcrRTS7+RjBvYoREYtMu4kOeuZ/OSYxVAHoZJ4pTascxAJELwkfqnh58c0RcmQ4SmpyA4flWvoneXVyOYA0K405Ex2wbDS9HCYvCeWazApqNRjaXfyGWN4EaJaqhEzhKzJZbJ0XjnznOThUE6kN0xt2lTvm6gKayOFK+q/FEskL/cOMhZREhSlqHj91pXVbcI/sfaqMvdio3FYplIF5Tb87f+XAN3wTuX4= x-ms-office365-filtering-correlation-id: 35b9c011-873a-4307-bad0-08d4da48aca6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0657; x-ms-traffictypediagnostic: AM2PR07MB0657: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(138986009662008); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0657; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0657; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39410400002)(39400400002)(39450400003)(39840400002)(189002)(199003)(13464003)(8676002)(54906002)(55016002)(6436002)(2950100002)(229853002)(2900100001)(99286003)(5660300001)(7696004)(8666007)(74316002)(2906002)(86362001)(38730400002)(6506006)(101416001)(4326008)(54356999)(76176999)(25786009)(39060400002)(478600001)(50986999)(305945005)(106356001)(105586002)(6306002)(7736002)(9686003)(8936002)(2940100002)(966005)(3660700001)(97736004)(189998001)(66066001)(53546010)(81166006)(81156014)(3280700002)(14454004)(230783001)(53936002)(102836003)(6116002)(3846002)(5250100002)(33656002)(68736007)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0657; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 08:21:43.3315 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0657 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUiTURiGOzvvtnfS5LQ0n/zIGhYkNXX5Y0gfSn8UCupHoGbUzBcn86vN LP0RNtskbTlBQ4fiSssPFCXDbwYOmWwpRbGkpWZzOU1DSirLkLa9Cv277vvm5jnPw6Gx6DE3 lM7JL2JU+fJcMS+AakgdiDq+f1aTFmvdPCirfrDKk9X/rcGy8d4prkzTNMyRaTcGKZmpqwEn 8pKHjLP85NbW35zkaY2DfwGnB5zMYnJzihlVzOlrAYq3NUGFzojbrqFyXhnaCK9EAhpIPAzf N3AqUQAtIuMIvtxz8FkxgeBznRX7BEX0GNy2neQRB1ZafmBWuBCsj495BU3zSAK4Led8fhC5 i2Brrd3fwOQXgo7vX/m+iXtJGnyc7+H5OIikg22ois9yArys2fD7FImCioU+7GMhyQBz9SZi p5kQGJwfKF8gIFfgZ983PyMSAYaRJ8jHmISA093MYdcj0Dr6CrMcDMsLW1yWI2H2aeM2R8Cb 5ir/ACA6PszMtPHZ4DxsDE5z2cDFgbpFy3YjGnrfl29zBpg0WxTLSujS12O2YOGCZ2mOxwbh ULNkoNiggwfl83Z/W0QYaOvWIgM6Zvzv6UbvMTE5Cj3DMax9CGqrPvGN/nPsAVuDmzIhqhMF qxl1Zl62VCphVDnX1eqCfEk+U/QceT/O2IvN2EG07EmyIEIj8W6he0qTJuLKi9UleRYENBYH Cc1OryXMkpeUMqqCq6qbuYzagsJoShwiTDK/ThWRbHkRo2SYQka1k3JoQWgZShksaBlQ1K5O aktHDgtOmKwXwxrD7YtSvEDF661NA55bMrvCXiDdMisN+0aTbzjirWfzns3pJyp0uuxIXY9t LI2yRSCHJ/NUw8qd9eDFy8sWSSH+k9jISDrl2pRLgag9cLL73RnL7Nqwsv/Irpa40rCHkwJX ZMyAoflAv5hSK+Rx0Villv8DIXuGSjQDAAA= Archived-At: Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-gmpls-scsi-03: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:21:50 -0000 SGkgU3VyZXNoLA0KDQpSZS1yZWFkaW5nIHRoZSBkcmFmdCBpdCBzZWVtcyBpdCdzIGFscmVhZHkg Y292ZXJlZCBieSB0aGlzIHN0YXRlbWVudDoNCg0KIlNpemUgYW5kIG90aGVyIGZvcm1hdHRpbmcg cmVzdHJpY3Rpb25zIG1heSBiZSBpbXBvc2VkIGJ5IHRoZSByb3V0aW5nDQogICAgICAgIHByb3Rv Y29sIElTQ0QgZmllbGQsIHJlZmVyIHRvIDx4cmVmIHRhcmdldD0iUkZDNDIwMyIvPiBhbmQgPHhy ZWYNCiAgICAgICAgdGFyZ2V0PSJSRkM1MzA3Ii8+LiINCg0KV291bGQgeW91IGxpa2UgaXQgdG8g YmUgbWFkZSBtb3JlIGV4cGxpY2l0Pw0KDQpDaGVlcnMNCkRhbmllbGUgIA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpIFttYWlsdG86ZGFuaWVs ZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbV0gDQpTZW50OiBnaW92ZWTDrCAzIGFnb3N0byAyMDE3 IDEwOjA4DQpUbzogU3VyZXNoIEtyaXNobmFuIDxzdXJlc2gua3Jpc2huYW5AZ21haWwuY29tPjsg VGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLXNjc2lA aWV0Zi5vcmc7IFZpc2hudSBCZWVyYW0gPHZiZWVyYW1AanVuaXBlci5uZXQ+OyB0ZWFzLWNoYWly c0BpZXRmLm9yZzsgdmJlZXJhbUBqdW5pcGVyLm5ldDsgdGVhc0BpZXRmLm9yZw0KU3ViamVjdDog UkU6IFN1cmVzaCBLcmlzaG5hbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLXNj c2ktMDM6ICh3aXRoIERJU0NVU1MpDQoNCkhpIFN1cmVzaCwNCg0KdGhhbmtzIGZvciB5b3VyIHJl dmlldy4NCg0KVGhlIEdNUExTIFNDU0kgaXMgYSBzdWItVExWIG9mIHRoZSBJU0NEIChpbnRlcmZh Y2Ugc3dpdGNoaW5nIGNhcGFiaWxpdHkgZGVzY3JpcHRvci1SRkM0MjAzKSwgd2hpY2ggaW4gdHVy biBpcyBhIHN1YiBUTFYgb2YgdGhlIExpbmsgVExWIChSRkMzNjMwKSAuLi4geWVzIHdlIGxpa2Ug bmVzdGluZyBpbiBHTVBMUyDwn5iKDQoNClJGQyAzNjMwIChzZWN0aW9uIDIuNC4yLikgc2F5czog IiBVbnJlY29nbml6ZWQgc3ViLVRMVnMgYXJlIGlnbm9yZWQuIg0KDQpJdCBzZWVtcyBvYnZpb3Vz IGJ1dCBpdCB0b29rIG1lIGEgd2hpbGUgdG8gZ28gYmFjayB0byB0aGUgcm9vdCBvZiB0aGUgcHJv YmxlbSwgaGVuY2UgZmV3IHdvcmRzICB3b3VsZCBoZWxwIHRoZSByZWFkZXIuIEhvdyBhYm91dCBz b21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mOg0KDQoiTWFsZm9ybWVkIHBhY2tldHMgc2hvdWxk IGJlIHRyZWF0ZWQgYWNjb3JkaW5nbHkgd2l0aCBlcnJvciBoYW5kbGluZyBwcm9jZWR1cmVzIGRl ZmluZWQgaW4gUkZDMzYzMC4iID8NCg0KQ2hlZXJzDQpEYW5pZWxlICANCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3VyZXNoIEtyaXNobmFuIFttYWlsdG86c3VyZXNoLmty aXNobmFuQGdtYWlsLmNvbV0gDQpTZW50OiBnaW92ZWTDrCAzIGFnb3N0byAyMDE3IDAxOjEyDQpU bzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLXNj c2lAaWV0Zi5vcmc7IFZpc2hudSBCZWVyYW0gPHZiZWVyYW1AanVuaXBlci5uZXQ+OyB0ZWFzLWNo YWlyc0BpZXRmLm9yZzsgdmJlZXJhbUBqdW5pcGVyLm5ldDsgdGVhc0BpZXRmLm9yZw0KU3ViamVj dDogU3VyZXNoIEtyaXNobmFuJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRlYXMtZ21wbHMtc2Nz aS0wMzogKHdpdGggRElTQ1VTUykNCg0KU3VyZXNoIEtyaXNobmFuIGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLXNjc2kt MDM6IERpc2N1c3MNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBs aW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0 aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBw YXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGluZm9y bWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10ZWFz LWdtcGxzLXNjc2kvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpJIGRvIGhhdmUgYSBjb25jZXJuIGFib3V0IGVycm9yIGhhbmRsaW5nIHRoYXQgc2hvdWxk IGJlIHByZXR0eSBzaW1wbGUgdG8gZml4Lg0KDQoqIFNlY3Rpb24gMw0KDQpUaGUgZG9jdW1lbnQg bmVlZHMgdG8gc3BlY2lmeSB0aGUgZXJyb3IgaGFuZGxpbmcgb24gdGhlIHJlY2VpdmVyIHdoZW4g dGhlIFNDU0ktVExWIGxlbmd0aCBpcyBub3QgYSBtdWx0aXBsZSBvZiA0IG9jdGV0cy4gQXJlIHRo ZSBmb2xsb3dpbmcgU0NTSS1UTFZzIHByb2Nlc3NlZCBvciBpcyBldmVyeXRoaW5nIGlnbm9yZWQ/ IElzIHRoZXJlIGFuIGVycm9yIG1lc3NhZ2Ugc2VudD8NCg0KDQoNCg0K From nobody Thu Aug 3 07:05:54 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E23132018; Thu, 3 Aug 2017 07:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LZgcwWeWFLyB; Thu, 3 Aug 2017 07:05:46 -0700 (PDT) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (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 B4F94131FFB; Thu, 3 Aug 2017 07:05:44 -0700 (PDT) Received: by mail-yw0-x241.google.com with SMTP id t139so877461ywg.1; Thu, 03 Aug 2017 07:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=huwtT/xK7Mnvdy4TzpIkG5OF3xbJuANNii0MJ5G/7xw=; b=H1/beT0bX/LpaMt5OwtkUTHXo9u/Gp6af6pdvVPjCgSa9dNmRpYTQMVmBHsE0vbX/b YEp43A5hZvenLYCy1mtZsOt2mM4lTUrjtqF1aXsp/wDt4Dp9YA/HTJ/9EUUErux+pxp9 wxGi5Edr3bWsQOEVo/XYJ4C1b9stA10F51k3QH/2nJ337yyJwMNpZ5LfIpviD9B/Qg00 b4b7mlXD5Bisgm+1YxDIp0Rx0gZQLcIzOXkdRYR3zzHczKqWsi7kdkSixUQlfwW/QMyv bPiFByFjlgtHKm2NMTjCEsc+YVOjD0AVj2NK8uyK3/asU4LzozahhTb7grqf4eKUlnEY MHFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=huwtT/xK7Mnvdy4TzpIkG5OF3xbJuANNii0MJ5G/7xw=; b=bJzhpBymEBjSTriodV77KgfKnO6Gt5umhH/lnmFyXIx8px2K5hHXCvZ9hrNVVo1aqw dqkMmK2iIYCDaoccZWBFHPd3Z3xtxpyBD6Bg+fTFpD+Gw759kmi8uCeiiK26I1dY9yXz jFDdZqj42awFYOTYU4Glnhu3UD/tWwiUOfafzmRRZ3vN9XNNHQObmnEB1g+f3P6L/8QV xwHjVQQFvzpn+m1nhtm/6rP1LGn449ZshaAzSH+aS+AWqwXQn9eexT4wlCvGggqwJJcn ed/la939HRCdBovqcGsTzXyVuNFLFYbGVydufl3k5GcDx5uPYcV+8Oe2BmyITL0SNvE6 WLSw== X-Gm-Message-State: AIVw1103gXx7z6I49SqxeDj6kZK9oMsoNMG8jetVCD/R1a9fjuxnxN+e YKLFpR2yvm+DOw== X-Received: by 10.13.197.71 with SMTP id h68mr1377083ywd.46.1501769143696; Thu, 03 Aug 2017 07:05:43 -0700 (PDT) Received: from [10.0.0.5] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id p127sm13135001ywf.46.2017.08.03.07.05.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 07:05:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Suresh Krishnan In-Reply-To: Date: Thu, 3 Aug 2017 10:05:41 -0400 Cc: The IESG , "draft-ietf-teas-gmpls-scsi@ietf.org" , Vishnu Beeram , "teas-chairs@ietf.org" , "teas@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <04827492-DD41-4DBF-99B2-D0A0BF801CC2@gmail.com> References: <150171551836.5679.14360895881912372876.idtracker@ietfa.amsl.com> To: Daniele Ceccarelli X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-gmpls-scsi-03: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:05:47 -0000 Hi Daniele, > On Aug 3, 2017, at 4:21 AM, Daniele Ceccarelli = wrote: >=20 > Hi Suresh, >=20 > The GMPLS SCSI is a sub-TLV of the ISCD (interface switching = capability descriptor-RFC4203), which in turn is a sub TLV of the Link = TLV (RFC3630) ... yes we like nesting in GMPLS =F0=9F=98=8A >=20 > RFC 3630 (section 2.4.2.) says: " Unrecognized sub-TLVs are ignored." >=20 > It seems obvious but it took me a while to go back to the root of the = problem, hence few words would help the reader. How about something = along the lines of: >=20 > "Malformed packets should be treated accordingly with error handling = procedures defined in RFC3630.=E2=80=9D ? =E2=80=A6 >=20 > Re-reading the draft it seems it's already covered by this statement: >=20 > "Size and other formatting restrictions may be imposed by the routing > protocol ISCD field, refer to and = target=3D"RFC5307"/>." >=20 > Would you like it to be made more explicit? Yes. Please. I personally think ignoring a length error as an = unrecognized TLV and moving on is not preferable, but I am happy to step = aside if that decision is explicitly made. Regards Suresh From nobody Thu Aug 3 07:25:38 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD269132026; Thu, 3 Aug 2017 07:25:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150177033665.9682.16331556632242398651@ietfa.amsl.com> Date: Thu, 03 Aug 2017 07:25:36 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-11.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:25:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Updates to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs Authors : Mike Taillon Tarek Saad Rakesh Gandhi Zafar Ali Manav Bhatia Filename : draft-ietf-teas-gmpls-lsp-fastreroute-11.txt Pages : 23 Date : 2017-08-03 Abstract: This document updates the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC 4090 to support Packet Switched Capable (PSC) Generalized Multi- Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these updates enable the re-direction of bidirectional traffic onto bypass tunnels that ensure co-routedness of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in control-plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute-11 https://datatracker.ietf.org/doc/html/draft-ietf-teas-gmpls-lsp-fastreroute-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-gmpls-lsp-fastreroute-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 3 07:27:15 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 580F1132081; Thu, 3 Aug 2017 07:26:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150177041931.9686.4969124194474356333@ietfa.amsl.com> Date: Thu, 03 Aug 2017 07:26:59 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-10.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:26:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Extensions to RSVP-TE for LSP Ingress FRR Protection Authors : Huaimo Chen Raveendra Torvi Filename : draft-ietf-teas-rsvp-ingress-protection-10.txt Pages : 25 Date : 2017-08-03 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Label Switched Path (LSP), which is a Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection-10 https://datatracker.ietf.org/doc/html/draft-ietf-teas-rsvp-ingress-protection-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-ingress-protection-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 3 07:35:25 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 826F31323AD; Thu, 3 Aug 2017 07:35:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150177091748.9833.14170238165152972001@ietfa.amsl.com> Date: Thu, 03 Aug 2017 07:35:17 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-08.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:35:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Extensions to RSVP-TE for LSP Egress Local Protection Authors : Huaimo Chen Autumn Liu Tarek Saad Fengman Xu Lu Huang Ning So Filename : draft-ietf-teas-rsvp-egress-protection-08.txt Pages : 20 Date : 2017-08-03 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) Label Switched Path (LSP), which is a Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-rsvp-egress-protection-08 https://datatracker.ietf.org/doc/html/draft-ietf-teas-rsvp-egress-protection-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-egress-protection-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 3 07:40:34 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0AC1323CE; Thu, 3 Aug 2017 07:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCa3GeEyjIbE; Thu, 3 Aug 2017 07:40:31 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525291323C8; Thu, 3 Aug 2017 07:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3680; q=dns/txt; s=iport; t=1501771231; x=1502980831; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FUUSrqITpQiSUjlQSnZMKqHndV0cVN+npgG9S/GgxuE=; b=UwxrO/I8ne5fIB3WRI4jXmE+Xqr/zMoqYOVPm6p95/EgEnsRv5E3B9qe 1aij5VTi67b3UOZ5zFQMASRmmdFbeghv3uSBNQrz+LKIYUKLLL9zS/k5U QN7GI/njWk+Jm1eOwrnjklAxwEmXq8He2Pg3+hHkD0rLNhD4HATlTglty M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAACJNINZ/4cNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tZG0nB44IkAeYA4ISIQ2FGQIahCM/GAECAQEBAQEBAWsohRk?= =?us-ascii?q?CAQMBASEROgsQAgEIEggCJgICAiULFQIOAgQOBYovEK0XgiaLTwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2BC4IdggKBTIFiLIJ8gyaBTReCfDCCMQWffQKHUYxagg9?= =?us-ascii?q?ZhH+KYZYAAR84gQp3FR8qEgGHB3aIR4EPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,316,1498521600"; d="scan'208";a="278197453" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Aug 2017 14:40:30 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v73EeUKD025569 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2017 14:40:30 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Aug 2017 09:40:29 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Thu, 3 Aug 2017 09:40:29 -0500 From: "Rakesh Gandhi (rgandhi)" To: The IESG CC: "teas@ietf.org" , "teas-chairs@ietf.org" , "draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org" , "Rakesh Gandhi (rgandhi)" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-11.txt Thread-Index: AQHTDGRkFQtuHaNMpEKHfCnWhggy06JyxTsA Date: Thu, 3 Aug 2017 14:40:29 +0000 Message-ID: <0677235C-B0CD-433A-828F-7A3CF9205C87@cisco.com> References: <150177033665.9682.16331556632242398651@ietfa.amsl.com> In-Reply-To: <150177033665.9682.16331556632242398651@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.247.50] Content-Type: text/plain; charset="utf-8" Content-ID: <98AF14DBCC89FC418AC63104812B7CF3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-11.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:40:33 -0000 SGkgV0csDQoNCldlIGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiB3aXRoIHVwZGF0ZWQgU2Vj dXJpdHkgc2VjdGlvbi4NCg0KV2VsY29tZSB5b3VyIHJldmlldyBjb21tZW50cyBhbmQgc3VnZ2Vz dGlvbnMuDQoNClRoYW5rcywNClJha2VzaA0KDQoNCk9uIDIwMTctMDgtMDMsIDEwOjI1IEFNLCAi VGVhcyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8dGVhcy1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0K DQogICAgDQogICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KICAgIFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIFRyYWZmaWMgRW5naW5lZXJpbmcgQXJjaGl0ZWN0dXJlIGFuZCBTaWdu YWxpbmcgV0cgb2YgdGhlIElFVEYuDQogICAgDQogICAgICAgICAgICBUaXRsZSAgICAgICAgICAg OiBVcGRhdGVzIHRvIFJlc291cmNlIFJlc2VydmF0aW9uIFByb3RvY29sIEZvciBGYXN0IFJlcm91 dGUgb2YgVHJhZmZpYyBFbmdpbmVlcmluZyBHTVBMUyBMU1BzDQogICAgICAgICAgICBBdXRob3Jz ICAgICAgICAgOiBNaWtlIFRhaWxsb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRh cmVrIFNhYWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJha2VzaCBHYW5kaGkNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFphZmFyIEFsaQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTWFuYXYgQmhhdGlhDQogICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGUtMTEudHh0DQogICAgCVBhZ2VzICAgICAgICAg ICA6IDIzDQogICAgCURhdGUgICAgICAgICAgICA6IDIwMTctMDgtMDMNCiAgICANCiAgICBBYnN0 cmFjdDoNCiAgICAgICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgdGhlIFJlc291cmNlIFJlc2VydmF0 aW9uIFByb3RvY29sIC0gVHJhZmZpYw0KICAgICAgIEVuZ2luZWVyaW5nIChSU1ZQLVRFKSBGYXN0 IFJlcm91dGUgKEZSUikgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFJGQw0KICAgICAgIDQwOTAgdG8g c3VwcG9ydCBQYWNrZXQgU3dpdGNoZWQgQ2FwYWJsZSAoUFNDKSBHZW5lcmFsaXplZCBNdWx0aS0N CiAgICAgICBQcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKEdNUExTKSBMYWJlbCBTd2l0Y2hlZCBQ YXRocyAoTFNQcykuICBUaGVzZQ0KICAgICAgIHVwZGF0ZXMgYWxsb3cgdGhlIGNvb3JkaW5hdGlv biBvZiBhIGJpZGlyZWN0aW9uYWwgYnlwYXNzIHR1bm5lbA0KICAgICAgIGFzc2lnbm1lbnQgcHJv dGVjdGluZyBhIGNvbW1vbiBmYWNpbGl0eSBpbiBib3RoIGZvcndhcmQgYW5kIHJldmVyc2UNCiAg ICAgICBkaXJlY3Rpb25zIG9mIGEgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLiAgSW4gYWRk aXRpb24sIHRoZXNlDQogICAgICAgdXBkYXRlcyBlbmFibGUgdGhlIHJlLWRpcmVjdGlvbiBvZiBi aWRpcmVjdGlvbmFsIHRyYWZmaWMgb250byBieXBhc3MNCiAgICAgICB0dW5uZWxzIHRoYXQgZW5z dXJlIGNvLXJvdXRlZG5lc3Mgb2YgZGF0YSBwYXRocyBpbiB0aGUgZm9yd2FyZCBhbmQNCiAgICAg ICByZXZlcnNlIGRpcmVjdGlvbnMgYWZ0ZXIgRlJSIGFuZCBhdm9pZCBSU1ZQIHNvZnQtc3RhdGUg dGltZW91dCBpbg0KICAgICAgIGNvbnRyb2wtcGxhbmUuDQogICAgDQogICAgDQogICAgDQogICAg VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLWxz cC1mYXN0cmVyb3V0ZS8NCiAgICANCiAgICBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u cyBhdmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGUtMTENCiAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGUt MTENCiAgICANCiAgICBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFi bGUgYXQ6DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt dGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGUtMTENCiAgICANCiAgICANCiAgICBQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRlYXMgbWFpbGluZyBsaXN0DQogICAgVGVhc0Bp ZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0K ICAgIA0KDQo= From nobody Thu Aug 3 08:39:23 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07524132392; Thu, 3 Aug 2017 08:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSudjh7QE6Sg; Thu, 3 Aug 2017 08:39:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5DB86132453; Thu, 3 Aug 2017 08:39:20 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v73FcWJt089974 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 Aug 2017 10:39:11 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Thu, 3 Aug 2017 10:39:11 -0500 Cc: The IESG , "draft-ietf-teas-gmpls-scsi@ietf.org" , Vishnu Beeram , "teas-chairs@ietf.org" , "teas@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8751F81E-7F0F-4F25-B607-A1589EE6F54F@nostrum.com> References: <150171446174.5764.9578371193226819669.idtracker@ietfa.amsl.com> To: Daniele Ceccarelli X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Teas] Ben Campbell's No Objection on draft-ietf-teas-gmpls-scsi-03: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 15:39:22 -0000 Thanks! Ben. > On Aug 3, 2017, at 1:53 AM, Daniele Ceccarelli = wrote: >=20 > Hi Ben, >=20 > thanks for the review. IANA already took its decision as part of its = review:=20 >=20 > "A new registry is to be created called the "Generalized SCSI = (Switching Capability Specific Information) TLVs Types" registry. This = new registry will be created on the Generalized Multi-Protocol Label = Switching (GMPLS) Signaling Parameters registry page located at: >=20 > https://www.iana.org/assignments/gmpls-sig-parameters/" >=20 > I think we can update the text accordingly. > Thanks a lot > Daniele =20 >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: gioved=C3=AC 3 agosto 2017 00:54 > To: The IESG > Cc: draft-ietf-teas-gmpls-scsi@ietf.org; Vishnu Beeram = ; teas-chairs@ietf.org; vbeeram@juniper.net; = teas@ietf.org > Subject: Ben Campbell's No Objection on draft-ietf-teas-gmpls-scsi-03: = (with COMMENT) >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-teas-gmpls-scsi-03: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-scsi/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > - 6, paragraph 2: I think the draft needs to specify where IANA will = put the registry, not leave it up to their discretion. >=20 >=20 From nobody Thu Aug 10 13:20:31 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 241C01323AE; Thu, 10 Aug 2017 13:20:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-teas-lsp-diversity@ietf.org, lberger@labn.net, teas-chairs@ietf.org, teas@ietf.org, db3546@att.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150239642305.11932.13335922726093665368.idtracker@ietfa.amsl.com> Date: Thu, 10 Aug 2017 13:20:23 -0700 Archived-At: Subject: [Teas] Last Call: (Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route) to Proposed Standard X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 20:20:23 -0000 The IESG has received a request from the Traffic Engineering Architecture and Signaling WG (teas) to consider the following document: - 'Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-08-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Resource ReserVation Protocol-Traffic Engineering provides support for the communication of exclusion information during label switched path (LSP) setup. This document specifies two new diversity subobjects for the RSVP XRO and EXRS subobjects. Three different mechanisms are supported how LSP diversity can be accomplished in the provider or core network: the signaled diversity type, indicates whether diversity is based on client, path computation engine (PCE), or network assigned identifiers. The solution described in this document is based on the assumption that LSPs are requested sequentially, i.e., the time period between the LSP setup requests for the two LSPs may be longer (days, weeks, months). Re-routing the first LSP that may have existed for a longer period of time is not considered. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1943/ https://datatracker.ietf.org/ipr/2383/ From nobody Thu Aug 10 13:37:45 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 003431323BC; Thu, 10 Aug 2017 13:37:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-teas-pce-central-control@ietf.org, db3546@att.com, Vishnu Beeram , teas-chairs@ietf.org, teas@ietf.org, vbeeram@juniper.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150239745692.11900.8397071149243291127.idtracker@ietfa.amsl.com> Date: Thu, 10 Aug 2017 13:37:36 -0700 Archived-At: Subject: [Teas] Last Call: (An Architecture for Use of PCE and PCEP in a Network with Central Control) to Informational RFC X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 20:37:37 -0000 The IESG has received a request from the Traffic Engineering Architecture and Signaling WG (teas) to consider the following document: - 'An Architecture for Use of PCE and PCEP in a Network with Central Control' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-08-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Path Computation Element (PCE) has become established as a core component of Software Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network for any definition of "optimal" and can also monitor changes in resource availability and traffic demands to update the paths. Conventionally, the PCE has been used to derive paths for MPLS Label Switched Paths (LSPs). These paths are supplied using the Path Computation Element Communication Protocol (PCEP) to the head end of the LSP for signaling in the MPLS network. SDN has a far broader applicability than just signaled MPLS traffic engineered networks, and the PCE may be used to determine paths in a wide range of use cases including static LSPs, segment routing, service function chaining (SFC), and indeed any form of routed or switched network. It is, therefore, reasonable to consider PCEP as a general southbound control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a southbound interface, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Aug 10 14:19:38 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D5413242F for ; Thu, 10 Aug 2017 14:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFzyDhWxUTxu for ; Thu, 10 Aug 2017 14:19:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F03313201B for ; Thu, 10 Aug 2017 14:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=300; q=dns/txt; s=iport; t=1502399972; x=1503609572; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=buwP3ZLi9n+AoV2oQWK9MdNeOy4dDJW5L9+y+407FmU=; b=K/LdZh9MYoXy+qaLFc/IiJH8BD+DCtemX0Pl9/Y77lFHP64JrT/2ryiZ dPRhuFlanK1nso9BMk6MCLDkcY0zibFxr0Cp4ZaYFaKg9RznpMVLHP+0d l1dT1m7Fb1kcRCmcZL9XD8yr1d8G7gnsBcvjheyoP26YC0gxPkl/CLDD1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAADxzIxZ/4cNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBf44IkAyYA4IShUeEez8YAQIBAQEBAQEBayiFWT8SAT5CJgEEDg2?= =?us-ascii?q?KJ686i2MBAQEBAQEEAQEBAQEBASGDKIICgUyPcQWgIAKBZpJHggABF4VdimaWD?= =?us-ascii?q?QEfOIEKdxWHYgGKFAGBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,354,1498521600"; d="scan'208";a="284818366" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Aug 2017 21:19:31 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7ALJVur005308 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 10 Aug 2017 21:19:31 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Aug 2017 16:19:31 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Thu, 10 Aug 2017 16:19:30 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" CC: "Matt Hartley (mhartley)" Thread-Topic: Minutes from Prague Thread-Index: AdMSHgVx+kUNeg7iRPGcSsVXxIrdeQ== Date: Thu, 10 Aug 2017 21:19:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.177] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Teas] Minutes from Prague X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 21:19:37 -0000 All, The minutes from Prague have now been uploaded for both sessions. I've been= through the session recordings, but please check them to ensure your comme= nts were recorded accurately. Many thanks to Haomian, Italo and the other anonymous people who contribute= d. Cheers Matt=20 From nobody Thu Aug 10 20:11:00 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CB0132395; Thu, 10 Aug 2017 20:10:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150242105876.8480.15299823081501542952@ietfa.amsl.com> Date: Thu, 10 Aug 2017 20:10:58 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-scaling-rec-06.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 03:10:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments Authors : Vishnu Pavan Beeram Ina Minei Rob Shakir Dante Pacella Tarek Saad Filename : draft-ietf-teas-rsvp-te-scaling-rec-06.txt Pages : 10 Date : 2017-08-10 Abstract: The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed is growing continually and the onus is on RSVP-TE implementations across the board to keep up with this increasing demand. This document introduces a couple of techniques - "Refresh-Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - to help RSVP-TE deployments push the envelope on scaling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-06 https://datatracker.ietf.org/doc/html/draft-ietf-teas-rsvp-te-scaling-rec-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-scaling-rec-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 10 20:37:54 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31957131C9E; Thu, 10 Aug 2017 20:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T00MNUfElyqZ; Thu, 10 Aug 2017 20:37:42 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 A4370131D1E; Thu, 10 Aug 2017 20:37:42 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id f9so10717305uaf.4; Thu, 10 Aug 2017 20:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o6Fk/tv1KasgnCA/jXRCCn03mJ4lGAWNbBTCads20t8=; b=T8wcGxQ5uD6bqcRYI9u8VaHmLnzDqT90k+WddkjVMFIgcCQbsq0co4+O99ggms4+HY a9r8SLYcLhugcbo8/Q1rrMYl8uU9t1FDT0JcgNm1EH5K+NRZlfuZfGkx6db9tXRz0tN5 CAxOzgTe4T5IlM94RLVFE1/dSoi9txWwOJXGlN1jjDcTdoY9o15phrXCxfIaJoNo4kUT o3WAaTRg6HJK9FkE0h/GvDkEYIScdfzK5oGAjs7dKxI8iXoOUcXQlfN1p6ltZW7a4wzf W4CW2qXM8e40CEvKvdfF6Mm56jpS4cpaKmpY/gtQFJuMsLaIVEoDp0KBZrfKi6dst2ie hhUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o6Fk/tv1KasgnCA/jXRCCn03mJ4lGAWNbBTCads20t8=; b=UppCeSxJtlMFplC5/FJIs/o+RZc1ZQy2wgYoRULCJ+o8K7wpmA5KdQsaMdTWxp+63b upNbrPnIunxJGnyHV5+zmxgeFZp6yZn2VLZ6EntY3EZX7CAI2AX/vCi/njc80bYblhb4 7xSVTwZ9bSQwM0wuqb2va8PuHE3+AaIRiX+/NYoGSkU50Hjojd8vD+HiAs4zN9gN6r/2 4OgpLxeHU8dBV8ZTYnyHaKJDAjjmUxgKIX6f51aEV4P3HTsSGexSfnk0GByjxljdNT2S HlEuAu4Gi3l15lgyQn6s3DscRvytW4Hg/wFkmBkelZejovIhVcIqQQvZ1mRiY2SMyiKt LWZg== X-Gm-Message-State: AHYfb5htlwOZkGtBxeCLrFWQbU6tOjgxmG4EqTwcrKyJ0/TUb0uayq9c WxIsbkdIE3uPczMKWBbEGc9mZZmCyA== X-Received: by 10.176.2.205 with SMTP id 71mr10628613uah.161.1502422661782; Thu, 10 Aug 2017 20:37:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.60.74 with HTTP; Thu, 10 Aug 2017 20:37:41 -0700 (PDT) In-Reply-To: References: From: Vishnu Pavan Beeram Date: Thu, 10 Aug 2017 23:37:41 -0400 Message-ID: To: Victoria Pritchard Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, "teas@ietf.org" Content-Type: multipart/alternative; boundary="001a113acb420ee28b05567209b2" Archived-At: Subject: Re: [Teas] RtgDir review: draft-ietf-teas-rsvp-te-scaling-rec-05 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 03:37:45 -0000 --001a113acb420ee28b05567209b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Victoria, Hi! Much Thanks for the review. We (the authors) just posted a new rev (-06) to address the nits below. Please do go over the diffs ( https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-scaling-rec-0= 6.txt ) and let us know if there are any further concerns. Please see inline (prefixed VPB) below for responses. Regards, -Pavan (on behalf of the authors) On Thu, Jul 27, 2017 at 5:31 PM, Victoria Pritchard wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, plea= se > see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-teas-rsvp-te-scaling-rec-05 > Reviewer: Victoria Pritchard > Review Date: 27/07/2017 > IETF LC End Date: > Intended Status: Standards Track > > *Summary:* > > This document is basically ready for publication, but has nits that shoul= d > be considered prior to publication. > > *Comments:* > > The draft is well written and really clear to read, although contains som= e > language which does not read as formally as I would expect from a standar= ds > track document, especially in the appendix. > > *Major Issues:* > > No major issues found. > > *Minor Issues:* > > No minor issues found. > > *Nits:* > > Section 2.2 "MUST act as if the all the Path" contains an extra "the". > [VPB] Fixed. > Section 2.3 "RSVP- TE control plane congestion" has an extra space after > RSVP. > [VPB] Fixed. > Also, I'm not sure a sentence should start with "And". > [VPB] There are sufficient examples in today's literature (technical or otherwise) of sentences that start with a "conjunction". We left the sentence as is for now -- 'll revisit if the concern persists. > Section 2.3.2 "it is risky to assume" - would it be better to say MUST NO= T > assume, or SHOULD NOT assume? > [VPB] Fixed. > > Appendix - after stating the default value, would help to separate the > explanation using either a full stop or a new line. > > "sort of analogous", "same ballpark", "nicely matches up", "about 30 (31.= 5 > to be precise)" seemed strange phrases to use and could be reworded to be > more formal. > > > [VPB] Fixed -- added a full stop after each value and rephrased the specified sentences . > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > --001a113acb420ee28b05567209b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Victoria, Hi!

Much Thanks for the revie= w. We (the authors) just posted a new rev (-06) to address the nits below. = Please do go over the diffs ( https://tools.ietf.org/rfcd= iff?url2=3Ddraft-ietf-teas-rsvp-te-scaling-rec-06.txt )=C2=A0and let us= know if there are any further concerns.

Please se= e inline (prefixed VPB) below for responses.

Regar= ds,
-Pavan (on behalf of the authors)

On Thu, Jul 27, 2017 at 5:31 PM, Victoria= Pritchard <pritchardv0@gmail.com> wrote:

Hello= ,

I have been selecte= d as the Routing Directorate reviewer for this draft. The Routing Directora= te seeks to review all routing or routing-related drafts as they pass throu= gh IETF last call and IESG review, and sometimes on special request. The pu= rpose of the review is to provide assistance to the Routing ADs. For more i= nformation about the Routing Directorate, please see=C2=A0=E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki= /RtgDir

Although thes= e comments are primarily for the use of the Routing ADs, it would be helpfu= l if you could consider them along with any other IETF Last Call comments t= hat you receive, and strive to resolve them through discussion or by updati= ng the draft.

Document: d= raft-ietf-teas-rsvp-te-scaling-rec-05=C2=A0
Reviewer: Victoria Prit= chard
Review Date: 27/07/2017
IETF LC End Date: =C2=A0
Intended St= atus: Standards Track

Summary:

Th= is document is basically ready for publication, but has nits that should be= considered prior to publication.

Comments:

The draft is well written and really clear to read, although con= tains some language which does not read as formally as I would expect from = a standards track document, especially in the appendix.

Major Issues:

No major issues found.

Minor Issues:

No minor issues found.

Nits:

Section 2.2 "MUST act as if t= he all the Path" contains an extra "the".

[VPB] Fixed.=C2=A0

Section 2.3=C2=A0"RSVP- TE control plane congestion" has an extra spa= ce after RSVP.

[VPB] Fixed.=C2=A0

Also, I'm not sure a sentence shoul= d start with "And".

[VPB] There= are sufficient examples in today's literature (technical or otherwise)= of sentences that start with a "conjunction".=C2=A0 We left the = sentence as is for now -- 'll revisit if the concern persists.=C2=A0

Section 2.3.2 "it is risky to= assume" - would it be better to say MUST NOT assume, or SHOULD NOT as= sume?

[VPB] =C2=A0Fixed.


Appendix - after stating the = default value, would help to separate the explanation using either a full s= top or a new line.

"sort of analogous", "same = ballpark", "nicely matches up", "about 30 (31.5 to be p= recise)" seemed strange phrases to use and could be reworded to be mor= e formal.


=
[VPB] Fixed -- added a full stop after each value a= nd rephrased the specified sentences .=C2=A0



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


--001a113acb420ee28b05567209b2-- From nobody Thu Aug 10 23:27:32 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDAF1324DB; Thu, 10 Aug 2017 23:27:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150243284515.8585.2848914626167021096@ietfa.amsl.com> Date: Thu, 10 Aug 2017 23:27:25 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-network-assigned-upstream-label-07.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 06:27:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Network Assigned Upstream-Label Authors : Xian Zhang Vishnu Pavan Beeram Igor Bryskin Daniele Ceccarelli Oscar Gonzalez de Dios Filename : draft-ietf-teas-network-assigned-upstream-label-07.txt Pages : 8 Date : 2017-08-10 Abstract: This document discusses a Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP- TE) mechanism that enables the network to assign an upstream label for a bidirectional label-switched path (LSP). This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFC3473. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-network-assigned-upstream-label/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-network-assigned-upstream-label-07 https://datatracker.ietf.org/doc/html/draft-ietf-teas-network-assigned-upstream-label-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-network-assigned-upstream-label-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 10 23:37:14 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711C21321A3; Thu, 10 Aug 2017 23:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 58TYFbwenU9Y; Thu, 10 Aug 2017 23:37:09 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 D6F7F132496; Thu, 10 Aug 2017 23:37:08 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id u133so10330117vke.3; Thu, 10 Aug 2017 23:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rif9F/hjOPhPWJ5Uvbb7uof3iV7ztwykrtaFd9R+bHU=; b=kwcNbfelDPjSHP9EFFaWIOnZ4wmttskTnEobFNcKFYvJMYACvAtfTP+JczyoX1UU6P BiUtNi2QNUkG436XH1mjrJFgCjbbbh1KlYWvoYdjP3pGkIvfZyO5Y+OYek4MYJZ3vE8v gvvRlYGn8XZHxx8/u0FnwCazD3RROpltbl/awcmmxKUgU0eX67AjrNCuW1JctAI4t1Tz gmHGQ1/kB5mBv8EkncRjJWagwZ4Bl6wAQJY8/YUBJQ/S2Jdc6GwLn0YjpkvrhzTiEfmQ yITOv4AvrGeCRUbL2s6I95ZO68iYoXH3CvUrLAy/tIJWbjVuG7pGhXAGO+oXGGyArys8 Bsng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rif9F/hjOPhPWJ5Uvbb7uof3iV7ztwykrtaFd9R+bHU=; b=DEQVQUXB8tKfuNCoidGgj91LRvrFrJ2Y8IYpc3Ak5mPZV3z0jpJO3BR+i5LTICYwl5 e/nO/u98civSRh6G78eCQ3EI4qJJWK1XmytczDdJX5RyuR1wfFISAEIRw21SyZJoGpKK tHXeNUCGMzreo5zjJPMKCTxlMtT1J3nTMH+05StXWmwB8YmaAmNh8eabPwe74ldMxPf+ J151p6L29CV/5Tv6RHj1O3Yf5xuXGtxbaS8enEBJZwNOrOHvJTX8v8jDvrnGWy7Q9jgj Av+G/MNVYcQvAHPWRY3c278fuKl3ElY67QhwDSUCAFHbagDnQGfiYZwXwKLLKIw+Y+tl DMWQ== X-Gm-Message-State: AHYfb5hsLWI45Ll+Ki8VSS6y54hBuK/p3C1h6UGiBrWwQSO/qfmoefwj 86LsJuNK31AFrYvbzyTK/acHMNahcg== X-Received: by 10.31.79.4 with SMTP id d4mr10030696vkb.194.1502433427922; Thu, 10 Aug 2017 23:37:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.60.74 with HTTP; Thu, 10 Aug 2017 23:37:07 -0700 (PDT) In-Reply-To: References: From: Vishnu Pavan Beeram Date: Fri, 11 Aug 2017 02:37:07 -0400 Message-ID: To: "Acee Lindem (acee)" Cc: Routing ADs , Routing Directorate , "teas@ietf.org" , "draft-ietf-teas-network-assigned-upstream-label@ietf.org" Content-Type: multipart/alternative; boundary="001a114dfb48c527ba0556748aaa" Archived-At: Subject: Re: [Teas] RtgDir review: draft-ietf-teas-network-assigned-upstream-label-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 06:37:13 -0000 --001a114dfb48c527ba0556748aaa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Acee, Hi! Much Thanks for the review. We (the authors) just posted a new rev (-07) to address the all the nits identified below. Please do go over the diffs ( https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-network-assigned-upst= ream-label-07.txt ) and let us know if there are any further concerns. Regards, -Pavan (on behalf of the authors) On Sat, Jul 8, 2017 at 1:29 PM, Acee Lindem (acee) wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, plea= se > see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-teas-network-assigned-upstream-label-06 > Reviewer: Acee Lindem > Review Date: July 8th, 2017 > IETF LC End Date: Completed =E2=80=93 Submitted to IESG for publication > Intended Status: Standards Track > > Summary: > This document is basically ready for publication, but has nits that > should be considered prior to publication. > > Comments: > The document provides an extension to GMPLS RSVP Bi-directional LSP > upstream label assignment which > supports negotiation of the upstream label. This is accomplished by > the upstream router specifying a > special value, 0xFFFFFFFF, in the UPSTREAM_LABEL object and a set of > candidate labels in the LABEL_SET > object of the PATH message. The downstream router will select an > appropriate label from the LABEL_SET > labels and returns it in the LABEL object of the corresponding RESV > message. The document is generally > well organized and written. The technical solution is both > straight-forward and complete. > > Major Issues: > No major issues found. > > Minor Issues: > No minor issues found. > > Nits: > 1. Expand acronyms on first usage. For example, LSP and WDM are not > considered =E2=80=9Cwell-known=E2=80=9D as defined in https://www.rfc-edi= tor.org/ > materials/abbrev.expansion.txt > > 2. Suggested Editorial Changes: > > *** draft-ietf-teas-network-assigned-upstream-label-06.txt.orig > 2017-07-08 12:12:18.000000000 -0400 > --- draft-ietf-teas-network-assigned-upstream-label-06.txt > 2017-07-08 12:55:57.000000000 -0400 > *************** > *** 127,138 **** > 2. Unassigned Upstream Label > > This document proposes the use of a special label value - > ! "0xFFFFFFFF" (for a 4-byte label) - to indicate an Unassigned > Upstream Label. Similar "all-ones" patterns are expected to be used > for labels of other sizes. The presence of this value in the > UPSTREAM_LABEL object of a PATH message indicates that the upstream > node has not assigned an upstream label on its own and has requested > ! the downstream node to provide a label that it can use in both > forward and reverse directions. The presence of this value in the > UPSTREAM_LABEL object of a PATH message MUST also be interpreted by > the receiving node as a request to mandate symmetric labels for the > --- 127,138 ---- > 2. Unassigned Upstream Label > > This document proposes the use of a special label value - > ! "0xFFFFFFFF" (for a 4-octet label) - to indicate an Unassigned > Upstream Label. Similar "all-ones" patterns are expected to be used > for labels of other sizes. The presence of this value in the > UPSTREAM_LABEL object of a PATH message indicates that the upstream > node has not assigned an upstream label on its own and has requested > ! the downstream node to provide a label that it can use in both the > forward and reverse directions. The presence of this value in the > UPSTREAM_LABEL object of a PATH message MUST also be interpreted by > the receiving node as a request to mandate symmetric labels for the > *************** > *** 160,166 **** > Label in the PATH message even after it receives an appropriate > symmetric label in the RESV message. This is done to make sure that > the downstream node would pick a different symmetric label if and > ! when it needs to change the label at a later point in time. If the > > > > --- 160,166 ---- > Label in the PATH message even after it receives an appropriate > symmetric label in the RESV message. This is done to make sure that > the downstream node would pick a different symmetric label if and > ! when it needs to change the label at a later time. If the > > > > *************** > *** 226,237 **** > Internet-Draft Network Assigned Upstream-Label June 201= 7 > > > ! router send signal into the optical network unless it is at the > appropriate wavelength. In other words, having the router send > ! signal with a wrong wavelength may adversely impact existing optical > trails. If the clients do not have full visibility into the optical > network, they are not in a position to pick the correct wavelength > ! up-front. > > The rest of this section examines how the protocol mechanism propose= d > in this document allows the optical network to select and communicat= e > --- 226,237 ---- > Internet-Draft Network Assigned Upstream-Label June 201= 7 > > > ! router send the signal into the optical network unless it is at the > appropriate wavelength. In other words, having the router send > ! signals with a wrong wavelength may adversely impact existing optica= l > trails. If the clients do not have full visibility into the optical > network, they are not in a position to pick the correct wavelength > ! in advance. > > The rest of this section examines how the protocol mechanism propose= d > in this document allows the optical network to select and communicat= e > *************** > *** 272,278 **** > > o The downstream node (Node F) receives the PATH message, chooses > the appropriate wavelength values and forwards them in appropriat= e > ! label fields to the egress client ("Router B") > > > > --- 272,278 ---- > > o The downstream node (Node F) receives the PATH message, chooses > the appropriate wavelength values and forwards them in appropriat= e > ! label fields to the egress client ("Router B"). > > > > *************** > *** 284,290 **** > > o "Router B" receives the PATH message, turns the laser ON and tune= s > it to the appropriate wavelength (received in the UPSTREAM_LABEL/ > ! LABEL_SET of the PATH) and sends out a RESV message upstream. > > o The RESV message received by the ingress client carries a valid > symmetric label in the LABEL object. "Router A" turns on the > --- 284,290 ---- > > o "Router B" receives the PATH message, turns the laser ON and tune= s > it to the appropriate wavelength (received in the UPSTREAM_LABEL/ > ! LABEL_SET of the PATH message) and sends a RESV message upstream. > > o The RESV message received by the ingress client carries a valid > symmetric label in the LABEL object. "Router A" turns on the > *************** > *** 306,318 **** > > After the LSP is set up, the network may decide to change the > wavelength for the given LSP. This could be for a variety of reason= s > ! - policy reasons, restoration within the core, preemption etc. > > In such a scenario, if the ingress client receives a changed label > ! via the LABEL object in a RESV modify, it retunes the laser at the > ! ingress to the new wavelength. Similarly, if the egress client > ! receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH > ! modify, it retunes the laser at the egress to the new wavelength. > > 4. Acknowledgements > > --- 306,320 ---- > > After the LSP is set up, the network may decide to change the > wavelength for the given LSP. This could be for a variety of reason= s > ! including policy reasons, restoration within the core, preemption, > ! etc. > > In such a scenario, if the ingress client receives a changed label > ! via the LABEL object in a modified RESV message, it retunes the lase= r > ! at the ingress to the new wavelength. Similarly, if the egress clie= nt > ! receives a changed label via UPSTREAM_LABEL/LABEL_SET in a modified > ! PATH message, it retunes the laser at the egress to the new > ! wavelength. > > 4. Acknowledgements > > *************** > *** 358,364 **** > semantics of a specific field in an existing RSVP object and the > corresponding procedures. Thus, there are no new security > implications raised by this document and the security considerations > ! put together by [RFC3473] still applies. > > For a general discussion on MPLS and GMPLS related security issues, > see the MPLS/GMPLS security framework [RFC5920]. > --- 360,366 ---- > semantics of a specific field in an existing RSVP object and the > corresponding procedures. Thus, there are no new security > implications raised by this document and the security considerations > ! discussed by [RFC3473] still apply. > > For a general discussion on MPLS and GMPLS related security issues, > see the MPLS/GMPLS security framework [RFC5920]. > > Thanks, > Acee > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > --001a114dfb48c527ba0556748aaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Acee, Hi!

Much Thanks for the review. We= (the authors) just posted a new rev (-07) to address the all the nits iden= tified below. Please do go over the diffs ( h= ttps://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-network-assigned-upstr= eam-label-07.txt ) and let us know if there are any further concerns.
Regards,
-Pavan (on behalf of the authors)

On Sat, Jul 8, 2017 a= t 1:29 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
Hello,

I have been selected as the Routing = Directorate reviewer for this draft. The Routing Directorate seeks to revie= w all routing or routing-related drafts as they pass through IETF last call= and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the= Routing ADs. For more information about the Routing Directorate, please se= e =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDi= r

Although these comments are primaril= y for the use of the Routing ADs, it would be helpful if you could consider= them along with any other IETF Last Call comments that you receive, and st= rive to resolve them through discussion or by updating the draft.

Document: draft-ietf-teas-network-assigned-upstream-label-06
Reviewer: Acee Lindem
Review Date: July 8th, 2017
IETF LC End Date: Completed =E2=80= =93 Submitted to IESG for publication
Intended Status: Standards Track

Summary:
=C2=A0 =C2=A0 This document is basic= ally ready for publication, but has nits that should be considered prior to= publication.
=C2=A0=C2=A0
Comments:
=C2=A0 =C2=A0 The document provides = an extension to GMPLS RSVP Bi-directional LSP upstream label assignment whi= ch=C2=A0
=C2=A0 =C2=A0 supports negotiation o= f the upstream label. This is accomplished by the upstream router specifyin= g a=C2=A0
=C2=A0 =C2=A0 special value, 0xFFFFF= FFF, in the UPSTREAM_LABEL object and a set of candidate labels in the LABE= L_SET
=C2=A0 =C2=A0 object of the PATH mes= sage. The downstream router will select an appropriate label from the LABEL= _SET
=C2=A0 =C2=A0 labels and returns it = in the LABEL object of the corresponding RESV message. The document is gene= rally
=C2=A0 =C2=A0 well organized and wri= tten.=C2=A0The technical solution is both straight-forward and compl= ete.=C2=A0

Major Issues:
=C2=A0 No major issues found.=C2=A0<= /font>
=C2=A0 =C2=A0=C2=A0
Minor Issues:
=C2=A0 No minor issues found.=C2=A0<= /font>
=C2=A0 =C2=A0
Nits:
=C2=A0 =C2=A01. Expand acronyms on f= irst usage. For example, LSP and WDM are not considered =E2=80=9Cwell-known= =E2=80=9D as defined in https://www.rfc-editor.org/materi= als/abbrev.expansion.txt

=C2=A0 =C2=A02. Suggested Editorial = Changes:=C2=A0

*** draft-ietf-teas-network-ass= igned-upstream-label-06.txt.orig
2017-07-08 12:12:18.000000000 -0400<= /font>
--- draft-ietf-teas-network-ass= igned-upstream-label-06.txt
2017-07-08 12:55:57.000000000 -0400<= /font>
***************
*** 127,138 ****
=C2=A0 2.=C2=A0 Unassigned Upstream = Label
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0This document pr= oposes the use of a special label value -
! =C2=A0 =C2=A0"0xFFFFFFFF"= ; (for a 4-byte label) - to indicate an Unassigned
=C2=A0 =C2=A0 =C2=A0Upstream Label.= =C2=A0 Similar "all-ones" patterns are expected to be used=
=C2=A0 =C2=A0 =C2=A0for labels of ot= her sizes.=C2=A0 The presence of this value in the
=C2=A0 =C2=A0 =C2=A0UPSTREAM_LABEL o= bject of a PATH message indicates that the upstream
=C2=A0 =C2=A0 =C2=A0node has not ass= igned an upstream label on its own and has requested
! =C2=A0 =C2=A0the downstream node t= o provide a label that it can use in both
=C2=A0 =C2=A0 =C2=A0forward and reve= rse directions.=C2=A0 The presence of this value in the
=C2=A0 =C2=A0 =C2=A0UPSTREAM_LABEL o= bject of a PATH message MUST also be interpreted by
=C2=A0 =C2=A0 =C2=A0the receiving no= de as a request to mandate symmetric labels for the
--- 127,138 ----
=C2=A0 2.=C2=A0 Unassigned Upstream = Label
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0This document pr= oposes the use of a special label value -
! =C2=A0 =C2=A0"0xFFFFFFFF"= ; (for a 4-octet label) - to indicate an Unassigned
=C2=A0 =C2=A0 =C2=A0Upstream Label.= =C2=A0 Similar "all-ones" patterns are expected to be used=
=C2=A0 =C2=A0 =C2=A0for labels of ot= her sizes.=C2=A0 The presence of this value in the
=C2=A0 =C2=A0 =C2=A0UPSTREAM_LABEL o= bject of a PATH message indicates that the upstream
=C2=A0 =C2=A0 =C2=A0node has not ass= igned an upstream label on its own and has requested
! =C2=A0 =C2=A0the downstream node t= o provide a label that it can use in both the
=C2=A0 =C2=A0 =C2=A0forward and reve= rse directions.=C2=A0 The presence of this value in the
=C2=A0 =C2=A0 =C2=A0UPSTREAM_LABEL o= bject of a PATH message MUST also be interpreted by
=C2=A0 =C2=A0 =C2=A0the receiving no= de as a request to mandate symmetric labels for the
***************
*** 160,166 ****
=C2=A0 =C2=A0 =C2=A0Label in the PAT= H message even after it receives an appropriate
=C2=A0 =C2=A0 =C2=A0symmetric label = in the RESV message.=C2=A0 This is done to make sure that
=C2=A0 =C2=A0 =C2=A0the downstream n= ode would pick a different symmetric label if and
! =C2=A0 =C2=A0when it needs to chan= ge the label at a later point in time.=C2=A0 If the
=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0
--- 160,166 ----
=C2=A0 =C2=A0 =C2=A0Label in the PAT= H message even after it receives an appropriate
=C2=A0 =C2=A0 =C2=A0symmetric label = in the RESV message.=C2=A0 This is done to make sure that
=C2=A0 =C2=A0 =C2=A0the downstream n= ode would pick a different symmetric label if and
! =C2=A0 =C2=A0when it needs to chan= ge the label at a later time.=C2=A0 If the
=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0
***************
*** 226,237 ****
=C2=A0 Internet-Draft =C2=A0 =C2=A0 = =C2=A0 Network Assigned Upstream-Label =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 J= une 2017
=C2=A0=C2=A0
=C2=A0=C2=A0
! =C2=A0 =C2=A0router send signal in= to the optical network unless it is at the
=C2=A0 =C2=A0 =C2=A0appropriate wave= length.=C2=A0 In other words, having the router send
! =C2=A0 =C2=A0signal with a wrong w= avelength may adversely impact existing optical
=C2=A0 =C2=A0 =C2=A0trails.=C2=A0 If= the clients do not have full visibility into the optical
=C2=A0 =C2=A0 =C2=A0network, they ar= e not in a position to pick the correct wavelength
! =C2=A0 =C2=A0up-front.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0The rest of this= section examines how the protocol mechanism proposed
=C2=A0 =C2=A0 =C2=A0in this document= allows the optical network to select and communicate
--- 226,237 ----
=C2=A0 Internet-Draft =C2=A0 =C2=A0 = =C2=A0 Network Assigned Upstream-Label =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 J= une 2017
=C2=A0=C2=A0
=C2=A0=C2=A0
! =C2=A0 =C2=A0router send the signa= l into the optical network unless it is at the
=C2=A0 =C2=A0 =C2=A0appropriate wave= length.=C2=A0 In other words, having the router send
! =C2=A0 =C2=A0signals with a wrong = wavelength may adversely impact existing optical
=C2=A0 =C2=A0 =C2=A0trails.=C2=A0 If= the clients do not have full visibility into the optical
=C2=A0 =C2=A0 =C2=A0network, they ar= e not in a position to pick the correct wavelength
! =C2=A0 =C2=A0in advance.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0The rest of this= section examines how the protocol mechanism proposed
=C2=A0 =C2=A0 =C2=A0in this document= allows the optical network to select and communicate
***************
*** 272,278 ****
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0The down= stream node (Node F) receives the PATH message, chooses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the appr= opriate wavelength values and forwards them in appropriate
! =C2=A0 =C2=A0 =C2=A0 label fields = to the egress client ("Router B")
=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0
--- 272,278 ----
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0The down= stream node (Node F) receives the PATH message, chooses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the appr= opriate wavelength values and forwards them in appropriate
! =C2=A0 =C2=A0 =C2=A0 label fields = to the egress client ("Router B").
=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0
***************
*** 284,290 ****
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0"Ro= uter B" receives the PATH message, turns the laser ON and tunes=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it to th= e appropriate wavelength (received in the UPSTREAM_LABEL/
! =C2=A0 =C2=A0 =C2=A0 LABEL_SET of = the PATH) and sends out a RESV message upstream.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0The RESV= message received by the ingress client carries a valid
=C2=A0 =C2=A0 =C2=A0 =C2=A0 symmetri= c label in the LABEL object. =C2=A0"Router A" turns on the=
--- 284,290 ----
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0"Ro= uter B" receives the PATH message, turns the laser ON and tunes=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it to th= e appropriate wavelength (received in the UPSTREAM_LABEL/
! =C2=A0 =C2=A0 =C2=A0 LABEL_SET of = the PATH message) and sends a RESV message upstream.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0The RESV= message received by the ingress client carries a valid
=C2=A0 =C2=A0 =C2=A0 =C2=A0 symmetri= c label in the LABEL object. =C2=A0"Router A" turns on the=
***************
*** 306,318 ****
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0After the LSP is= set up, the network may decide to change the
=C2=A0 =C2=A0 =C2=A0wavelength for t= he given LSP.=C2=A0 This could be for a variety of reasons
! =C2=A0 =C2=A0- policy reasons, res= toration within the core, preemption etc.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0In such a scenar= io, if the ingress client receives a changed label
! =C2=A0 =C2=A0via the LABEL object = in a RESV modify, it retunes the laser at the
! =C2=A0 =C2=A0ingress to the new wa= velength.=C2=A0 Similarly, if the egress client
! =C2=A0 =C2=A0receives a changed la= bel via UPSTREAM_LABEL/LABEL_SET in a PATH
! =C2=A0 =C2=A0modify, it retunes th= e laser at the egress to the new wavelength.
=C2=A0=C2=A0
=C2=A0 4.=C2=A0 Acknowledgements
=C2=A0=C2=A0
--- 306,320 ----
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0After the LSP is= set up, the network may decide to change the
=C2=A0 =C2=A0 =C2=A0wavelength for t= he given LSP.=C2=A0 This could be for a variety of reasons
! =C2=A0 =C2=A0including policy reas= ons, restoration within the core, preemption,=C2=A0
! =C2=A0 =C2=A0etc.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0In such a scenar= io, if the ingress client receives a changed label
! =C2=A0 =C2=A0via the LABEL object = in a modified RESV message, it retunes the laser
! =C2=A0 =C2=A0at the ingress to the= new wavelength.=C2=A0 Similarly, if the egress client
! =C2=A0 =C2=A0receives a changed la= bel via UPSTREAM_LABEL/LABEL_SET in a modified=C2=A0
! =C2=A0 =C2=A0PATH message, it retu= nes the laser at the egress to the new
! =C2=A0 =C2=A0wavelength.
=C2=A0=C2=A0
=C2=A0 4.=C2=A0 Acknowledgements
=C2=A0=C2=A0
***************
*** 358,364 ****
=C2=A0 =C2=A0 =C2=A0semantics of a s= pecific field in an existing RSVP object and the
=C2=A0 =C2=A0 =C2=A0corresponding pr= ocedures.=C2=A0 Thus, there are no new security
=C2=A0 =C2=A0 =C2=A0implications rai= sed by this document and the security considerations
! =C2=A0 =C2=A0put together by [RFC3= 473] still applies.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0For a general di= scussion on MPLS and GMPLS related security issues,
=C2=A0 =C2=A0 =C2=A0see the MPLS/GMP= LS security framework [RFC5920].
--- 360,366 ----
=C2=A0 =C2=A0 =C2=A0semantics of a s= pecific field in an existing RSVP object and the
=C2=A0 =C2=A0 =C2=A0corresponding pr= ocedures.=C2=A0 Thus, there are no new security
=C2=A0 =C2=A0 =C2=A0implications rai= sed by this document and the security considerations
! =C2=A0 =C2=A0discussed by [RFC3473= ] still apply.=C2=A0
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0For a general di= scussion on MPLS and GMPLS related security issues,
=C2=A0 =C2=A0 =C2=A0see the MPLS/GMP= LS security framework [RFC5920].

Thanks,
Acee=C2=A0


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


--001a114dfb48c527ba0556748aaa-- From nobody Fri Aug 11 03:38:42 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E121324C2; Fri, 11 Aug 2017 03:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcTmMhwfX5Bc; Fri, 11 Aug 2017 03:38:31 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807A8131D33; Fri, 11 Aug 2017 03:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49155; q=dns/txt; s=iport; t=1502447911; x=1503657511; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6YQH4ep0WilSULo4HAFhm94gJiFBz0oRmLJdjNi9/xE=; b=dnukZvt8LUFhAAwyhXO8OuX8U2qbJVK9nlaEj5gAVdxSwQWSu0Vsj9wa IRjI5y2bGr4h+jKYFoTFRuieMMXIFKaxYkx+PEwV1KHDcZC4tkXpi4jvU nooZEIeCuZtnhi0keKu3UJ/U0BmmiJ9eoTmBT0F9Jp+wM7Mb85j1BlHDu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAABBiI1Z/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWSBFAeOCZANgW53hz+NX4IPAyEBDIUZAhqEYj8YAQIBAQE?= =?us-ascii?q?BAQEBayiFGAEBAQEDAQEhRAcLEAIBCBEDAQIhAQYDAgICHwYLFAkIAgQOBRuJM?= =?us-ascii?q?EwDFRCrPYImhzQNhCEBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyiCAoMvgnM0gld?= =?us-ascii?q?PgWQJgnOCYQWJf44Fh2Y8AodRh3OEdIIPWYESg3KKaIwxiWEBDxA4gQp3FUmEX?= =?us-ascii?q?oI8dgEBiRaBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,357,1498521600"; d="scan'208,217";a="279237003" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Aug 2017 10:38:30 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v7BAcT9e023276 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Aug 2017 10:38:30 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 11 Aug 2017 06:38:28 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 11 Aug 2017 06:38:29 -0400 From: "Acee Lindem (acee)" To: Vishnu Pavan Beeram CC: Routing ADs , Routing Directorate , "teas@ietf.org" , "draft-ietf-teas-network-assigned-upstream-label@ietf.org" Thread-Topic: [Teas] RtgDir review: draft-ietf-teas-network-assigned-upstream-label-06 Thread-Index: AQHTEmxFqVkUzY9NIk6l2Dk4HQbgd6J+9weA Date: Fri, 11 Aug 2017 10:38:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.25.151] Content-Type: multipart/alternative; boundary="_000_D5B2FF77C03E0aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] RtgDir review: draft-ietf-teas-network-assigned-upstream-label-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 10:38:35 -0000 --_000_D5B2FF77C03E0aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF2YW4sDQpJdCBsb29rcyBnb29kIHRvIG1lLiBJIGdlbmVyYWxseSBjYXBpdGFsaXplIHdv cmRzIHRoYXQgZXhwYW5kIGludG8gYWNyb255bXMsIGUuZy4sIExhYmVsIFN3aXRjaGVkIFBhdGgg KExTUCkgYW5kIFdhdmVsZW5ndGggRGl2aXNpb24gTXVsdGlwbGV4aW5nIChXRE0pLiBBbHNvLCB5 b3UgYXJlIG1pc3Npbmcgb25lIGNvbW1hIGluIHNlY3Rpb24gMy4yIOKAkyByZXBsYWNlIOKAnHBy ZWVtcHRpb24gZXRjLuKAnSB3aXRoIOKAnHByZWVtcHRpb24sIGV0Yy7igJ0NClRoYW5rcywNCkFj ZWUNCg0KRnJvbTogVmlzaG51IFBhdmFuIEJlZXJhbSA8dmlzaG51cGF2YW5AZ21haWwuY29tPG1h aWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb20+Pg0KRGF0ZTogRnJpZGF5LCBBdWd1c3QgMTEsIDIw MTcgYXQgMjozNyBBTQ0KVG86IEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNl ZUBjaXNjby5jb20+Pg0KQ2M6IFJvdXRpbmcgQURzIDxydGctYWRzQHRvb2xzLmlldGYub3JnPG1h aWx0bzpydGctYWRzQHRvb2xzLmlldGYub3JnPj4sIFJvdXRpbmcgRGlyZWN0b3JhdGUgPHJ0Zy1k aXJAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmc+PiwgInRlYXNAaWV0Zi5vcmc8bWFp bHRvOnRlYXNAaWV0Zi5vcmc+IiA8dGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4+ LCAiZHJhZnQtaWV0Zi10ZWFzLW5ldHdvcmstYXNzaWduZWQtdXBzdHJlYW0tbGFiZWxAaWV0Zi5v cmc8bWFpbHRvOmRyYWZ0LWlldGYtdGVhcy1uZXR3b3JrLWFzc2lnbmVkLXVwc3RyZWFtLWxhYmVs QGlldGYub3JnPiIgPGRyYWZ0LWlldGYtdGVhcy1uZXR3b3JrLWFzc2lnbmVkLXVwc3RyZWFtLWxh YmVsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRlYXMtbmV0d29yay1hc3NpZ25lZC11cHN0 cmVhbS1sYWJlbEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1RlYXNdIFJ0Z0RpciByZXZpZXc6 IGRyYWZ0LWlldGYtdGVhcy1uZXR3b3JrLWFzc2lnbmVkLXVwc3RyZWFtLWxhYmVsLTA2DQoNCkFj ZWUsIEhpIQ0KDQpNdWNoIFRoYW5rcyBmb3IgdGhlIHJldmlldy4gV2UgKHRoZSBhdXRob3JzKSBq dXN0IHBvc3RlZCBhIG5ldyByZXYgKC0wNykgdG8gYWRkcmVzcyB0aGUgYWxsIHRoZSBuaXRzIGlk ZW50aWZpZWQgYmVsb3cuIFBsZWFzZSBkbyBnbyBvdmVyIHRoZSBkaWZmcyAoIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGVhcy1uZXR3b3JrLWFzc2lnbmVk LXVwc3RyZWFtLWxhYmVsLTA3LnR4dCApIGFuZCBsZXQgdXMga25vdyBpZiB0aGVyZSBhcmUgYW55 IGZ1cnRoZXIgY29uY2VybnMuDQoNClJlZ2FyZHMsDQotUGF2YW4gKG9uIGJlaGFsZiBvZiB0aGUg YXV0aG9ycykNCg0KT24gU2F0LCBKdWwgOCwgMjAxNyBhdCAxOjI5IFBNLCBBY2VlIExpbmRlbSAo YWNlZSkgPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGVs bG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJl dmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byBy ZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3Mg dGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24g c3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUg YXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2UgY29t bWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdv dWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkg b3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2 ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBk cmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtdGVhcy1uZXR3b3JrLWFzc2lnbmVkLXVwc3Ry ZWFtLWxhYmVsLTA2DQpSZXZpZXdlcjogQWNlZSBMaW5kZW0NClJldmlldyBEYXRlOiBKdWx5IDh0 aCwgMjAxNw0KSUVURiBMQyBFbmQgRGF0ZTogQ29tcGxldGVkIOKAkyBTdWJtaXR0ZWQgdG8gSUVT RyBmb3IgcHVibGljYXRpb24NCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQoNClN1 bW1hcnk6DQogICAgVGhpcyBkb2N1bWVudCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1YmxpY2F0 aW9uLCBidXQgaGFzIG5pdHMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBwdWJs aWNhdGlvbi4NCg0KQ29tbWVudHM6DQogICAgVGhlIGRvY3VtZW50IHByb3ZpZGVzIGFuIGV4dGVu c2lvbiB0byBHTVBMUyBSU1ZQIEJpLWRpcmVjdGlvbmFsIExTUCB1cHN0cmVhbSBsYWJlbCBhc3Np Z25tZW50IHdoaWNoDQogICAgc3VwcG9ydHMgbmVnb3RpYXRpb24gb2YgdGhlIHVwc3RyZWFtIGxh YmVsLiBUaGlzIGlzIGFjY29tcGxpc2hlZCBieSB0aGUgdXBzdHJlYW0gcm91dGVyIHNwZWNpZnlp bmcgYQ0KICAgIHNwZWNpYWwgdmFsdWUsIDB4RkZGRkZGRkYsIGluIHRoZSBVUFNUUkVBTV9MQUJF TCBvYmplY3QgYW5kIGEgc2V0IG9mIGNhbmRpZGF0ZSBsYWJlbHMgaW4gdGhlIExBQkVMX1NFVA0K ICAgIG9iamVjdCBvZiB0aGUgUEFUSCBtZXNzYWdlLiBUaGUgZG93bnN0cmVhbSByb3V0ZXIgd2ls bCBzZWxlY3QgYW4gYXBwcm9wcmlhdGUgbGFiZWwgZnJvbSB0aGUgTEFCRUxfU0VUDQogICAgbGFi ZWxzIGFuZCByZXR1cm5zIGl0IGluIHRoZSBMQUJFTCBvYmplY3Qgb2YgdGhlIGNvcnJlc3BvbmRp bmcgUkVTViBtZXNzYWdlLiBUaGUgZG9jdW1lbnQgaXMgZ2VuZXJhbGx5DQogICAgd2VsbCBvcmdh bml6ZWQgYW5kIHdyaXR0ZW4uIFRoZSB0ZWNobmljYWwgc29sdXRpb24gaXMgYm90aCBzdHJhaWdo dC1mb3J3YXJkIGFuZCBjb21wbGV0ZS4NCg0KTWFqb3IgSXNzdWVzOg0KICBObyBtYWpvciBpc3N1 ZXMgZm91bmQuDQoNCk1pbm9yIElzc3VlczoNCiAgTm8gbWlub3IgaXNzdWVzIGZvdW5kLg0KDQpO aXRzOg0KICAgMS4gRXhwYW5kIGFjcm9ueW1zIG9uIGZpcnN0IHVzYWdlLiBGb3IgZXhhbXBsZSwg TFNQIGFuZCBXRE0gYXJlIG5vdCBjb25zaWRlcmVkIOKAnHdlbGwta25vd27igJ0gYXMgZGVmaW5l ZCBpbiBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9tYXRlcmlhbHMvYWJicmV2LmV4cGFuc2lv bi50eHQNCg0KICAgMi4gU3VnZ2VzdGVkIEVkaXRvcmlhbCBDaGFuZ2VzOg0KDQoqKiogZHJhZnQt aWV0Zi10ZWFzLW5ldHdvcmstYXNzaWduZWQtdXBzdHJlYW0tbGFiZWwtMDYudHh0Lm9yaWcNCjIw MTctMDctMDggMTI6MTI6MTguMDAwMDAwMDAwIC0wNDAwDQotLS0gZHJhZnQtaWV0Zi10ZWFzLW5l dHdvcmstYXNzaWduZWQtdXBzdHJlYW0tbGFiZWwtMDYudHh0DQoyMDE3LTA3LTA4IDEyOjU1OjU3 LjAwMDAwMDAwMCAtMDQwMA0KKioqKioqKioqKioqKioqDQoqKiogMTI3LDEzOCAqKioqDQogIDIu ICBVbmFzc2lnbmVkIFVwc3RyZWFtIExhYmVsDQoNCiAgICAgVGhpcyBkb2N1bWVudCBwcm9wb3Nl cyB0aGUgdXNlIG9mIGEgc3BlY2lhbCBsYWJlbCB2YWx1ZSAtDQohICAgICIweEZGRkZGRkZGIiAo Zm9yIGEgNC1ieXRlIGxhYmVsKSAtIHRvIGluZGljYXRlIGFuIFVuYXNzaWduZWQNCiAgICAgVXBz dHJlYW0gTGFiZWwuICBTaW1pbGFyICJhbGwtb25lcyIgcGF0dGVybnMgYXJlIGV4cGVjdGVkIHRv IGJlIHVzZWQNCiAgICAgZm9yIGxhYmVscyBvZiBvdGhlciBzaXplcy4gIFRoZSBwcmVzZW5jZSBv ZiB0aGlzIHZhbHVlIGluIHRoZQ0KICAgICBVUFNUUkVBTV9MQUJFTCBvYmplY3Qgb2YgYSBQQVRI IG1lc3NhZ2UgaW5kaWNhdGVzIHRoYXQgdGhlIHVwc3RyZWFtDQogICAgIG5vZGUgaGFzIG5vdCBh c3NpZ25lZCBhbiB1cHN0cmVhbSBsYWJlbCBvbiBpdHMgb3duIGFuZCBoYXMgcmVxdWVzdGVkDQoh ICAgIHRoZSBkb3duc3RyZWFtIG5vZGUgdG8gcHJvdmlkZSBhIGxhYmVsIHRoYXQgaXQgY2FuIHVz ZSBpbiBib3RoDQogICAgIGZvcndhcmQgYW5kIHJldmVyc2UgZGlyZWN0aW9ucy4gIFRoZSBwcmVz ZW5jZSBvZiB0aGlzIHZhbHVlIGluIHRoZQ0KICAgICBVUFNUUkVBTV9MQUJFTCBvYmplY3Qgb2Yg YSBQQVRIIG1lc3NhZ2UgTVVTVCBhbHNvIGJlIGludGVycHJldGVkIGJ5DQogICAgIHRoZSByZWNl aXZpbmcgbm9kZSBhcyBhIHJlcXVlc3QgdG8gbWFuZGF0ZSBzeW1tZXRyaWMgbGFiZWxzIGZvciB0 aGUNCi0tLSAxMjcsMTM4IC0tLS0NCiAgMi4gIFVuYXNzaWduZWQgVXBzdHJlYW0gTGFiZWwNCg0K ICAgICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRoZSB1c2Ugb2YgYSBzcGVjaWFsIGxhYmVsIHZh bHVlIC0NCiEgICAgIjB4RkZGRkZGRkYiIChmb3IgYSA0LW9jdGV0IGxhYmVsKSAtIHRvIGluZGlj YXRlIGFuIFVuYXNzaWduZWQNCiAgICAgVXBzdHJlYW0gTGFiZWwuICBTaW1pbGFyICJhbGwtb25l cyIgcGF0dGVybnMgYXJlIGV4cGVjdGVkIHRvIGJlIHVzZWQNCiAgICAgZm9yIGxhYmVscyBvZiBv dGhlciBzaXplcy4gIFRoZSBwcmVzZW5jZSBvZiB0aGlzIHZhbHVlIGluIHRoZQ0KICAgICBVUFNU UkVBTV9MQUJFTCBvYmplY3Qgb2YgYSBQQVRIIG1lc3NhZ2UgaW5kaWNhdGVzIHRoYXQgdGhlIHVw c3RyZWFtDQogICAgIG5vZGUgaGFzIG5vdCBhc3NpZ25lZCBhbiB1cHN0cmVhbSBsYWJlbCBvbiBp dHMgb3duIGFuZCBoYXMgcmVxdWVzdGVkDQohICAgIHRoZSBkb3duc3RyZWFtIG5vZGUgdG8gcHJv dmlkZSBhIGxhYmVsIHRoYXQgaXQgY2FuIHVzZSBpbiBib3RoIHRoZQ0KICAgICBmb3J3YXJkIGFu ZCByZXZlcnNlIGRpcmVjdGlvbnMuICBUaGUgcHJlc2VuY2Ugb2YgdGhpcyB2YWx1ZSBpbiB0aGUN CiAgICAgVVBTVFJFQU1fTEFCRUwgb2JqZWN0IG9mIGEgUEFUSCBtZXNzYWdlIE1VU1QgYWxzbyBi ZSBpbnRlcnByZXRlZCBieQ0KICAgICB0aGUgcmVjZWl2aW5nIG5vZGUgYXMgYSByZXF1ZXN0IHRv IG1hbmRhdGUgc3ltbWV0cmljIGxhYmVscyBmb3IgdGhlDQoqKioqKioqKioqKioqKioNCioqKiAx NjAsMTY2ICoqKioNCiAgICAgTGFiZWwgaW4gdGhlIFBBVEggbWVzc2FnZSBldmVuIGFmdGVyIGl0 IHJlY2VpdmVzIGFuIGFwcHJvcHJpYXRlDQogICAgIHN5bW1ldHJpYyBsYWJlbCBpbiB0aGUgUkVT ViBtZXNzYWdlLiAgVGhpcyBpcyBkb25lIHRvIG1ha2Ugc3VyZSB0aGF0DQogICAgIHRoZSBkb3du c3RyZWFtIG5vZGUgd291bGQgcGljayBhIGRpZmZlcmVudCBzeW1tZXRyaWMgbGFiZWwgaWYgYW5k DQohICAgIHdoZW4gaXQgbmVlZHMgdG8gY2hhbmdlIHRoZSBsYWJlbCBhdCBhIGxhdGVyIHBvaW50 IGluIHRpbWUuICBJZiB0aGUNCg0KDQoNCi0tLSAxNjAsMTY2IC0tLS0NCiAgICAgTGFiZWwgaW4g dGhlIFBBVEggbWVzc2FnZSBldmVuIGFmdGVyIGl0IHJlY2VpdmVzIGFuIGFwcHJvcHJpYXRlDQog ICAgIHN5bW1ldHJpYyBsYWJlbCBpbiB0aGUgUkVTViBtZXNzYWdlLiAgVGhpcyBpcyBkb25lIHRv IG1ha2Ugc3VyZSB0aGF0DQogICAgIHRoZSBkb3duc3RyZWFtIG5vZGUgd291bGQgcGljayBhIGRp ZmZlcmVudCBzeW1tZXRyaWMgbGFiZWwgaWYgYW5kDQohICAgIHdoZW4gaXQgbmVlZHMgdG8gY2hh bmdlIHRoZSBsYWJlbCBhdCBhIGxhdGVyIHRpbWUuICBJZiB0aGUNCg0KDQoNCioqKioqKioqKioq KioqKg0KKioqIDIyNiwyMzcgKioqKg0KICBJbnRlcm5ldC1EcmFmdCAgICAgICBOZXR3b3JrIEFz c2lnbmVkIFVwc3RyZWFtLUxhYmVsICAgICAgICAgICBKdW5lIDIwMTcNCg0KDQohICAgIHJvdXRl ciBzZW5kIHNpZ25hbCBpbnRvIHRoZSBvcHRpY2FsIG5ldHdvcmsgdW5sZXNzIGl0IGlzIGF0IHRo ZQ0KICAgICBhcHByb3ByaWF0ZSB3YXZlbGVuZ3RoLiAgSW4gb3RoZXIgd29yZHMsIGhhdmluZyB0 aGUgcm91dGVyIHNlbmQNCiEgICAgc2lnbmFsIHdpdGggYSB3cm9uZyB3YXZlbGVuZ3RoIG1heSBh ZHZlcnNlbHkgaW1wYWN0IGV4aXN0aW5nIG9wdGljYWwNCiAgICAgdHJhaWxzLiAgSWYgdGhlIGNs aWVudHMgZG8gbm90IGhhdmUgZnVsbCB2aXNpYmlsaXR5IGludG8gdGhlIG9wdGljYWwNCiAgICAg bmV0d29yaywgdGhleSBhcmUgbm90IGluIGEgcG9zaXRpb24gdG8gcGljayB0aGUgY29ycmVjdCB3 YXZlbGVuZ3RoDQohICAgIHVwLWZyb250Lg0KDQogICAgIFRoZSByZXN0IG9mIHRoaXMgc2VjdGlv biBleGFtaW5lcyBob3cgdGhlIHByb3RvY29sIG1lY2hhbmlzbSBwcm9wb3NlZA0KICAgICBpbiB0 aGlzIGRvY3VtZW50IGFsbG93cyB0aGUgb3B0aWNhbCBuZXR3b3JrIHRvIHNlbGVjdCBhbmQgY29t bXVuaWNhdGUNCi0tLSAyMjYsMjM3IC0tLS0NCiAgSW50ZXJuZXQtRHJhZnQgICAgICAgTmV0d29y ayBBc3NpZ25lZCBVcHN0cmVhbS1MYWJlbCAgICAgICAgICAgSnVuZSAyMDE3DQoNCg0KISAgICBy b3V0ZXIgc2VuZCB0aGUgc2lnbmFsIGludG8gdGhlIG9wdGljYWwgbmV0d29yayB1bmxlc3MgaXQg aXMgYXQgdGhlDQogICAgIGFwcHJvcHJpYXRlIHdhdmVsZW5ndGguICBJbiBvdGhlciB3b3Jkcywg aGF2aW5nIHRoZSByb3V0ZXIgc2VuZA0KISAgICBzaWduYWxzIHdpdGggYSB3cm9uZyB3YXZlbGVu Z3RoIG1heSBhZHZlcnNlbHkgaW1wYWN0IGV4aXN0aW5nIG9wdGljYWwNCiAgICAgdHJhaWxzLiAg SWYgdGhlIGNsaWVudHMgZG8gbm90IGhhdmUgZnVsbCB2aXNpYmlsaXR5IGludG8gdGhlIG9wdGlj YWwNCiAgICAgbmV0d29yaywgdGhleSBhcmUgbm90IGluIGEgcG9zaXRpb24gdG8gcGljayB0aGUg Y29ycmVjdCB3YXZlbGVuZ3RoDQohICAgIGluIGFkdmFuY2UuDQoNCiAgICAgVGhlIHJlc3Qgb2Yg dGhpcyBzZWN0aW9uIGV4YW1pbmVzIGhvdyB0aGUgcHJvdG9jb2wgbWVjaGFuaXNtIHByb3Bvc2Vk DQogICAgIGluIHRoaXMgZG9jdW1lbnQgYWxsb3dzIHRoZSBvcHRpY2FsIG5ldHdvcmsgdG8gc2Vs ZWN0IGFuZCBjb21tdW5pY2F0ZQ0KKioqKioqKioqKioqKioqDQoqKiogMjcyLDI3OCAqKioqDQoN CiAgICAgbyAgVGhlIGRvd25zdHJlYW0gbm9kZSAoTm9kZSBGKSByZWNlaXZlcyB0aGUgUEFUSCBt ZXNzYWdlLCBjaG9vc2VzDQogICAgICAgIHRoZSBhcHByb3ByaWF0ZSB3YXZlbGVuZ3RoIHZhbHVl cyBhbmQgZm9yd2FyZHMgdGhlbSBpbiBhcHByb3ByaWF0ZQ0KISAgICAgICBsYWJlbCBmaWVsZHMg dG8gdGhlIGVncmVzcyBjbGllbnQgKCJSb3V0ZXIgQiIpDQoNCg0KDQotLS0gMjcyLDI3OCAtLS0t DQoNCiAgICAgbyAgVGhlIGRvd25zdHJlYW0gbm9kZSAoTm9kZSBGKSByZWNlaXZlcyB0aGUgUEFU SCBtZXNzYWdlLCBjaG9vc2VzDQogICAgICAgIHRoZSBhcHByb3ByaWF0ZSB3YXZlbGVuZ3RoIHZh bHVlcyBhbmQgZm9yd2FyZHMgdGhlbSBpbiBhcHByb3ByaWF0ZQ0KISAgICAgICBsYWJlbCBmaWVs ZHMgdG8gdGhlIGVncmVzcyBjbGllbnQgKCJSb3V0ZXIgQiIpLg0KDQoNCg0KKioqKioqKioqKioq KioqDQoqKiogMjg0LDI5MCAqKioqDQoNCiAgICAgbyAgIlJvdXRlciBCIiByZWNlaXZlcyB0aGUg UEFUSCBtZXNzYWdlLCB0dXJucyB0aGUgbGFzZXIgT04gYW5kIHR1bmVzDQogICAgICAgIGl0IHRv IHRoZSBhcHByb3ByaWF0ZSB3YXZlbGVuZ3RoIChyZWNlaXZlZCBpbiB0aGUgVVBTVFJFQU1fTEFC RUwvDQohICAgICAgIExBQkVMX1NFVCBvZiB0aGUgUEFUSCkgYW5kIHNlbmRzIG91dCBhIFJFU1Yg bWVzc2FnZSB1cHN0cmVhbS4NCg0KICAgICBvICBUaGUgUkVTViBtZXNzYWdlIHJlY2VpdmVkIGJ5 IHRoZSBpbmdyZXNzIGNsaWVudCBjYXJyaWVzIGEgdmFsaWQNCiAgICAgICAgc3ltbWV0cmljIGxh YmVsIGluIHRoZSBMQUJFTCBvYmplY3QuICAiUm91dGVyIEEiIHR1cm5zIG9uIHRoZQ0KLS0tIDI4 NCwyOTAgLS0tLQ0KDQogICAgIG8gICJSb3V0ZXIgQiIgcmVjZWl2ZXMgdGhlIFBBVEggbWVzc2Fn ZSwgdHVybnMgdGhlIGxhc2VyIE9OIGFuZCB0dW5lcw0KICAgICAgICBpdCB0byB0aGUgYXBwcm9w cmlhdGUgd2F2ZWxlbmd0aCAocmVjZWl2ZWQgaW4gdGhlIFVQU1RSRUFNX0xBQkVMLw0KISAgICAg ICBMQUJFTF9TRVQgb2YgdGhlIFBBVEggbWVzc2FnZSkgYW5kIHNlbmRzIGEgUkVTViBtZXNzYWdl IHVwc3RyZWFtLg0KDQogICAgIG8gIFRoZSBSRVNWIG1lc3NhZ2UgcmVjZWl2ZWQgYnkgdGhlIGlu Z3Jlc3MgY2xpZW50IGNhcnJpZXMgYSB2YWxpZA0KICAgICAgICBzeW1tZXRyaWMgbGFiZWwgaW4g dGhlIExBQkVMIG9iamVjdC4gICJSb3V0ZXIgQSIgdHVybnMgb24gdGhlDQoqKioqKioqKioqKioq KioNCioqKiAzMDYsMzE4ICoqKioNCg0KICAgICBBZnRlciB0aGUgTFNQIGlzIHNldCB1cCwgdGhl IG5ldHdvcmsgbWF5IGRlY2lkZSB0byBjaGFuZ2UgdGhlDQogICAgIHdhdmVsZW5ndGggZm9yIHRo ZSBnaXZlbiBMU1AuICBUaGlzIGNvdWxkIGJlIGZvciBhIHZhcmlldHkgb2YgcmVhc29ucw0KISAg ICAtIHBvbGljeSByZWFzb25zLCByZXN0b3JhdGlvbiB3aXRoaW4gdGhlIGNvcmUsIHByZWVtcHRp b24gZXRjLg0KDQogICAgIEluIHN1Y2ggYSBzY2VuYXJpbywgaWYgdGhlIGluZ3Jlc3MgY2xpZW50 IHJlY2VpdmVzIGEgY2hhbmdlZCBsYWJlbA0KISAgICB2aWEgdGhlIExBQkVMIG9iamVjdCBpbiBh IFJFU1YgbW9kaWZ5LCBpdCByZXR1bmVzIHRoZSBsYXNlciBhdCB0aGUNCiEgICAgaW5ncmVzcyB0 byB0aGUgbmV3IHdhdmVsZW5ndGguICBTaW1pbGFybHksIGlmIHRoZSBlZ3Jlc3MgY2xpZW50DQoh ICAgIHJlY2VpdmVzIGEgY2hhbmdlZCBsYWJlbCB2aWEgVVBTVFJFQU1fTEFCRUwvTEFCRUxfU0VU IGluIGEgUEFUSA0KISAgICBtb2RpZnksIGl0IHJldHVuZXMgdGhlIGxhc2VyIGF0IHRoZSBlZ3Jl c3MgdG8gdGhlIG5ldyB3YXZlbGVuZ3RoLg0KDQogIDQuICBBY2tub3dsZWRnZW1lbnRzDQoNCi0t LSAzMDYsMzIwIC0tLS0NCg0KICAgICBBZnRlciB0aGUgTFNQIGlzIHNldCB1cCwgdGhlIG5ldHdv cmsgbWF5IGRlY2lkZSB0byBjaGFuZ2UgdGhlDQogICAgIHdhdmVsZW5ndGggZm9yIHRoZSBnaXZl biBMU1AuICBUaGlzIGNvdWxkIGJlIGZvciBhIHZhcmlldHkgb2YgcmVhc29ucw0KISAgICBpbmNs dWRpbmcgcG9saWN5IHJlYXNvbnMsIHJlc3RvcmF0aW9uIHdpdGhpbiB0aGUgY29yZSwgcHJlZW1w dGlvbiwNCiEgICAgZXRjLg0KDQogICAgIEluIHN1Y2ggYSBzY2VuYXJpbywgaWYgdGhlIGluZ3Jl c3MgY2xpZW50IHJlY2VpdmVzIGEgY2hhbmdlZCBsYWJlbA0KISAgICB2aWEgdGhlIExBQkVMIG9i amVjdCBpbiBhIG1vZGlmaWVkIFJFU1YgbWVzc2FnZSwgaXQgcmV0dW5lcyB0aGUgbGFzZXINCiEg ICAgYXQgdGhlIGluZ3Jlc3MgdG8gdGhlIG5ldyB3YXZlbGVuZ3RoLiAgU2ltaWxhcmx5LCBpZiB0 aGUgZWdyZXNzIGNsaWVudA0KISAgICByZWNlaXZlcyBhIGNoYW5nZWQgbGFiZWwgdmlhIFVQU1RS RUFNX0xBQkVML0xBQkVMX1NFVCBpbiBhIG1vZGlmaWVkDQohICAgIFBBVEggbWVzc2FnZSwgaXQg cmV0dW5lcyB0aGUgbGFzZXIgYXQgdGhlIGVncmVzcyB0byB0aGUgbmV3DQohICAgIHdhdmVsZW5n dGguDQoNCiAgNC4gIEFja25vd2xlZGdlbWVudHMNCg0KKioqKioqKioqKioqKioqDQoqKiogMzU4 LDM2NCAqKioqDQogICAgIHNlbWFudGljcyBvZiBhIHNwZWNpZmljIGZpZWxkIGluIGFuIGV4aXN0 aW5nIFJTVlAgb2JqZWN0IGFuZCB0aGUNCiAgICAgY29ycmVzcG9uZGluZyBwcm9jZWR1cmVzLiAg VGh1cywgdGhlcmUgYXJlIG5vIG5ldyBzZWN1cml0eQ0KICAgICBpbXBsaWNhdGlvbnMgcmFpc2Vk IGJ5IHRoaXMgZG9jdW1lbnQgYW5kIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KISAgICBw dXQgdG9nZXRoZXIgYnkgW1JGQzM0NzNdIHN0aWxsIGFwcGxpZXMuDQoNCiAgICAgRm9yIGEgZ2Vu ZXJhbCBkaXNjdXNzaW9uIG9uIE1QTFMgYW5kIEdNUExTIHJlbGF0ZWQgc2VjdXJpdHkgaXNzdWVz LA0KICAgICBzZWUgdGhlIE1QTFMvR01QTFMgc2VjdXJpdHkgZnJhbWV3b3JrIFtSRkM1OTIwXS4N Ci0tLSAzNjAsMzY2IC0tLS0NCiAgICAgc2VtYW50aWNzIG9mIGEgc3BlY2lmaWMgZmllbGQgaW4g YW4gZXhpc3RpbmcgUlNWUCBvYmplY3QgYW5kIHRoZQ0KICAgICBjb3JyZXNwb25kaW5nIHByb2Nl ZHVyZXMuICBUaHVzLCB0aGVyZSBhcmUgbm8gbmV3IHNlY3VyaXR5DQogICAgIGltcGxpY2F0aW9u cyByYWlzZWQgYnkgdGhpcyBkb2N1bWVudCBhbmQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z DQohICAgIGRpc2N1c3NlZCBieSBbUkZDMzQ3M10gc3RpbGwgYXBwbHkuDQoNCiAgICAgRm9yIGEg Z2VuZXJhbCBkaXNjdXNzaW9uIG9uIE1QTFMgYW5kIEdNUExTIHJlbGF0ZWQgc2VjdXJpdHkgaXNz dWVzLA0KICAgICBzZWUgdGhlIE1QTFMvR01QTFMgc2VjdXJpdHkgZnJhbWV3b3JrIFtSRkM1OTIw XS4NCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0BpZXRmLm9yZzxtYWlsdG86 VGVhc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVh cw0KDQoNCg== --_000_D5B2FF77C03E0aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2CE202E629D08E4F8476A290085804A2@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBQYXZhbiwm bmJzcDs8L2Rpdj4NCjxkaXY+SXQgbG9va3MgZ29vZCB0byBtZS4gSSBnZW5lcmFsbHkgY2FwaXRh bGl6ZSB3b3JkcyB0aGF0IGV4cGFuZCBpbnRvIGFjcm9ueW1zLCBlLmcuLCBMYWJlbCBTd2l0Y2hl ZCBQYXRoIChMU1ApIGFuZCBXYXZlbGVuZ3RoIERpdmlzaW9uIE11bHRpcGxleGluZyAoV0RNKS4g QWxzbywgeW91IGFyZSBtaXNzaW5nIG9uZSBjb21tYSBpbiBzZWN0aW9uIDMuMiDigJMgcmVwbGFj ZSDigJxwcmVlbXB0aW9uIGV0Yy7igJ0gd2l0aCDigJxwcmVlbXB0aW9uLCBldGMu4oCdPC9kaXY+ DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpi bGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9u ZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6 IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVt IG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkZyb206IDwvc3Bhbj5WaXNobnUgUGF2YW4gQmVlcmFtICZsdDs8YSBocmVmPSJtYWlsdG86dmlz aG51cGF2YW5AZ21haWwuY29tIj52aXNobnVwYXZhbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+RnJpZGF5LCBBdWd1c3Qg MTEsIDIwMTcgYXQgMjozNyBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20i PmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+Q2M6IDwvc3Bhbj5Sb3V0aW5nIEFEcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1hZHNAdG9v bHMuaWV0Zi5vcmciPnJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0OywgUm91dGluZyBEaXJl Y3RvcmF0ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmciPnJ0Zy1kaXJAaWV0 Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNA aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGVhc0BpZXRmLm9yZyI+dGVh c0BpZXRmLm9yZzwvYT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXRl YXMtbmV0d29yay1hc3NpZ25lZC11cHN0cmVhbS1sYWJlbEBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi10 ZWFzLW5ldHdvcmstYXNzaWduZWQtdXBzdHJlYW0tbGFiZWxAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi10ZWFzLW5ldHdvcmstYXNzaWduZWQtdXBzdHJl YW0tbGFiZWxAaWV0Zi5vcmciPmRyYWZ0LWlldGYtdGVhcy1uZXR3b3JrLWFzc2lnbmVkLXVwc3Ry ZWFtLWxhYmVsQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbVGVhc10gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0 Zi10ZWFzLW5ldHdvcmstYXNzaWduZWQtdXBzdHJlYW0tbGFiZWwtMDY8YnI+DQo8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6 MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2PkFjZWUsIEhpITxicj4NCjxicj4NCjwvZGl2Pg0KTXVjaCBUaGFua3MgZm9yIHRoZSBy ZXZpZXcuIFdlICh0aGUgYXV0aG9ycykganVzdCBwb3N0ZWQgYSBuZXcgcmV2ICgtMDcpIHRvIGFk ZHJlc3MgdGhlIGFsbCB0aGUgbml0cyBpZGVudGlmaWVkIGJlbG93LiBQbGVhc2UgZG8gZ28gb3Zl ciB0aGUgZGlmZnMgKA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi10ZWFzLW5ldHdvcmstYXNzaWduZWQtdXBzdHJlYW0tbGFiZWwtMDcudHh0 Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGVhcy1u ZXR3b3JrLWFzc2lnbmVkLXVwc3RyZWFtLWxhYmVsLTA3LnR4dDwvYT4gKSBhbmQgbGV0IHVzIGtu b3cgaWYgdGhlcmUgYXJlIGFueSBmdXJ0aGVyIGNvbmNlcm5zLg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+UmVnYXJkcyw8L2Rpdj4NCi1QYXZhbiAob24gYmVoYWxmIG9mIHRoZSBhdXRob3JzKTwv ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBTYXQsIEp1bCA4LCAyMDE3IGF0IDE6MjkgUE0sIEFjZWUgTGluZGVtIChhY2VlKSA8 c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIiB0YXJn ZXQ9Il9ibGFuayI+YWNlZUBjaXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3 b3JkLXdyYXA6YnJlYWstd29yZDtjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxNHB4O2ZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fu cy1zZXJpZiI+SGVsbG8sPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNh bnMtc2VyaWYiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxz YW5zLXNlcmlmIj5JIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0 ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3Mg dG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBw YXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVz IG9uDQogc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHBy b3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9u IGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAizxhIGhyZWY9Imh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXIiIHRhcmdl dD0iX2JsYW5rIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy88d2JyPmFyZWEvcnRnL3RyYWMv d2lraS9SdGdEaXI8L2E+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNh bnMtc2VyaWYiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxz YW5zLXNlcmlmIj5BbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUg dXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQg Y29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50 cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRp c2N1c3Npb24NCiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5Eb2N1bWVudDogZHJhZnQtaWV0Zi10ZWFz LW5ldHdvcmstPHdicj5hc3NpZ25lZC11cHN0cmVhbS1sYWJlbC0wNjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5SZXZpZXdlcjogQWNlZSBMaW5kZW08 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+UmV2aWV3 IERhdGU6IEp1bHkgOHRoLCAyMDE3PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpLHNhbnMtc2VyaWYiPklFVEYgTEMgRW5kIERhdGU6IENvbXBsZXRlZCDigJMgU3VibWl0dGVk IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiPkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrPC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5TdW1tYXJ5Ojwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7IFRoaXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwg YnV0IGhhcyBuaXRzIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgcHJpb3IgdG8gcHVibGljYXRp b24uPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNl cmlmIj5Db21tZW50czo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBUaGUgZG9jdW1lbnQgcHJvdmlkZXMgYW4gZXh0ZW5zaW9u IHRvIEdNUExTIFJTVlAgQmktZGlyZWN0aW9uYWwgTFNQIHVwc3RyZWFtIGxhYmVsIGFzc2lnbm1l bnQgd2hpY2gmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBzdXBwb3J0cyBuZWdvdGlhdGlvbiBvZiB0aGUgdXBzdHJl YW0gbGFiZWwuIFRoaXMgaXMgYWNjb21wbGlzaGVkIGJ5IHRoZSB1cHN0cmVhbSByb3V0ZXIgc3Bl Y2lmeWluZyBhJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgc3BlY2lhbCB2YWx1ZSwgMHhGRkZGRkZGRiwgaW4gdGhl IFVQU1RSRUFNX0xBQkVMIG9iamVjdCBhbmQgYSBzZXQgb2YgY2FuZGlkYXRlIGxhYmVscyBpbiB0 aGUgTEFCRUxfU0VUPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgb2JqZWN0IG9mIHRoZSBQQVRIIG1lc3NhZ2UuIFRoZSBkb3du c3RyZWFtIHJvdXRlciB3aWxsIHNlbGVjdCBhbiBhcHByb3ByaWF0ZSBsYWJlbCBmcm9tIHRoZSBM QUJFTF9TRVQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwOyBsYWJlbHMgYW5kIHJldHVybnMgaXQgaW4gdGhlIExBQkVMIG9iamVj dCBvZiB0aGUgY29ycmVzcG9uZGluZyBSRVNWIG1lc3NhZ2UuIFRoZSBkb2N1bWVudCBpcyBnZW5l cmFsbHk8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwOyB3ZWxsIG9yZ2FuaXplZCBhbmQgd3JpdHRlbi4mbmJzcDs8L2ZvbnQ+VGhl IHRlY2huaWNhbCBzb2x1dGlvbiBpcyBib3RoIHN0cmFpZ2h0LWZvcndhcmQgYW5kIGNvbXBsZXRl LiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4N CjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5NYWpv ciBJc3N1ZXM6PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiPiZuYnNwOyBObyBtYWpvciBpc3N1ZXMgZm91bmQuJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsmbmJzcDs8L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+TWlub3IgSXNz dWVzOjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4m bmJzcDsgTm8gbWlub3IgaXNzdWVzIGZvdW5kLiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPk5pdHM6PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsxLiBFeHBh bmQgYWNyb255bXMgb24gZmlyc3QgdXNhZ2UuIEZvciBleGFtcGxlLCBMU1AgYW5kIFdETSBhcmUg bm90IGNvbnNpZGVyZWQg4oCcd2VsbC1rbm93buKAnSBhcyBkZWZpbmVkIGluDQo8YSBocmVmPSJo dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9tYXRlcmlhbHMvYWJicmV2LmV4cGFuc2lvbi50eHQi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnLzx3YnI+bWF0ZXJp YWxzL2FiYnJldi5leHBhbnNpb24udHh0PC9hPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzIuIFN1Z2dlc3RlZCBFZGl0b3Jp YWwgQ2hhbmdlczombmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp LHNhbnMtc2VyaWYiPioqKiBkcmFmdC1pZXRmLXRlYXMtbmV0d29yay08d2JyPmFzc2lnbmVkLXVw c3RyZWFtLWxhYmVsLTA2Ljx3YnI+dHh0Lm9yaWc8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmksc2Fucy1zZXJpZiI+MjAxNy0wNy0wOCAxMjoxMjoxOC4wMDAwMDAwMDAgLTA0 MDA8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+LS0t IGRyYWZ0LWlldGYtdGVhcy1uZXR3b3JrLTx3YnI+YXNzaWduZWQtdXBzdHJlYW0tbGFiZWwtMDYu dHh0PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjIw MTctMDctMDggMTI6NTU6NTcuMDAwMDAwMDAwIC0wNDAwPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPioqKioqKioqKioqKioqKjwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4qKiogMTI3LDEzOCAqKioqPC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAy LiZuYnNwOyBVbmFzc2lnbmVkIFVwc3RyZWFtIExhYmVsPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOzwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwO1Ro aXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhlIHVzZSBvZiBhIHNwZWNpYWwgbGFiZWwgdmFsdWUgLTwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4hICZuYnNw OyAmbmJzcDsmcXVvdDsweEZGRkZGRkZGJnF1b3Q7IChmb3IgYSA0LWJ5dGUgbGFiZWwpIC0gdG8g aW5kaWNhdGUgYW4gVW5hc3NpZ25lZDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2Fs aWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwO1Vwc3RyZWFtIExhYmVsLiZuYnNw OyBTaW1pbGFyICZxdW90O2FsbC1vbmVzJnF1b3Q7IHBhdHRlcm5zIGFyZSBleHBlY3RlZCB0byBi ZSB1c2VkPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9yIGxhYmVscyBvZiBvdGhlciBzaXplcy4mbmJzcDsgVGhl IHByZXNlbmNlIG9mIHRoaXMgdmFsdWUgaW4gdGhlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7VVBTVFJFQU1fTEFC RUwgb2JqZWN0IG9mIGEgUEFUSCBtZXNzYWdlIGluZGljYXRlcyB0aGF0IHRoZSB1cHN0cmVhbTwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7ICZuYnNwO25vZGUgaGFzIG5vdCBhc3NpZ25lZCBhbiB1cHN0cmVhbSBsYWJlbCBvbiBp dHMgb3duIGFuZCBoYXMgcmVxdWVzdGVkPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiPiEgJm5ic3A7ICZuYnNwO3RoZSBkb3duc3RyZWFtIG5vZGUgdG8g cHJvdmlkZSBhIGxhYmVsIHRoYXQgaXQgY2FuIHVzZSBpbiBib3RoPC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9y d2FyZCBhbmQgcmV2ZXJzZSBkaXJlY3Rpb25zLiZuYnNwOyBUaGUgcHJlc2VuY2Ugb2YgdGhpcyB2 YWx1ZSBpbiB0aGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1z ZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtVUFNUUkVBTV9MQUJFTCBvYmplY3Qgb2YgYSBQQVRI IG1lc3NhZ2UgTVVTVCBhbHNvIGJlIGludGVycHJldGVkIGJ5PC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIHJl Y2VpdmluZyBub2RlIGFzIGEgcmVxdWVzdCB0byBtYW5kYXRlIHN5bW1ldHJpYyBsYWJlbHMgZm9y IHRoZTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4t LS0gMTI3LDEzOCAtLS0tPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNh bnMtc2VyaWYiPiZuYnNwOyAyLiZuYnNwOyBVbmFzc2lnbmVkIFVwc3RyZWFtIExhYmVsPC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhlIHVzZSBvZiBhIHNwZWNp YWwgbGFiZWwgdmFsdWUgLTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxz YW5zLXNlcmlmIj4hICZuYnNwOyAmbmJzcDsmcXVvdDsweEZGRkZGRkZGJnF1b3Q7IChmb3IgYSA0 LW9jdGV0IGxhYmVsKSAtIHRvIGluZGljYXRlIGFuIFVuYXNzaWduZWQ8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtV cHN0cmVhbSBMYWJlbC4mbmJzcDsgU2ltaWxhciAmcXVvdDthbGwtb25lcyZxdW90OyBwYXR0ZXJu cyBhcmUgZXhwZWN0ZWQgdG8gYmUgdXNlZDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2ZvciBsYWJlbHMgb2Ygb3Ro ZXIgc2l6ZXMuJm5ic3A7IFRoZSBwcmVzZW5jZSBvZiB0aGlzIHZhbHVlIGluIHRoZTwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwO1VQU1RSRUFNX0xBQkVMIG9iamVjdCBvZiBhIFBBVEggbWVzc2FnZSBpbmRpY2F0ZXMg dGhhdCB0aGUgdXBzdHJlYW08L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtub2RlIGhhcyBub3QgYXNzaWduZWQgYW4g dXBzdHJlYW0gbGFiZWwgb24gaXRzIG93biBhbmQgaGFzIHJlcXVlc3RlZDwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4hICZuYnNwOyAmbmJzcDt0aGUg ZG93bnN0cmVhbSBub2RlIHRvIHByb3ZpZGUgYSBsYWJlbCB0aGF0IGl0IGNhbiB1c2UgaW4gYm90 aCB0aGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDtmb3J3YXJkIGFuZCByZXZlcnNlIGRpcmVjdGlvbnMuJm5ic3A7 IFRoZSBwcmVzZW5jZSBvZiB0aGlzIHZhbHVlIGluIHRoZTwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwO1VQU1RSRUFN X0xBQkVMIG9iamVjdCBvZiBhIFBBVEggbWVzc2FnZSBNVVNUIGFsc28gYmUgaW50ZXJwcmV0ZWQg Ynk8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDt0aGUgcmVjZWl2aW5nIG5vZGUgYXMgYSByZXF1ZXN0IHRvIG1hbmRh dGUgc3ltbWV0cmljIGxhYmVscyBmb3IgdGhlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpLHNhbnMtc2VyaWYiPioqKioqKioqKioqKioqKjwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4qKiogMTYwLDE2NiAqKioqPC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7TGFiZWwgaW4gdGhlIFBBVEggbWVzc2FnZSBldmVuIGFmdGVyIGl0IHJlY2VpdmVzIGFu IGFwcHJvcHJpYXRlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7c3ltbWV0cmljIGxhYmVsIGluIHRoZSBSRVNWIG1l c3NhZ2UuJm5ic3A7IFRoaXMgaXMgZG9uZSB0byBtYWtlIHN1cmUgdGhhdDwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw O3RoZSBkb3duc3RyZWFtIG5vZGUgd291bGQgcGljayBhIGRpZmZlcmVudCBzeW1tZXRyaWMgbGFi ZWwgaWYgYW5kPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiPiEgJm5ic3A7ICZuYnNwO3doZW4gaXQgbmVlZHMgdG8gY2hhbmdlIHRoZSBsYWJlbCBhdCBh IGxhdGVyIHBvaW50IGluIHRpbWUuJm5ic3A7IElmIHRoZTwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOzwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4tLS0gMTYw LDE2NiAtLS0tPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7TGFiZWwgaW4gdGhlIFBBVEggbWVzc2FnZSBldmVuIGFm dGVyIGl0IHJlY2VpdmVzIGFuIGFwcHJvcHJpYXRlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7c3ltbWV0cmljIGxh YmVsIGluIHRoZSBSRVNWIG1lc3NhZ2UuJm5ic3A7IFRoaXMgaXMgZG9uZSB0byBtYWtlIHN1cmUg dGhhdDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBkb3duc3RyZWFtIG5vZGUgd291bGQgcGljayBhIGRpZmZl cmVudCBzeW1tZXRyaWMgbGFiZWwgaWYgYW5kPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpLHNhbnMtc2VyaWYiPiEgJm5ic3A7ICZuYnNwO3doZW4gaXQgbmVlZHMgdG8gY2hh bmdlIHRoZSBsYWJlbCBhdCBhIGxhdGVyIHRpbWUuJm5ic3A7IElmIHRoZTwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDs8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7 PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNw OyZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij4qKioqKioqKioqKioqKio8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiI+KioqIDIyNiwyMzcgKioqKjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgSW50ZXJuZXQtRHJhZnQgJm5ic3A7ICZuYnNw OyAmbmJzcDsgTmV0d29yayBBc3NpZ25lZCBVcHN0cmVhbS1MYWJlbCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IEp1bmUgMjAxNzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiEgJm5ic3A7ICZuYnNwO3JvdXRl ciBzZW5kIHNpZ25hbCBpbnRvIHRoZSBvcHRpY2FsIG5ldHdvcmsgdW5sZXNzIGl0IGlzIGF0IHRo ZTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwO2FwcHJvcHJpYXRlIHdhdmVsZW5ndGguJm5ic3A7IEluIG90aGVyIHdv cmRzLCBoYXZpbmcgdGhlIHJvdXRlciBzZW5kPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpLHNhbnMtc2VyaWYiPiEgJm5ic3A7ICZuYnNwO3NpZ25hbCB3aXRoIGEgd3Jvbmcg d2F2ZWxlbmd0aCBtYXkgYWR2ZXJzZWx5IGltcGFjdCBleGlzdGluZyBvcHRpY2FsPC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7dHJhaWxzLiZuYnNwOyBJZiB0aGUgY2xpZW50cyBkbyBub3QgaGF2ZSBmdWxsIHZpc2li aWxpdHkgaW50byB0aGUgb3B0aWNhbDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2Fs aWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwO25ldHdvcmssIHRoZXkgYXJlIG5v dCBpbiBhIHBvc2l0aW9uIHRvIHBpY2sgdGhlIGNvcnJlY3Qgd2F2ZWxlbmd0aDwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4hICZuYnNwOyAmbmJzcDt1 cC1mcm9udC48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIHJlc3Qgb2YgdGhpcyBzZWN0aW9uIGV4 YW1pbmVzIGhvdyB0aGUgcHJvdG9jb2wgbWVjaGFuaXNtIHByb3Bvc2VkPC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 aW4gdGhpcyBkb2N1bWVudCBhbGxvd3MgdGhlIG9wdGljYWwgbmV0d29yayB0byBzZWxlY3QgYW5k IGNvbW11bmljYXRlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMt c2VyaWYiPi0tLSAyMjYsMjM3IC0tLS08L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNh bGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7IEludGVybmV0LURyYWZ0ICZuYnNwOyAmbmJzcDsgJm5i c3A7IE5ldHdvcmsgQXNzaWduZWQgVXBzdHJlYW0tTGFiZWwgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBKdW5lIDIwMTc8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNh bGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4hICZuYnNwOyAmbmJzcDtyb3V0ZXIgc2Vu ZCB0aGUgc2lnbmFsIGludG8gdGhlIG9wdGljYWwgbmV0d29yayB1bmxlc3MgaXQgaXMgYXQgdGhl PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDsgJm5ic3A7YXBwcm9wcmlhdGUgd2F2ZWxlbmd0aC4mbmJzcDsgSW4gb3RoZXIgd29y ZHMsIGhhdmluZyB0aGUgcm91dGVyIHNlbmQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNhbGlicmksc2Fucy1zZXJpZiI+ISAmbmJzcDsgJm5ic3A7c2lnbmFscyB3aXRoIGEgd3Jvbmcg d2F2ZWxlbmd0aCBtYXkgYWR2ZXJzZWx5IGltcGFjdCBleGlzdGluZyBvcHRpY2FsPC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7dHJhaWxzLiZuYnNwOyBJZiB0aGUgY2xpZW50cyBkbyBub3QgaGF2ZSBmdWxsIHZpc2li aWxpdHkgaW50byB0aGUgb3B0aWNhbDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2Fs aWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwO25ldHdvcmssIHRoZXkgYXJlIG5v dCBpbiBhIHBvc2l0aW9uIHRvIHBpY2sgdGhlIGNvcnJlY3Qgd2F2ZWxlbmd0aDwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4hICZuYnNwOyAmbmJzcDtp biBhZHZhbmNlLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNl cmlmIj4mbmJzcDsmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgcmVzdCBvZiB0aGlzIHNlY3Rpb24g ZXhhbWluZXMgaG93IHRoZSBwcm90b2NvbCBtZWNoYW5pc20gcHJvcG9zZWQ8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDtpbiB0aGlzIGRvY3VtZW50IGFsbG93cyB0aGUgb3B0aWNhbCBuZXR3b3JrIHRvIHNlbGVjdCBh bmQgY29tbXVuaWNhdGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fu cy1zZXJpZiI+KioqKioqKioqKioqKioqPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiPioqKiAyNzIsMjc4ICoqKio8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 byAmbmJzcDtUaGUgZG93bnN0cmVhbSBub2RlIChOb2RlIEYpIHJlY2VpdmVzIHRoZSBQQVRIIG1l c3NhZ2UsIGNob29zZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBhcHByb3ByaWF0ZSB3YXZl bGVuZ3RoIHZhbHVlcyBhbmQgZm9yd2FyZHMgdGhlbSBpbiBhcHByb3ByaWF0ZTwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4hICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGxhYmVsIGZpZWxkcyB0byB0aGUgZWdyZXNzIGNsaWVudCAoJnF1b3Q7Um91dGVyIEIm cXVvdDspPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5z LXNlcmlmIj4mbmJzcDsmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpLHNhbnMtc2VyaWYiPi0tLSAyNzIsMjc4IC0tLS08L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7PC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7byAmbmJzcDtUaGUgZG93bnN0cmVhbSBub2RlIChOb2RlIEYpIHJlY2VpdmVzIHRoZSBQQVRI IG1lc3NhZ2UsIGNob29zZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBhcHByb3ByaWF0ZSB3 YXZlbGVuZ3RoIHZhbHVlcyBhbmQgZm9yd2FyZHMgdGhlbSBpbiBhcHByb3ByaWF0ZTwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4hICZuYnNwOyAmbmJz cDsgJm5ic3A7IGxhYmVsIGZpZWxkcyB0byB0aGUgZWdyZXNzIGNsaWVudCAoJnF1b3Q7Um91dGVy IEImcXVvdDspLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNl cmlmIj4mbmJzcDsmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4qKioqKioqKioqKioqKio8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+KioqIDI4NCwyOTAgKioqKjwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsmbmJz cDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDtvICZuYnNwOyZxdW90O1JvdXRlciBCJnF1b3Q7IHJlY2VpdmVzIHRo ZSBQQVRIIG1lc3NhZ2UsIHR1cm5zIHRoZSBsYXNlciBPTiBhbmQgdHVuZXM8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGl0IHRvIHRoZSBhcHByb3ByaWF0ZSB3YXZlbGVuZ3RoIChyZWNlaXZlZCBpbiB0 aGUgVVBTVFJFQU1fTEFCRUwvPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp LHNhbnMtc2VyaWYiPiEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTEFCRUxfU0VUIG9mIHRoZSBQQVRI KSBhbmQgc2VuZHMgb3V0IGEgUkVTViBtZXNzYWdlIHVwc3RyZWFtLjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDs8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDtvICZuYnNwO1RoZSBSRVNWIG1lc3NhZ2UgcmVjZWl2ZWQgYnkgdGhlIGluZ3Jlc3MgY2xp ZW50IGNhcnJpZXMgYSB2YWxpZDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJy aSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc3ltbWV0cmljIGxhYmVs IGluIHRoZSBMQUJFTCBvYmplY3QuICZuYnNwOyZxdW90O1JvdXRlciBBJnF1b3Q7IHR1cm5zIG9u IHRoZTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4t LS0gMjg0LDI5MCAtLS0tPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2Fs aWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwO28gJm5ic3A7JnF1b3Q7Um91dGVy IEImcXVvdDsgcmVjZWl2ZXMgdGhlIFBBVEggbWVzc2FnZSwgdHVybnMgdGhlIGxhc2VyIE9OIGFu ZCB0dW5lczwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaXQgdG8gdGhlIGFwcHJvcHJpYXRlIHdhdmVs ZW5ndGggKHJlY2VpdmVkIGluIHRoZSBVUFNUUkVBTV9MQUJFTC88L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+ISAmbmJzcDsgJm5ic3A7ICZuYnNwOyBM QUJFTF9TRVQgb2YgdGhlIFBBVEggbWVzc2FnZSkgYW5kIHNlbmRzIGEgUkVTViBtZXNzYWdlIHVw c3RyZWFtLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtvICZuYnNwO1RoZSBSRVNWIG1lc3NhZ2UgcmVj ZWl2ZWQgYnkgdGhlIGluZ3Jlc3MgY2xpZW50IGNhcnJpZXMgYSB2YWxpZDwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgc3ltbWV0cmljIGxhYmVsIGluIHRoZSBMQUJFTCBvYmplY3QuICZuYnNwOyZxdW90 O1JvdXRlciBBJnF1b3Q7IHR1cm5zIG9uIHRoZTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4qKioqKioqKioqKioqKio8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+KioqIDMwNiwzMTggKioqKjwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDs8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDtBZnRlciB0aGUgTFNQIGlzIHNldCB1cCwgdGhlIG5ldHdvcmsgbWF5IGRl Y2lkZSB0byBjaGFuZ2UgdGhlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp LHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7d2F2ZWxlbmd0aCBmb3IgdGhlIGdpdmVu IExTUC4mbmJzcDsgVGhpcyBjb3VsZCBiZSBmb3IgYSB2YXJpZXR5IG9mIHJlYXNvbnM8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+ISAmbmJzcDsgJm5i c3A7LSBwb2xpY3kgcmVhc29ucywgcmVzdG9yYXRpb24gd2l0aGluIHRoZSBjb3JlLCBwcmVlbXB0 aW9uIGV0Yy48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7SW4gc3VjaCBhIHNjZW5hcmlvLCBpZiB0aGUg aW5ncmVzcyBjbGllbnQgcmVjZWl2ZXMgYSBjaGFuZ2VkIGxhYmVsPC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiEgJm5ic3A7ICZuYnNwO3ZpYSB0aGUg TEFCRUwgb2JqZWN0IGluIGEgUkVTViBtb2RpZnksIGl0IHJldHVuZXMgdGhlIGxhc2VyIGF0IHRo ZTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4hICZu YnNwOyAmbmJzcDtpbmdyZXNzIHRvIHRoZSBuZXcgd2F2ZWxlbmd0aC4mbmJzcDsgU2ltaWxhcmx5 LCBpZiB0aGUgZWdyZXNzIGNsaWVudDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2Fs aWJyaSxzYW5zLXNlcmlmIj4hICZuYnNwOyAmbmJzcDtyZWNlaXZlcyBhIGNoYW5nZWQgbGFiZWwg dmlhIFVQU1RSRUFNX0xBQkVML0xBQkVMX1NFVCBpbiBhIFBBVEg8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+ISAmbmJzcDsgJm5ic3A7bW9kaWZ5LCBp dCByZXR1bmVzIHRoZSBsYXNlciBhdCB0aGUgZWdyZXNzIHRvIHRoZSBuZXcgd2F2ZWxlbmd0aC48 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7 Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYi PiZuYnNwOyA0LiZuYnNwOyBBY2tub3dsZWRnZW1lbnRzPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOzwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4tLS0gMzA2LDMyMCAtLS0tPC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwO0FmdGVyIHRoZSBMU1AgaXMgc2V0IHVwLCB0aGUgbmV0d29yayBtYXkg ZGVjaWRlIHRvIGNoYW5nZSB0aGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDt3YXZlbGVuZ3RoIGZvciB0aGUgZ2l2 ZW4gTFNQLiZuYnNwOyBUaGlzIGNvdWxkIGJlIGZvciBhIHZhcmlldHkgb2YgcmVhc29uczwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4hICZuYnNwOyAm bmJzcDtpbmNsdWRpbmcgcG9saWN5IHJlYXNvbnMsIHJlc3RvcmF0aW9uIHdpdGhpbiB0aGUgY29y ZSwgcHJlZW1wdGlvbiwmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+ISAmbmJzcDsgJm5ic3A7ZXRjLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtJ biBzdWNoIGEgc2NlbmFyaW8sIGlmIHRoZSBpbmdyZXNzIGNsaWVudCByZWNlaXZlcyBhIGNoYW5n ZWQgbGFiZWw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+ISAmbmJzcDsgJm5ic3A7dmlhIHRoZSBMQUJFTCBvYmplY3QgaW4gYSBtb2RpZmllZCBSRVNW IG1lc3NhZ2UsIGl0IHJldHVuZXMgdGhlIGxhc2VyPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiEgJm5ic3A7ICZuYnNwO2F0IHRoZSBpbmdyZXNzIHRv IHRoZSBuZXcgd2F2ZWxlbmd0aC4mbmJzcDsgU2ltaWxhcmx5LCBpZiB0aGUgZWdyZXNzIGNsaWVu dDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4hICZu YnNwOyAmbmJzcDtyZWNlaXZlcyBhIGNoYW5nZWQgbGFiZWwgdmlhIFVQU1RSRUFNX0xBQkVML0xB QkVMX1NFVCBpbiBhIG1vZGlmaWVkJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpLHNhbnMtc2VyaWYiPiEgJm5ic3A7ICZuYnNwO1BBVEggbWVzc2FnZSwgaXQgcmV0 dW5lcyB0aGUgbGFzZXIgYXQgdGhlIGVncmVzcyB0byB0aGUgbmV3PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiEgJm5ic3A7ICZuYnNwO3dhdmVsZW5n dGguPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNl cmlmIj4mbmJzcDsgNC4mbmJzcDsgQWNrbm93bGVkZ2VtZW50czwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDs8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+KioqKioqKioqKioqKioqPC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPioqKiAzNTgs MzY0ICoqKio8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtzZW1hbnRpY3Mgb2YgYSBzcGVjaWZpYyBmaWVsZCBpbiBh biBleGlzdGluZyBSU1ZQIG9iamVjdCBhbmQgdGhlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Y29ycmVzcG9uZGlu ZyBwcm9jZWR1cmVzLiZuYnNwOyBUaHVzLCB0aGVyZSBhcmUgbm8gbmV3IHNlY3VyaXR5PC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDsgJm5ic3A7aW1wbGljYXRpb25zIHJhaXNlZCBieSB0aGlzIGRvY3VtZW50IGFuZCB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+ISAmbmJzcDsgJm5ic3A7cHV0IHRvZ2V0aGVyIGJ5IFtSRkMzNDczXSBz dGlsbCBhcHBsaWVzLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5z LXNlcmlmIj4mbmJzcDsmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtGb3IgYSBnZW5lcmFsIGRpc2N1c3Np b24gb24gTVBMUyBhbmQgR01QTFMgcmVsYXRlZCBzZWN1cml0eSBpc3N1ZXMsPC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7c2VlIHRoZSBNUExTL0dNUExTIHNlY3VyaXR5IGZyYW1ld29yayBbUkZDNTkyMF0uPC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPi0tLSAzNjAsMzY2 IC0tLS08L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDtzZW1hbnRpY3Mgb2YgYSBzcGVjaWZpYyBmaWVsZCBpbiBhbiBl eGlzdGluZyBSU1ZQIG9iamVjdCBhbmQgdGhlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Y29ycmVzcG9uZGluZyBw cm9jZWR1cmVzLiZuYnNwOyBUaHVzLCB0aGVyZSBhcmUgbm8gbmV3IHNlY3VyaXR5PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7aW1wbGljYXRpb25zIHJhaXNlZCBieSB0aGlzIGRvY3VtZW50IGFuZCB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiI+ISAmbmJzcDsgJm5ic3A7ZGlzY3Vzc2VkIGJ5IFtSRkMzNDczXSBzdGlsbCBh cHBseS4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1z ZXJpZiI+Jm5ic3A7Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp LHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Rm9yIGEgZ2VuZXJhbCBkaXNjdXNzaW9u IG9uIE1QTFMgYW5kIEdNUExTIHJlbGF0ZWQgc2VjdXJpdHkgaXNzdWVzLDwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw O3NlZSB0aGUgTVBMUy9HTVBMUyBzZWN1cml0eSBmcmFtZXdvcmsgW1JGQzU5MjBdLjwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5BY2VlJm5ic3A7 PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpD YWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19f PGJyPg0KVGVhcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VGVhc0BpZXRmLm9y ZyI+VGVhc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RlYXMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5saXN0aW5mby90ZWFzPC9hPjxicj4NCjxi cj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D5B2FF77C03E0aceeciscocom_-- From nobody Fri Aug 11 03:56:39 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDF2132631; Fri, 11 Aug 2017 03:56:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150244899254.24482.3885236199271285888@ietfa.amsl.com> Date: Fri, 11 Aug 2017 03:56:32 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-network-assigned-upstream-label-08.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 10:56:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Network Assigned Upstream-Label Authors : Xian Zhang Vishnu Pavan Beeram Igor Bryskin Daniele Ceccarelli Oscar Gonzalez de Dios Filename : draft-ietf-teas-network-assigned-upstream-label-08.txt Pages : 8 Date : 2017-08-11 Abstract: This document discusses a Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP- TE) mechanism that enables the network to assign an upstream label for a bidirectional Label Switched Path (LSP). This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFC3473. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-network-assigned-upstream-label/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-network-assigned-upstream-label-08 https://datatracker.ietf.org/doc/html/draft-ietf-teas-network-assigned-upstream-label-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-network-assigned-upstream-label-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 11 04:00:26 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828A8132641; Fri, 11 Aug 2017 04:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhCKH663Qn69; Fri, 11 Aug 2017 04:00:18 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 E62EB1325E2; Fri, 11 Aug 2017 04:00:17 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 80so13697887uas.0; Fri, 11 Aug 2017 04:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j+5FuMGLapQU8S26O0oDZCPPP6eI4vQGB8/sHMB4FnQ=; b=IQkyN7Bh1Y8slYiHSGhra2cfIokHUiwtn/LHNN8uhrk51zUOdN5enS7lglOnI3sg30 UhOcjz79+zyrcX2O5FrpLL2ZZRsZ9bkZ+6OoTj32hXLfw4CX/wqEEnhlTwoKgmAjuWm9 UTWo1fnoVqVjEtd8vzar8O+3hWdPWXO1PbBroD/XWT+7fWJk1wA4lKMhBDKYbQRTf5t5 LThK2wTY9VdEEvRzvSL4wNj963oWbEFBE1KVWDN8+3OCZd/+MpqPfw7qFpV+apsYiPvE YQRM9/Dp4TjLCJSc9/hWfdHarMRgMRdfC/T9IeTl/xK09TMx6qNeg3FdjBPpxjkVL6OL N+XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j+5FuMGLapQU8S26O0oDZCPPP6eI4vQGB8/sHMB4FnQ=; b=Sc0TAj0wh+5fSl8D8eGQwKostDqLAc8ojxupUmi+gmrLYy/4JBQojwZJg3Ex9IT+CL TaKeOB2UcHxGa+Uq8JF/ZM5JPqKlXKCms2VQiG4rloHqHHC60RjgHmyorsTB8vMEXt8c K4xCH6JaFBsNrNNHDDfg2FBHX/OB4ST1VmDW76azaXPUraCIfHuxs3SY6AgksOmHvkGA V19u0kX4dBEf8HR0jI6xu6prYyjnUxLeY7BDoB2QwVFJfURv0BpxxAZfrNnBfD7t+6TE 0LysgZ6HjRJk1bkkj5aUrU28GmQ2yTERxVWS8othQCaPEbJ8DdDDFLu2qOVDfIgXyEXk jB8Q== X-Gm-Message-State: AHYfb5g1z632HSTsnCAS+LABPBftUPoVvMWj39190LW2A3ZKY5kKq6Fe DTXwW5LYpRR9Ki37+7EdBEFRmgl+Dw== X-Received: by 10.176.84.221 with SMTP id q29mr9487354uaa.173.1502449215467; Fri, 11 Aug 2017 04:00:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.149.139 with HTTP; Fri, 11 Aug 2017 04:00:14 -0700 (PDT) In-Reply-To: References: From: Vishnu Pavan Beeram Date: Fri, 11 Aug 2017 07:00:14 -0400 Message-ID: To: "Acee Lindem (acee)" Cc: Routing ADs , Routing Directorate , "teas@ietf.org" , "draft-ietf-teas-network-assigned-upstream-label@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1b10cec7f9c3055678375e" Archived-At: Subject: Re: [Teas] RtgDir review: draft-ietf-teas-network-assigned-upstream-label-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 11:00:25 -0000 --94eb2c1b10cec7f9c3055678375e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Acee, Hi! Rev -08 takes care of these two items (I didn't feel like keeping these pending). https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-network-assigned-upstre= am-label-08 Regards, -Pavan On Fri, Aug 11, 2017 at 6:38 AM, Acee Lindem (acee) wrote: > Hi Pavan, > It looks good to me. I generally capitalize words that expand into > acronyms, e.g., Label Switched Path (LSP) and Wavelength Division > Multiplexing (WDM). Also, you are missing one comma in section 3.2 =E2=80= =93 > replace =E2=80=9Cpreemption etc.=E2=80=9D with =E2=80=9Cpreemption, etc.= =E2=80=9D > Thanks, > Acee > > From: Vishnu Pavan Beeram > Date: Friday, August 11, 2017 at 2:37 AM > To: Acee Lindem > Cc: Routing ADs , Routing Directorate < > rtg-dir@ietf.org>, "teas@ietf.org" , " > draft-ietf-teas-network-assigned-upstream-label@ietf.org" < > draft-ietf-teas-network-assigned-upstream-label@ietf.org> > Subject: Re: [Teas] RtgDir review: draft-ietf-teas-network- > assigned-upstream-label-06 > > Acee, Hi! > > Much Thanks for the review. We (the authors) just posted a new rev (-07) > to address the all the nits identified below. Please do go over the diffs= ( > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas- > network-assigned-upstream-label-07.txt ) and let us know if there are any > further concerns. > > Regards, > -Pavan (on behalf of the authors) > > On Sat, Jul 8, 2017 at 1:29 PM, Acee Lindem (acee) wrote= : > >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or routing-related >> drafts as they pass through IETF last call and IESG review, and sometime= s >> on special request. The purpose of the review is to provide assistance t= o >> the Routing ADs. For more information about the Routing Directorate, ple= ase >> see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing ADs, it >> would be helpful if you could consider them along with any other IETF La= st >> Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >> >> Document: draft-ietf-teas-network-assigned-upstream-label-06 >> Reviewer: Acee Lindem >> Review Date: July 8th, 2017 >> IETF LC End Date: Completed =E2=80=93 Submitted to IESG for publication >> Intended Status: Standards Track >> >> Summary: >> This document is basically ready for publication, but has nits that >> should be considered prior to publication. >> >> Comments: >> The document provides an extension to GMPLS RSVP Bi-directional LSP >> upstream label assignment which >> supports negotiation of the upstream label. This is accomplished by >> the upstream router specifying a >> special value, 0xFFFFFFFF, in the UPSTREAM_LABEL object and a set of >> candidate labels in the LABEL_SET >> object of the PATH message. The downstream router will select an >> appropriate label from the LABEL_SET >> labels and returns it in the LABEL object of the corresponding RESV >> message. The document is generally >> well organized and written. The technical solution is both >> straight-forward and complete. >> >> Major Issues: >> No major issues found. >> >> Minor Issues: >> No minor issues found. >> >> Nits: >> 1. Expand acronyms on first usage. For example, LSP and WDM are not >> considered =E2=80=9Cwell-known=E2=80=9D as defined in https://www.rfc-ed= itor.org/mat >> erials/abbrev.expansion.txt >> >> 2. Suggested Editorial Changes: >> >> *** draft-ietf-teas-network-assigned-upstream-label-06.txt.orig >> 2017-07-08 12:12:18.000000000 -0400 >> --- draft-ietf-teas-network-assigned-upstream-label-06.txt >> 2017-07-08 12:55:57.000000000 -0400 >> *************** >> *** 127,138 **** >> 2. Unassigned Upstream Label >> >> This document proposes the use of a special label value - >> ! "0xFFFFFFFF" (for a 4-byte label) - to indicate an Unassigned >> Upstream Label. Similar "all-ones" patterns are expected to be use= d >> for labels of other sizes. The presence of this value in the >> UPSTREAM_LABEL object of a PATH message indicates that the upstream >> node has not assigned an upstream label on its own and has requeste= d >> ! the downstream node to provide a label that it can use in both >> forward and reverse directions. The presence of this value in the >> UPSTREAM_LABEL object of a PATH message MUST also be interpreted by >> the receiving node as a request to mandate symmetric labels for the >> --- 127,138 ---- >> 2. Unassigned Upstream Label >> >> This document proposes the use of a special label value - >> ! "0xFFFFFFFF" (for a 4-octet label) - to indicate an Unassigned >> Upstream Label. Similar "all-ones" patterns are expected to be use= d >> for labels of other sizes. The presence of this value in the >> UPSTREAM_LABEL object of a PATH message indicates that the upstream >> node has not assigned an upstream label on its own and has requeste= d >> ! the downstream node to provide a label that it can use in both the >> forward and reverse directions. The presence of this value in the >> UPSTREAM_LABEL object of a PATH message MUST also be interpreted by >> the receiving node as a request to mandate symmetric labels for the >> *************** >> *** 160,166 **** >> Label in the PATH message even after it receives an appropriate >> symmetric label in the RESV message. This is done to make sure tha= t >> the downstream node would pick a different symmetric label if and >> ! when it needs to change the label at a later point in time. If the >> >> >> >> --- 160,166 ---- >> Label in the PATH message even after it receives an appropriate >> symmetric label in the RESV message. This is done to make sure tha= t >> the downstream node would pick a different symmetric label if and >> ! when it needs to change the label at a later time. If the >> >> >> >> *************** >> *** 226,237 **** >> Internet-Draft Network Assigned Upstream-Label June 20= 17 >> >> >> ! router send signal into the optical network unless it is at the >> appropriate wavelength. In other words, having the router send >> ! signal with a wrong wavelength may adversely impact existing optica= l >> trails. If the clients do not have full visibility into the optica= l >> network, they are not in a position to pick the correct wavelength >> ! up-front. >> >> The rest of this section examines how the protocol mechanism propos= ed >> in this document allows the optical network to select and communica= te >> --- 226,237 ---- >> Internet-Draft Network Assigned Upstream-Label June 20= 17 >> >> >> ! router send the signal into the optical network unless it is at the >> appropriate wavelength. In other words, having the router send >> ! signals with a wrong wavelength may adversely impact existing optic= al >> trails. If the clients do not have full visibility into the optica= l >> network, they are not in a position to pick the correct wavelength >> ! in advance. >> >> The rest of this section examines how the protocol mechanism propos= ed >> in this document allows the optical network to select and communica= te >> *************** >> *** 272,278 **** >> >> o The downstream node (Node F) receives the PATH message, chooses >> the appropriate wavelength values and forwards them in appropria= te >> ! label fields to the egress client ("Router B") >> >> >> >> --- 272,278 ---- >> >> o The downstream node (Node F) receives the PATH message, chooses >> the appropriate wavelength values and forwards them in appropria= te >> ! label fields to the egress client ("Router B"). >> >> >> >> *************** >> *** 284,290 **** >> >> o "Router B" receives the PATH message, turns the laser ON and tun= es >> it to the appropriate wavelength (received in the UPSTREAM_LABEL= / >> ! LABEL_SET of the PATH) and sends out a RESV message upstream. >> >> o The RESV message received by the ingress client carries a valid >> symmetric label in the LABEL object. "Router A" turns on the >> --- 284,290 ---- >> >> o "Router B" receives the PATH message, turns the laser ON and tun= es >> it to the appropriate wavelength (received in the UPSTREAM_LABEL= / >> ! LABEL_SET of the PATH message) and sends a RESV message upstream= . >> >> o The RESV message received by the ingress client carries a valid >> symmetric label in the LABEL object. "Router A" turns on the >> *************** >> *** 306,318 **** >> >> After the LSP is set up, the network may decide to change the >> wavelength for the given LSP. This could be for a variety of reaso= ns >> ! - policy reasons, restoration within the core, preemption etc. >> >> In such a scenario, if the ingress client receives a changed label >> ! via the LABEL object in a RESV modify, it retunes the laser at the >> ! ingress to the new wavelength. Similarly, if the egress client >> ! receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH >> ! modify, it retunes the laser at the egress to the new wavelength. >> >> 4. Acknowledgements >> >> --- 306,320 ---- >> >> After the LSP is set up, the network may decide to change the >> wavelength for the given LSP. This could be for a variety of reaso= ns >> ! including policy reasons, restoration within the core, preemption, >> ! etc. >> >> In such a scenario, if the ingress client receives a changed label >> ! via the LABEL object in a modified RESV message, it retunes the las= er >> ! at the ingress to the new wavelength. Similarly, if the egress >> client >> ! receives a changed label via UPSTREAM_LABEL/LABEL_SET in a modified >> ! PATH message, it retunes the laser at the egress to the new >> ! wavelength. >> >> 4. Acknowledgements >> >> *************** >> *** 358,364 **** >> semantics of a specific field in an existing RSVP object and the >> corresponding procedures. Thus, there are no new security >> implications raised by this document and the security consideration= s >> ! put together by [RFC3473] still applies. >> >> For a general discussion on MPLS and GMPLS related security issues, >> see the MPLS/GMPLS security framework [RFC5920]. >> --- 360,366 ---- >> semantics of a specific field in an existing RSVP object and the >> corresponding procedures. Thus, there are no new security >> implications raised by this document and the security consideration= s >> ! discussed by [RFC3473] still apply. >> >> For a general discussion on MPLS and GMPLS related security issues, >> see the MPLS/GMPLS security framework [RFC5920]. >> >> Thanks, >> Acee >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >> > --94eb2c1b10cec7f9c3055678375e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Acee, Hi!

Rev -08 takes care of these two= items (I didn't feel like keeping these pending).

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-network-assi= gned-upstream-label-08

Regards,
-Pavan
<= div class=3D"gmail_extra">
On Fri, Aug 11, 20= 17 at 6:38 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
Hi Pavan,=C2=A0
It looks good to me. I generally capitalize words that expand into acr= onyms, e.g., Label Switched Path (LSP) and Wavelength Division Multiplexing= (WDM). Also, you are missing one comma in section 3.2 =E2=80=93 replace = =E2=80=9Cpreemption etc.=E2=80=9D with =E2=80=9Cpreemption, etc.=E2=80=9D
Thanks,
Acee=C2=A0

From: Vishnu Pavan Beeram <vishnupavan@gmail.com= >
Date: Friday, August 11, 2017 at 2:= 37 AM
To: Acee Lindem <acee@cisco.com>
Cc: Routing ADs <rtg-ads@tools.ietf.org>= , Routing Directorate <rtg-dir@ietf.org>, "teas@ietf.org" <teas@ietf.org>, "draft-ietf-teas-network-assigned-upstream-la= bel@ietf.org" <draft-ietf-teas-network-= assigned-upstream-label@ietf.org>
Subject: Re: [Teas] RtgDir review: = draft-ietf-teas-network-assigned-upstream-label-06

Acee, Hi!

Much Thanks for the review. We (the authors) just posted a new rev (-07) to= address the all the nits identified below. Please do go over the diffs ( https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-network-ass= igned-upstream-label-07.txt ) and let us know if there are any fur= ther concerns.

Regards,
-Pavan (on behalf of the authors)

On Sat, Jul 8, 2017 at 1:29 PM, Acee Lindem (ace= e) <acee@cisco.com&= gt; wrote:
Hello,

I have been selected as the Routing = Directorate reviewer for this draft. The Routing Directorate seeks to revie= w all routing or routing-related drafts as they pass through IETF last call= and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the= Routing ADs. For more information about the Routing Directorate, please se= e =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDi= r

Although these comments are primaril= y for the use of the Routing ADs, it would be helpful if you could consider= them along with any other IETF Last Call comments that you receive, and st= rive to resolve them through discussion or by updating the draft.

Document: draft-ietf-teas-network-as= signed-upstream-label-06
Reviewer: Acee Lindem
Review Date: July 8th, 2017
IETF LC End Date: Completed =E2=80= =93 Submitted to IESG for publication
Intended Status: Standards Track

Summary:
=C2=A0 =C2=A0 This document is basic= ally ready for publication, but has nits that should be considered prior to= publication.
=C2=A0=C2=A0
Comments:
=C2=A0 =C2=A0 The document provides = an extension to GMPLS RSVP Bi-directional LSP upstream label assignment whi= ch=C2=A0
=C2=A0 =C2=A0 supports negotiation o= f the upstream label. This is accomplished by the upstream router specifyin= g a=C2=A0
=C2=A0 =C2=A0 special value, 0xFFFFF= FFF, in the UPSTREAM_LABEL object and a set of candidate labels in the LABE= L_SET
=C2=A0 =C2=A0 object of the PATH mes= sage. The downstream router will select an appropriate label from the LABEL= _SET
=C2=A0 =C2=A0 labels and returns it = in the LABEL object of the corresponding RESV message. The document is gene= rally
=C2=A0 =C2=A0 well organized and wri= tten.=C2=A0The technical solution is both straight-forward and compl= ete.=C2=A0

Major Issues:
=C2=A0 No major issues found.=C2=A0<= /font>
=C2=A0 =C2=A0=C2=A0
Minor Issues:
=C2=A0 No minor issues found.=C2=A0<= /font>
=C2=A0 =C2=A0
Nits:
=C2=A0 =C2=A01. Expand acronyms on f= irst usage. For example, LSP and WDM are not considered =E2=80=9Cwell-known= =E2=80=9D as defined in https://www.rfc-editor.org/materials/abbrev.expansion.txt

=C2=A0 =C2=A02. Suggested Editorial = Changes:=C2=A0

*** draft-ietf-teas-network-assigned-upstream-label-06.txt.orig
2017-07-08 12:12:18.000000000 -0400<= /font>
--- draft-ietf-teas-network-assigned-upstream-label-06.txt
2017-07-08 12:55:57.000000000 -0400<= /font>
***************
*** 127,138 ****
=C2=A0 2.=C2=A0 Unassigned Upstream = Label
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0This document pr= oposes the use of a special label value -
! =C2=A0 =C2=A0"0xFFFFFFFF"= ; (for a 4-byte label) - to indicate an Unassigned
=C2=A0 =C2=A0 =C2=A0Upstream Label.= =C2=A0 Similar "all-ones" patterns are expected to be used=
=C2=A0 =C2=A0 =C2=A0for labels of ot= her sizes.=C2=A0 The presence of this value in the
=C2=A0 =C2=A0 =C2=A0UPSTREAM_LABEL o= bject of a PATH message indicates that the upstream
=C2=A0 =C2=A0 =C2=A0node has not ass= igned an upstream label on its own and has requested
! =C2=A0 =C2=A0the downstream node t= o provide a label that it can use in both
=C2=A0 =C2=A0 =C2=A0forward and reve= rse directions.=C2=A0 The presence of this value in the
=C2=A0 =C2=A0 =C2=A0UPSTREAM_LABEL o= bject of a PATH message MUST also be interpreted by
=C2=A0 =C2=A0 =C2=A0the receiving no= de as a request to mandate symmetric labels for the
--- 127,138 ----
=C2=A0 2.=C2=A0 Unassigned Upstream = Label
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0This document pr= oposes the use of a special label value -
! =C2=A0 =C2=A0"0xFFFFFFFF"= ; (for a 4-octet label) - to indicate an Unassigned
=C2=A0 =C2=A0 =C2=A0Upstream Label.= =C2=A0 Similar "all-ones" patterns are expected to be used=
=C2=A0 =C2=A0 =C2=A0for labels of ot= her sizes.=C2=A0 The presence of this value in the
=C2=A0 =C2=A0 =C2=A0UPSTREAM_LABEL o= bject of a PATH message indicates that the upstream
=C2=A0 =C2=A0 =C2=A0node has not ass= igned an upstream label on its own and has requested
! =C2=A0 =C2=A0the downstream node t= o provide a label that it can use in both the
=C2=A0 =C2=A0 =C2=A0forward and reve= rse directions.=C2=A0 The presence of this value in the
=C2=A0 =C2=A0 =C2=A0UPSTREAM_LABEL o= bject of a PATH message MUST also be interpreted by
=C2=A0 =C2=A0 =C2=A0the receiving no= de as a request to mandate symmetric labels for the
***************
*** 160,166 ****
=C2=A0 =C2=A0 =C2=A0Label in the PAT= H message even after it receives an appropriate
=C2=A0 =C2=A0 =C2=A0symmetric label = in the RESV message.=C2=A0 This is done to make sure that
=C2=A0 =C2=A0 =C2=A0the downstream n= ode would pick a different symmetric label if and
! =C2=A0 =C2=A0when it needs to chan= ge the label at a later point in time.=C2=A0 If the
=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0
--- 160,166 ----
=C2=A0 =C2=A0 =C2=A0Label in the PAT= H message even after it receives an appropriate
=C2=A0 =C2=A0 =C2=A0symmetric label = in the RESV message.=C2=A0 This is done to make sure that
=C2=A0 =C2=A0 =C2=A0the downstream n= ode would pick a different symmetric label if and
! =C2=A0 =C2=A0when it needs to chan= ge the label at a later time.=C2=A0 If the
=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0
***************
*** 226,237 ****
=C2=A0 Internet-Draft =C2=A0 =C2=A0 = =C2=A0 Network Assigned Upstream-Label =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 J= une 2017
=C2=A0=C2=A0
=C2=A0=C2=A0
! =C2=A0 =C2=A0router send signal in= to the optical network unless it is at the
=C2=A0 =C2=A0 =C2=A0appropriate wave= length.=C2=A0 In other words, having the router send
! =C2=A0 =C2=A0signal with a wrong w= avelength may adversely impact existing optical
=C2=A0 =C2=A0 =C2=A0trails.=C2=A0 If= the clients do not have full visibility into the optical
=C2=A0 =C2=A0 =C2=A0network, they ar= e not in a position to pick the correct wavelength
! =C2=A0 =C2=A0up-front.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0The rest of this= section examines how the protocol mechanism proposed
=C2=A0 =C2=A0 =C2=A0in this document= allows the optical network to select and communicate
--- 226,237 ----
=C2=A0 Internet-Draft =C2=A0 =C2=A0 = =C2=A0 Network Assigned Upstream-Label =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 J= une 2017
=C2=A0=C2=A0
=C2=A0=C2=A0
! =C2=A0 =C2=A0router send the signa= l into the optical network unless it is at the
=C2=A0 =C2=A0 =C2=A0appropriate wave= length.=C2=A0 In other words, having the router send
! =C2=A0 =C2=A0signals with a wrong = wavelength may adversely impact existing optical
=C2=A0 =C2=A0 =C2=A0trails.=C2=A0 If= the clients do not have full visibility into the optical
=C2=A0 =C2=A0 =C2=A0network, they ar= e not in a position to pick the correct wavelength
! =C2=A0 =C2=A0in advance.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0The rest of this= section examines how the protocol mechanism proposed
=C2=A0 =C2=A0 =C2=A0in this document= allows the optical network to select and communicate
***************
*** 272,278 ****
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0The down= stream node (Node F) receives the PATH message, chooses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the appr= opriate wavelength values and forwards them in appropriate
! =C2=A0 =C2=A0 =C2=A0 label fields = to the egress client ("Router B")
=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0
--- 272,278 ----
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0The down= stream node (Node F) receives the PATH message, chooses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the appr= opriate wavelength values and forwards them in appropriate
! =C2=A0 =C2=A0 =C2=A0 label fields = to the egress client ("Router B").
=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0
***************
*** 284,290 ****
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0"Ro= uter B" receives the PATH message, turns the laser ON and tunes=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it to th= e appropriate wavelength (received in the UPSTREAM_LABEL/
! =C2=A0 =C2=A0 =C2=A0 LABEL_SET of = the PATH) and sends out a RESV message upstream.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0The RESV= message received by the ingress client carries a valid
=C2=A0 =C2=A0 =C2=A0 =C2=A0 symmetri= c label in the LABEL object. =C2=A0"Router A" turns on the=
--- 284,290 ----
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0"Ro= uter B" receives the PATH message, turns the laser ON and tunes=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it to th= e appropriate wavelength (received in the UPSTREAM_LABEL/
! =C2=A0 =C2=A0 =C2=A0 LABEL_SET of = the PATH message) and sends a RESV message upstream.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0o =C2=A0The RESV= message received by the ingress client carries a valid
=C2=A0 =C2=A0 =C2=A0 =C2=A0 symmetri= c label in the LABEL object. =C2=A0"Router A" turns on the=
***************
*** 306,318 ****
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0After the LSP is= set up, the network may decide to change the
=C2=A0 =C2=A0 =C2=A0wavelength for t= he given LSP.=C2=A0 This could be for a variety of reasons
! =C2=A0 =C2=A0- policy reasons, res= toration within the core, preemption etc.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0In such a scenar= io, if the ingress client receives a changed label
! =C2=A0 =C2=A0via the LABEL object = in a RESV modify, it retunes the laser at the
! =C2=A0 =C2=A0ingress to the new wa= velength.=C2=A0 Similarly, if the egress client
! =C2=A0 =C2=A0receives a changed la= bel via UPSTREAM_LABEL/LABEL_SET in a PATH
! =C2=A0 =C2=A0modify, it retunes th= e laser at the egress to the new wavelength.
=C2=A0=C2=A0
=C2=A0 4.=C2=A0 Acknowledgements
=C2=A0=C2=A0
--- 306,320 ----
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0After the LSP is= set up, the network may decide to change the
=C2=A0 =C2=A0 =C2=A0wavelength for t= he given LSP.=C2=A0 This could be for a variety of reasons
! =C2=A0 =C2=A0including policy reas= ons, restoration within the core, preemption,=C2=A0
! =C2=A0 =C2=A0etc.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0In such a scenar= io, if the ingress client receives a changed label
! =C2=A0 =C2=A0via the LABEL object = in a modified RESV message, it retunes the laser
! =C2=A0 =C2=A0at the ingress to the= new wavelength.=C2=A0 Similarly, if the egress client
! =C2=A0 =C2=A0receives a changed la= bel via UPSTREAM_LABEL/LABEL_SET in a modified=C2=A0
! =C2=A0 =C2=A0PATH message, it retu= nes the laser at the egress to the new
! =C2=A0 =C2=A0wavelength.
=C2=A0=C2=A0
=C2=A0 4.=C2=A0 Acknowledgements
=C2=A0=C2=A0
***************
*** 358,364 ****
=C2=A0 =C2=A0 =C2=A0semantics of a s= pecific field in an existing RSVP object and the
=C2=A0 =C2=A0 =C2=A0corresponding pr= ocedures.=C2=A0 Thus, there are no new security
=C2=A0 =C2=A0 =C2=A0implications rai= sed by this document and the security considerations
! =C2=A0 =C2=A0put together by [RFC3= 473] still applies.
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0For a general di= scussion on MPLS and GMPLS related security issues,
=C2=A0 =C2=A0 =C2=A0see the MPLS/GMP= LS security framework [RFC5920].
--- 360,366 ----
=C2=A0 =C2=A0 =C2=A0semantics of a s= pecific field in an existing RSVP object and the
=C2=A0 =C2=A0 =C2=A0corresponding pr= ocedures.=C2=A0 Thus, there are no new security
=C2=A0 =C2=A0 =C2=A0implications rai= sed by this document and the security considerations
! =C2=A0 =C2=A0discussed by [RFC3473= ] still apply.=C2=A0
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0For a general di= scussion on MPLS and GMPLS related security issues,
=C2=A0 =C2=A0 =C2=A0see the MPLS/GMP= LS security framework [RFC5920].

Thanks,
Acee=C2=A0


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

--94eb2c1b10cec7f9c3055678375e-- From nobody Wed Aug 16 09:42:23 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0896132412 for ; Wed, 16 Aug 2017 09:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGw7MfABBfP3 for ; Wed, 16 Aug 2017 09:42:19 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 C4171132675 for ; Wed, 16 Aug 2017 09:42:18 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id 49so12528059wrw.2 for ; Wed, 16 Aug 2017 09:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=npD2seE2jb2C6bb2+h2CQ9LNOsCieCwycFGpHh318xk=; b=gn2BxuL7jttv548izsDYNfDrH9Hoc37a7FIOwfahslAL2ZeKwSdfd7u2THLl1Ivutg WuX0+X3GgbiMRfK9j6ZXVbsFlwqh1dcUHn2DhGC1Ta84br45a7D3cl0i8GNEwyhr0BHi wOwZ7tvkI1Gp7KiPMupKiHof+qZfPUcwikDytofqP0JOUjQwbzsk30+8PxDwdXnF2vzg /9bLRUgtqtEuRQyzA8i1nPwvFWEzEH/B0yf5eZX2eu/q6l0ofKXj35d6POUU1Ha9a48R tRf5RJ1AT39/YJ2+jLYNFizguPLTllVyXEZfq1+VGOTebzrpWCUlZ0qyMwho+WfWXrvR H1iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:thread-index:content-language; bh=npD2seE2jb2C6bb2+h2CQ9LNOsCieCwycFGpHh318xk=; b=crAO3Nk3wuSLr6guVk5C4z75vEiR4QkpW6kB4mRvCdU/Zqh9QPWWSOPy9+jG/8WIpZ fVUUSGz341pUFJx+JpdiAQb+Mko9cHyDLLzIvGCya21L5DTTTjWDT+0KW2Sc3DShWK1Z zviEqRB2K/9W0Ne+QUqKcDUqb3KkQlcAaS1rPBOSckHVCyIimu3cVlMONpIcii4O4v5W /O5CUMWS6VCuSBhbt2o6Kh+xCqHhIC1/OMP2jYRSX7ec79r1nZTfLCk4yCY02tWLQqy4 WzwebrPPuDP1yf2gWHLdOFsz9T+/DVN/ouGyqwok2IQxIfLG9Drtg1kHjOhQ0+yoqdt7 jTgA== X-Gm-Message-State: AHYfb5gZSD9Q7G2QP5H2b2/cXTI2YLwotROZG08b8XbgRTxxUHz4dSdz rYf4niGTojrV6rvY X-Received: by 10.223.149.146 with SMTP id p18mr1514664wrp.160.1502901737240; Wed, 16 Aug 2017 09:42:17 -0700 (PDT) Received: from INARA ([87.101.243.155]) by smtp.gmail.com with ESMTPSA id l131sm2116181wmb.5.2017.08.16.09.42.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 09:42:16 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: To: Cc: "'Leeyoung'" Date: Wed, 16 Aug 2017 19:42:14 +0300 Message-ID: <00f001d316ae$9e2e9590$da8bc0b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01D316C7.C37DA250" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMWro55PMmCDszmTu6XYxBNtMhzog== Content-Language: en-gb Archived-At: Subject: [Teas] Next Steps for ACTN Framework? - RE: FW: New Version Notification for draft-ietf-teas-actn-framework-07.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 16:42:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F1_01D316C7.C37DA250 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Chairs, all.=20 =20 What=E2=80=99s the status with the I-D ? Did we decide the I-D was going = forward as I believe it=E2=80=99s ready. Eventually having the work = published as a formal document would really help the industry recognise = ACTN as an SDN controller framework for TE networks.=20 =20 BR, Dan.=20 =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Italo Busi Sent: 21 July 2017 15:22 To: Leeyoung ; teas@ietf.org Subject: Re: [Teas] FW: New Version Notification for = draft-ietf-teas-actn-framework-07.txt =20 Hi Young, =20 I have read the new section 6 and I am ok with the latest changes.=20 =20 I have read the -06 version of the framework and I think you had already = addressed all my previous comments. =20 Therefore I believe the document is ready for WG LC. =20 Italo =20 From: Leeyoung [mailto:leeyoung@huawei.com]=20 Sent: gioved=C3=AC 20 luglio 2017 11:23 To: teas@ietf.org =20 Subject: [Teas] FW: New Version Notification for = draft-ietf-teas-actn-framework-07.txt =20 Hi,=20 =20 We have uploaded the ACTN framework draft completely merging with the = Abstraction Method draft = https://datatracker.ietf.org/doc/draft-lee-teas-actn-abstraction/ . This = decision was made per WG chairs=E2=80=99 recommendation. All changes = took place in Section 6. We added Sections 6.1 and 6.3 and 6.4. All = these are imported from The Abstraction Method draft with minor edit to = shorten the length and to make the flow better. If this is acceptable, = we will deprecate the Abstraction method draft.=20 =20 6. Topology Abstraction Method...................................21 6.1. Abstraction Factors......................................22 = (added) 6.2. Abstraction Types........................................23 6.2.1. Native/White Topology...............................23 6.2.2. Black Topology......................................24 6.2.3. Grey Topology.......................................25 6.3. Building Method of Grey Topology.........................27 = (added) 6.3.1. Automatic generation of abstract topology by configuration..............................................27 6.3.2. On-demand generation of supplementary topology via path compute request/reply......................................28 6.4. Abstraction Configuration Consideration..................29 = (added) 6.4.1. Packet Networks.....................................29 6.4.2. OTN Networks........................................29 6.4.3. WSON Networks.......................................30 6.5. Topology Abstraction Granularity Level example. =20 We=E2=80=99d appreciate your review and comment. As Pavan mentioned = during the TEAS meeting, the WG LC for this draft would be the next step = upon the approval of the chairs.=20 =20 Thanks & Best regards, Daniele and Young =20 -----Original Message----- From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, July 20, 2017 11:19 AM To: Daniele Ceccarelli >; Leeyoung = > Subject: New Version Notification for = draft-ietf-teas-actn-framework-07.txt =20 =20 A new version of I-D, draft-ietf-teas-actn-framework-07.txt has been successfully submitted by Young Lee and posted to the IETF = repository. =20 Name: draft-ietf-teas-actn-framework Revision: 07 Title: Framework for Abstraction and Control of = Traffic Engineered Networks Document date: 2017-07-20 Group: teas Pages: 46 URL: = = https://www.ietf.org/internet-drafts/draft-ietf-teas-actn-framework-07.tx= t Status: = = https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/ Htmlized: = = https://tools.ietf.org/html/draft-ietf-teas-actn-framework-07 Htmlized: = = https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-framework-07 Diff: = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-actn-framework-07 =20 Abstract: Traffic Engineered networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. =20 Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. =20 This document provides a framework for Abstraction and Control of Traffic Engineered Networks (ACTN). =20 =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. =20 The IETF Secretariat =20 ------=_NextPart_000_00F1_01D316C7.C37DA250 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Chairs, all.

 

What=E2=80=99s the status with the I-D ? Did we decide = the I-D was going forward as I believe it=E2=80=99s ready. Eventually = having the work published as a formal document would really help the = industry recognise ACTN as an SDN controller framework for TE networks. =

 

BR, Dan.

 

From: Teas = [mailto:teas-bounces@ietf.org] On Behalf Of Italo = Busi
Sent: 21 July 2017 15:22
To: Leeyoung = <leeyoung@huawei.com>; teas@ietf.org
Subject: Re: [Teas] = FW: New Version Notification for = draft-ietf-teas-actn-framework-07.txt

 

Hi Young,

 

I have read = the new section 6 and I am ok with the latest changes. =

 

I have read = the -06 version of the framework and I think you had already addressed = all my previous comments.

 

Therefore I = believe the document is ready for WG LC.

 

Italo

 

From: Leeyoung [mailto:leeyoung@huawei.com] =
Sent: gioved=C3=AC 20 luglio 2017 11:23
To: teas@ietf.org
Subject: = [Teas] FW: New Version Notification for = draft-ietf-teas-actn-framework-07.txt

 

Hi,

 

We have uploaded the ACTN = framework draft completely merging with the Abstraction Method draft https://datatracker.ietf.org/doc/draft-lee-teas-actn-abstraction/ = . This decision was made per WG chairs=E2=80=99 recommendation. All = changes took place in Section 6. We added Sections 6.1 and 6.3 and 6.4. = All these are imported from The Abstraction Method draft with minor edit = to shorten the length and to make the flow better. If this is = acceptable, we will deprecate the Abstraction method draft. =

 

6. Topology Abstraction = Method...................................21

      = 6.1. Abstraction = Factors......................................22 = (added)

      6.2. Abstraction = Types........................................23

         6.2.1. = Native/White = Topology...............................23

         6.2.2. = Black = Topology......................................24

         6.2.3. = Grey = Topology.......................................25

      = 6.3. Building = Method of Grey Topology.........................27 = (added)

         6.3.1. = Automatic generation of abstract topology by

         = configuration..............................................27<= /span>

         6.3.2. = On-demand generation of supplementary topology via = path

         compute = request/reply......................................28

      6.4. Abstraction = Configuration Consideration..................29 = (added)

         6.4.1. = Packet = Networks.....................................29

         6.4.2. OTN = Networks........................................29

<= p class=3DMsoPlainText>         6.4.3. = WSON = Networks.......................................30

      = 6.5. Topology Abstraction Granularity Level = example.

 

We=E2=80=99d appreciate your review and comment. As Pavan = mentioned during the TEAS meeting, the WG LC for this draft would be the = next step upon the approval of the chairs.

 

Thanks & Best = regards,

Daniele and Young

 

-----Original = Message-----
From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org<= /a>]
Sent: Thursday, July 20, 2017 11:19 AM
To: Daniele = Ceccarelli <daniele.ceccarelli@ericss= on.com>; Leeyoung <leeyoung@huawei.com>
Subjec= t: New Version Notification for = draft-ietf-teas-actn-framework-07.txt

 

 

A new version of I-D, = draft-ietf-teas-actn-framework-07.txt

has been successfully submitted = by Young Lee and posted to the IETF repository.

 

Name:         &= nbsp;        = draft-ietf-teas-actn-framework

Revision:        &nb= sp;     07

Title:         =             = Framework for Abstraction and Control of Traffic Engineered = Networks

Document date: 2017-07-20

Group:         =          = teas

Pages:         =          = 46

URL:         &n= bsp;  https://www.ietf.org/inte= rnet-drafts/draft-ietf-teas-actn-framework-07.txt

Status:         https://datatracker.ietf.= org/doc/draft-ietf-teas-actn-framework/

<= p class=3DMsoPlainText>Htmlized:       https://tools.ietf.org/ht= ml/draft-ietf-teas-actn-framework-07

Htmlized:       https://datatracker.ietf.= org/doc/html/draft-ietf-teas-actn-framework-07

Diff:         &= nbsp; https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-teas-actn-framework-07=

 

Abstract:

   Traffic Engineered = networks have a variety of mechanisms to

   facilitate the = separation of the data plane and control plane. = They

   also have a range of management and = provisioning protocols to

   configure and = activate network resources.  These = mechanisms

   represent key technologies for enabling = flexible and dynamic

   networking.

 

   Abstraction of = network resources is a technique that can be = applied

   to a single network domain or across multiple = domains to create a

   single virtualized network that is under the = control of a network

   operator or the customer of the operator that = actually owns

   the network resources.

 

   This document = provides a framework for Abstraction and Control = of

   Traffic Engineered Networks = (ACTN).

 

 

          =   =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;         =

 

 

Please note that it may take a couple of minutes from the = time of submission until the htmlized version and diff are available at = tools.ietf.org.

 

The IETF Secretariat

 

------=_NextPart_000_00F1_01D316C7.C37DA250-- From nobody Sun Aug 20 13:54:45 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A24E132359; Sun, 20 Aug 2017 13:54:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Elwyn Davies To: Cc: draft-ietf-teas-pce-central-control.all@ietf.org, ietf@ietf.org, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150326246998.3553.16986401070448324505@ietfa.amsl.com> Date: Sun, 20 Aug 2017 13:54:30 -0700 Archived-At: Subject: [Teas] Genart last call review of draft-ietf-teas-pce-central-control-03 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 20:54:30 -0000 Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-teas-pce-central-control-03 Reviewer: Elwyn Davies Review Date: 2017-08-20 IETF LC End Date: 2017-08-24 IESG Telechat date: 2017-08-31 Summary: Amost ready. I found this a well-written and mostly readily comprehensible document although it contains a couple of instances of unexplained SDN/PCE jargon (notably 'southbound'). My main concern is that the archtecture suggests that extensions to PCEP will a.s. be needed and implies that mechanisms will be needed to provide multiple extensions but neither specifies detailed guidance as to how this might be done or points to work in progress that would provide this guidance. The implication of the statements in this document are that an implementation or deployment might need to check if particlar extensions are implemented in communication partners and also how to behave if an unreconixed extension is received especially to avoid possible DoS. The other minor issues are only just abve the level of nits. Major issues: None Minor issues: Abstract:  The abstract is probably overlong. s1:  RFC 4655 is itself an architecture that introduces the PCE.  It would be helpful to explain that this document is an extension of the basic PCE arcitecture except that it relies on the specific use f the PCEP for intercommunication between architectural elements providing traffic control and routing whereas RFC 4655 does not assume any particular protocol. s3.2: It would be desirable to reiterate the problem of synchronization mentioned in s2.1.2 which is relevant to all the high level functions. s4: Since this document effectively gurantees that extensions to PCEP will be created and since RFC 5440 contains no extensibility procedures/guidelines, it seems to me that either this document should indicate how PCEP extensions and profiles are added to the base protocol or should point  to a (normative and currently non-existent) document that updates RFC 5440 and defines how extensions shoould be structured and provides ways for implementations to determine what is supported, if necessary. s5, para 2:  The second part of this paragraph;    However, debate will rage over overall system security and the opportunity for attacks in an architecture with a central controller since the network can be vulnerable to denial of service attacks on the controller, and the forwarding system may be harmed by attacks on the messages sent to individual NEs. In short, while the interactions with a PCE-based controller are not substantially different from those in any other SDN architecture, the security implications of SDN are still open for discussion. The IRTF's SDN Research Group (SDNRG) discussed this topic. This text needs to be rewritten to be suitable for inclusion in an RFC that is a document of record. s6:  The PCE, depending on which of the aspects mentioned in s3 and the technology being managed (LSPs, transport paths, etc.) are involved in a particular imlemetation/deployment, will need to access the relevant state information in NEs and possibly other PCEs using relevant managent protcol(s) and MIBs or similar.  Integrating this state information with the PCEP management information wil be key to effective operation of the centralized PCE system. s10:  It is arguable, IMO, that RFC 5440 and I-D.ietf-pce-pce-initiated-lsp are normative references.  The architecture implies their usage and someone implementing the architecture would need to be familiar with the details of the extended PCEP, particularly in respect of the manageability and security aspects of the protocol. Nits/editorial comments: Abstract, para 1: Statements of implied omnipotence by mortals a.s. lead to hubristic consequences...  s/any definition of "optimal"/virtually any definition of "optimal"/ Abstract (and subseqently):  The term 'southbound' is SDN specific jargon and should be explained.  Given that the abstract is already (IMO) too long, it would be wise to remove it from the abstract (I don't think it is essential) and provide the explation in s1. s1, para 4: See comment above... s/any form of routed or switched network./virtually any form of routed or switched network./ s2, para 2 and Figures 1-7:  It would be useful to add a note in s2 to indicate that the TED box in all the figures should imply that other databases may also be accessed. s2, last para (just before Fig.3): s/use case- specific/use case-specific [or use case specific]/ s2.1, para 1: The text at the beginning of the para doesn't read very easily - the 'or' disguises the fact that the two problems are on either sideof the 'or'.  Suggest someting like: OLD: Systems with central controllers are vulnerable to two problems: failure or overload of the single controller. NEW: Systems with a single central controllers are vulnerable to two problems:   - controller failure, and   - controller overload. ENDS s3.1.4, last para:      new protocol extensions may be needed, and some are already being worked on      in [I-D.ietf-pce-wson-rwa-ext].  The second clause of this is not future proof:   Suggest s/and some are already being worked on in [I-D.ietf-pce-wson-rwa-ext]./as, for example, described  in [I-D.ietf-pce-wson-rwa-ext]./ s3.1.5, para 1: s/the header or a packet/the header of a packet/ (I think - certainly for IPv6 use case) s3.2.2, last para:  The final sentence is probably superfluous - and, if it remains, probably needs a reference to explain what a FEC is. From nobody Tue Aug 22 02:44:53 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E81132076; Tue, 22 Aug 2017 02:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNZ245Xqcat5; Tue, 22 Aug 2017 02:44:43 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 35AE313236D; Tue, 22 Aug 2017 02:44:41 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-3f-599bfd0769b4 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.69.22436.70DFB995; Tue, 22 Aug 2017 11:44:39 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 22 Aug 2017 11:44:38 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ew3zfwfAg9HaNyzbyCYKJD+CS2XZG9FeMsl1Neyo9o8=; b=GVGlKatBC755K7xAuCIpdSxoVMfDxa0cflbJ8QWF4drIMWFXGsTfgwE1ck9Bdov/DzCd/1shJK7fTDqczAHvLK/yWbuFLzmSD7eDlOyT93J5eDWqkrlmHiKOph/2JqOU2AmdHMd8q7feZimyTr3XlGklmxsfBDBIIe77Y+zbfXY= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0883.eurprd07.prod.outlook.com (10.161.71.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Tue, 22 Aug 2017 09:44:37 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::64f3:4853:6cc1:d0cd]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::64f3:4853:6cc1:d0cd%15]) with mapi id 15.01.1385.008; Tue, 22 Aug 2017 09:44:37 +0000 From: Daniele Ceccarelli To: Suresh Krishnan CC: The IESG , "draft-ietf-teas-gmpls-scsi@ietf.org" , Vishnu Beeram , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-teas-gmpls-scsi-03: (with DISCUSS) Thread-Index: AQHTC+TcZ/ESc50AYUuBO+pBnvaX3qJyRPUQgAAGFpCAAGBZgIAdgwMQ Date: Tue, 22 Aug 2017 09:44:37 +0000 Message-ID: References: <150171551836.5679.14360895881912372876.idtracker@ietfa.amsl.com> <04827492-DD41-4DBF-99B2-D0A0BF801CC2@gmail.com> In-Reply-To: <04827492-DD41-4DBF-99B2-D0A0BF801CC2@gmail.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0883; 6:hNdpYR5/MPbWf2edi6ikMuvifRTrzbbjyvaxcJ0iL9aBvJHm6hMzX6ROs5d/EgrBn7YIK6Iu4uytifXdly6Pza8A23Ud9N+jR++UhOiBrjFQr7RRvK3Dsw4cRj2u1aWwgvTfgssuB4WetrTTfzqgSHyytKOSOtBdEHwjI4CXOAOBu80QjkcGo3F8fXk+TeGb59lQBipcndCPDemiiWGlGYI+rVoVy/ZcCa5qbDfgqqCiyqceNp3u3yJglXNaImZzYn16szrFMUg2SSzjJaHWTlJAFEcLNiSHB7pFlq142mlFRHAzEKZGEOrIUOBk3RWH5h74D8v0CUPmAOJH7y5sdw==; 5:hyvsChhJxKbOVJd6VmtUekBL1MfpdweKvivYqZeUB9EWLoMwZ+o+ZHz+Dup4pPoz3qAGdvBYNxTxjSvhbqcsI27WAz13tX+8hn4BIrCk69WCe9II8EVS7pFTHbRj6F71e69RmKr3I2OlHD5nJmILOQ==; 24:sY1azocS7ljLZsssKX3ZVETMvvo+LBXE02SgsM7eSPUizf4Q0sKg6g64dTicBqFTUqxx3e+ytmvq8TR46MD8HpzGqCAv9tq0xm0l4WneY6c=; 7:E5dNXRgMn1A83ND7fUq5WdM/5hxNS9eEFe1etRT6FpiO6PIBbg2LKeYr6LRxXtnlKdlLZktT4TtiTTSPXee0fDdJv/zF2dc8Kpxbx4ZZspx9d6p2hpAwtjvDrdZh0VUQnZ8XLY8pGrjeZQ9QqVBZ0fnGeirOVPBuPIYKZx+Cxc9oWvRwDMegbjVWa8r1yocTrMNAoH8PMK1fB4zYfylb7nb7n+aJwpC7pk3qiMmj41s= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f3accad6-defc-408c-d208-08d4e942677c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0883; x-ms-traffictypediagnostic: AM2PR07MB0883: x-exchange-antispam-report-test: UriScan:(37575265505322)(138986009662008); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0883; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0883; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(24454002)(189002)(199003)(13464003)(377454003)(105586002)(2906002)(2900100001)(3660700001)(106356001)(7736002)(2950100002)(6916009)(305945005)(5660300001)(7696004)(189998001)(53546010)(66066001)(93886005)(14454004)(86362001)(102836003)(81156014)(3846002)(6116002)(81166006)(229853002)(8936002)(25786009)(8666007)(9686003)(6246003)(55016002)(54356999)(99286003)(54906002)(74316002)(39060400002)(8676002)(97736004)(50986999)(76176999)(4326008)(101416001)(110136004)(68736007)(3280700002)(478600001)(5250100002)(6506006)(230783001)(53936002)(6436002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0883; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2017 09:44:37.8023 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0883 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURzGOe9lex2tTnPiX80Pjm4azktBK9L0iwh2+yCkItOVL94v7VXR /DJnGjjFS5k6LSOGhFpeK6cSNAUvpYmh5S3NTUisTAlTm5XzNejb7/88D+d/zsNhSImedmbi U9JZdYoqSSYQUdVhL854Crdrwr2XH3soSoq+CBRV1jJS0dcyTCu097sIRf5GJ6V42FRNBgiC jfpZYbDBsEkEv9eOC6+QEaJzMWxSfCar9vKPFsXlDa/TaU2QVdD9UahBM46FyI4BfApKh/tR IRIxEtyHoHLoFsUPAwgau0foQsQwFC4moSCB1ysI6LMsCfjBjKB43robEuCzYDFdsKEUe0HX mNIWIbEFgWZrhrBts8fhMDffLLCxFEfAoFEn5PNBMGlxsckUPgKGtgrKxmIcCfc0C3ur6gko by2nbYYd9oONQuvumQi7Qmn3I2RjEjvClKWO4F+GwdDzluTZAZbMv2k+fw2a8zv3Mm4w2qDf Y1cYq9PtNgG4QAgTz6cEvCGHZ2VfEc8XYWLoz56+QMCiMYtnD5gb+EHzHAIrrXeEPCfCiraR 4vkdDXnl7jwfgvpNHV2KPPX/3Vu/0wWJ3aG5y4uX3eCu7pNQv9vFQRistlAPEdWAHDiW45Jj fU/KWXX8dY5LTZGnsOltaOfHvOr45dmJGpcDTQgzSLZPzEzVhEtoVSaXnWxCwJAyqVhm3ZHE Marsm6w6NUqdkcRyJuTCUDJHccDL0TAJjlWls4ksm8aq/7kEY+esQaqikdDZo3OjEeu1b9qn EorsayMP9K75DI7U3ihJaO8Zyjj+vVru6nQ7hw2Mdsr2G8v1j5nYL21sjvL+cDkoV3s4XTlt txhfdvpSZkjY+RPfXDJfP5180JGjSTUHHtP69of1rhpb2lYhRBfa9GQ79XOV0rr1U7lWWRTd JlqaNl8dl1FcnMrHg1Rzqr8Os4F0LQMAAA== Archived-At: Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-gmpls-scsi-03: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 09:44:46 -0000 SGkgU3VyZXNoLA0KDQpzb3JyeSBmb3IgdGhlIGRlbGF5IGluIGFuc3dlcmluZy4NCkkgbW9kaWZp ZWQgdGhlIHRleHQgYXMgZm9sbG93czogDQoNCiAgICAgICAgVGhlIEdlbmVyYWxpemVkIFNDU0kg aXMgY29tcG9zZWQgb2YgemVybyBvciBtb3JlIHZhcmlhYmxlIGxlbmd0aA0KICAgICAgICB0eXBl LWxlbmd0aC12YWx1ZSBmaWVsZHMgd2hpY2ggYXJlIGVhY2ggY2FsbGVkIGEgU0NTSS1UTFYuDQog ICAgICAgIFRoZXJlIGFyZSBubyBzcGVjaWZpYyBzaXplIHJlc3RyaWN0aW9ucyBvbiB0aGVzZSBT Q1NJLVRMVi4gIFNpemUNCiAgICAgICAgYW5kIG90aGVyIGZvcm1hdHRpbmcgcmVzdHJpY3Rpb25z IG1heSBiZSBpbXBvc2VkIGJ5IHRoZSByb3V0aW5nDQogICAgICAgIHByb3RvY29sIElTQ0QgZmll bGQsIHJlZmVyIHRvIDx4cmVmIHRhcmdldD0iUkZDNDIwMyIvPiBhbmQgPHhyZWYNCiAgICAgICAg dGFyZ2V0PSJSRkM1MzA3Ii8+LiBQbGVhc2UgYWxzbyByZWZlciB0byA8eHJlZiB0YXJnZXQ9IlJG QzM2MzAiLz4gZm9yDQogICAgICAgIHRoZSB0cmVhdG1lbnQgb2YgbWFsZm9ybWVkIExpbmsgVExW cy4NCg0KSG93IHRvIG1hbmFnZSBtYWxmb3JtZWQgTGluayBUTFZzIGlzIGFscmVhZHkgZGVzY3Jp YmVkIGluIFJGQzM2MzAuDQoNClRoYW5rcw0KRGFuaWVsZSAgDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IFN1cmVzaCBLcmlzaG5hbiBbbWFpbHRvOnN1cmVzaC5rcmlzaG5h bkBnbWFpbC5jb21dIA0KU2VudDogZ2lvdmVkw6wgMyBhZ29zdG8gMjAxNyAxNjowNg0KVG86IERh bmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4NCkNjOiBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtdGVhcy1nbXBscy1zY3NpQGlldGYu b3JnOyBWaXNobnUgQmVlcmFtIDx2YmVlcmFtQGp1bmlwZXIubmV0PjsgdGVhcy1jaGFpcnNAaWV0 Zi5vcmc7IHRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBTdXJlc2ggS3Jpc2huYW4ncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtdGVhcy1nbXBscy1zY3NpLTAzOiAod2l0aCBESVNDVVNTKQ0KDQpI aSBEYW5pZWxlLA0KDQo+IE9uIEF1ZyAzLCAyMDE3LCBhdCA0OjIxIEFNLCBEYW5pZWxlIENlY2Nh cmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gSGkg U3VyZXNoLA0KPiANCj4gVGhlIEdNUExTIFNDU0kgaXMgYSBzdWItVExWIG9mIHRoZSBJU0NEIChp bnRlcmZhY2Ugc3dpdGNoaW5nIGNhcGFiaWxpdHkgZGVzY3JpcHRvci1SRkM0MjAzKSwgd2hpY2gg aW4gdHVybiBpcyBhIHN1YiBUTFYgb2YgdGhlIExpbmsgVExWIChSRkMzNjMwKSAuLi4geWVzIHdl IGxpa2UgbmVzdGluZyBpbiBHTVBMUyDwn5iKDQo+IA0KPiBSRkMgMzYzMCAoc2VjdGlvbiAyLjQu Mi4pIHNheXM6ICIgVW5yZWNvZ25pemVkIHN1Yi1UTFZzIGFyZSBpZ25vcmVkLiINCj4gDQo+IEl0 IHNlZW1zIG9idmlvdXMgYnV0IGl0IHRvb2sgbWUgYSB3aGlsZSB0byBnbyBiYWNrIHRvIHRoZSBy b290IG9mIHRoZSBwcm9ibGVtLCBoZW5jZSBmZXcgd29yZHMgIHdvdWxkIGhlbHAgdGhlIHJlYWRl ci4gSG93IGFib3V0IHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2Y6DQo+IA0KPiAiTWFsZm9y bWVkIHBhY2tldHMgc2hvdWxkIGJlIHRyZWF0ZWQgYWNjb3JkaW5nbHkgd2l0aCBlcnJvciBoYW5k bGluZyBwcm9jZWR1cmVzIGRlZmluZWQgaW4gUkZDMzYzMC7igJ0gPw0KDQrigKYNCg0KPiANCj4g UmUtcmVhZGluZyB0aGUgZHJhZnQgaXQgc2VlbXMgaXQncyBhbHJlYWR5IGNvdmVyZWQgYnkgdGhp cyBzdGF0ZW1lbnQ6DQo+IA0KPiAiU2l6ZSBhbmQgb3RoZXIgZm9ybWF0dGluZyByZXN0cmljdGlv bnMgbWF5IGJlIGltcG9zZWQgYnkgdGhlIHJvdXRpbmcNCj4gICAgICAgIHByb3RvY29sIElTQ0Qg ZmllbGQsIHJlZmVyIHRvIDx4cmVmIHRhcmdldD0iUkZDNDIwMyIvPiBhbmQgPHhyZWYNCj4gICAg ICAgIHRhcmdldD0iUkZDNTMwNyIvPi4iDQo+IA0KPiBXb3VsZCB5b3UgbGlrZSBpdCB0byBiZSBt YWRlIG1vcmUgZXhwbGljaXQ/DQoNClllcy4gUGxlYXNlLiBJIHBlcnNvbmFsbHkgdGhpbmsgaWdu b3JpbmcgYSBsZW5ndGggZXJyb3IgYXMgYW4gdW5yZWNvZ25pemVkIFRMViBhbmQgbW92aW5nIG9u IGlzIG5vdCBwcmVmZXJhYmxlLCBidXQgSSBhbSBoYXBweSB0byBzdGVwIGFzaWRlIGlmIHRoYXQg ZGVjaXNpb24gaXMgZXhwbGljaXRseSBtYWRlLg0KDQpSZWdhcmRzDQpTdXJlc2gNCg0KDQo= From nobody Tue Aug 22 06:08:17 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C596B1329AE; Tue, 22 Aug 2017 06:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8NnmvjpUW2N; Tue, 22 Aug 2017 06:08:07 -0700 (PDT) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (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 84A26132397; Tue, 22 Aug 2017 06:08:07 -0700 (PDT) Received: by mail-yw0-x242.google.com with SMTP id s187so2334399ywf.3; Tue, 22 Aug 2017 06:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+chehbUK9W5s5QB8kqgIo1Pd4M8WcKxJfBGlBCY+gyk=; b=DwxQKIRqOFTDOuHcRNOwZ8UpjptQGBK9RXwYek22KXlj1lylaiYriOa+3lIrsf1Qxm YzmsAGkTMFsbjEX/A7K32M+FaRTJNu2YcOMt0jPNvtcswoXD/p1v++i0l//ZEO57gOoi uNl2mYco3dViCFPDFtMP5eAtRmgBgWUCuyB+eEPRm/DfrFJ+eN93gzrzE1r/aTiBU6tT Rgbg5jM8CPH14SoPGivGgfwuzRWv6WV+55KVNhchpBhTuCjR9WhoUSnHbnhW567RsggS GuGkJ7vj+oIpx1M4juQX/gzK8kQ7SJGB9WJv7ppcMpNkMINyDCLHzgWtyVxgDdCsF5Xt 6JAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+chehbUK9W5s5QB8kqgIo1Pd4M8WcKxJfBGlBCY+gyk=; b=Ro5eppI0XIMqGEZwRakw2UMzI/TSHhEXZcNux8F2YNZaNZPeRqBBrm/risrawRXX/g pnltKvt2N1YayZlwWrVZfp8DN80Ca2zTxAgaWPT6ZbTSXcPxf+lsXcJ46/Z9Jp1ggF0J 7VSMYwsfhtOFCu7LdILuSvB08CY1as804TjVaG29p8x//mJGd11Jyp5/fvsq/o7QQMlJ fC5b8dsLVCxNe5lVevBanfVMqFFmmfc3rRY33kW3DIPNRK/gX5aUY/QrxgpVpJqozqNz nQ4VXN+/+vnji29k2w1/GocJc4M36bv2kw53zOapSPzY/CQsnkA2uhu2WzU+7Gi8VOXI nv7g== X-Gm-Message-State: AHYfb5iUPB8cCk5wWaCPDMWcWINc5KfetHWqYFR8EjAymywpgqcu6gx2 WoHwH9gORBkthw== X-Received: by 10.13.200.134 with SMTP id k128mr503040ywd.300.1503407286622; Tue, 22 Aug 2017 06:08:06 -0700 (PDT) Received: from [10.0.0.5] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id v187sm3990824ywb.78.2017.08.22.06.08.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 06:08:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Suresh Krishnan In-Reply-To: Date: Tue, 22 Aug 2017 09:08:02 -0400 Cc: The IESG , "draft-ietf-teas-gmpls-scsi@ietf.org" , Vishnu Beeram , "teas-chairs@ietf.org" , "teas@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <652D7481-A293-4A79-870A-7461EC529D91@gmail.com> References: <150171551836.5679.14360895881912372876.idtracker@ietfa.amsl.com> <04827492-DD41-4DBF-99B2-D0A0BF801CC2@gmail.com> To: Daniele Ceccarelli X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-gmpls-scsi-03: (with DISCUSS) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 13:08:11 -0000 Thanks Daniele. Regards Suresh > On Aug 22, 2017, at 5:44 AM, Daniele Ceccarelli = wrote: >=20 > Hi Suresh, >=20 > sorry for the delay in answering. > I modified the text as follows:=20 >=20 > The Generalized SCSI is composed of zero or more variable = length > type-length-value fields which are each called a SCSI-TLV. > There are no specific size restrictions on these SCSI-TLV. = Size > and other formatting restrictions may be imposed by the routing > protocol ISCD field, refer to and = target=3D"RFC5307"/>. Please also refer to for > the treatment of malformed Link TLVs. >=20 > How to manage malformed Link TLVs is already described in RFC3630. >=20 > Thanks > Daniele =20 >=20 >=20 > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@gmail.com]=20 > Sent: gioved=C3=AC 3 agosto 2017 16:06 > To: Daniele Ceccarelli > Cc: The IESG ; draft-ietf-teas-gmpls-scsi@ietf.org; = Vishnu Beeram ; teas-chairs@ietf.org; teas@ietf.org > Subject: Re: Suresh Krishnan's Discuss on = draft-ietf-teas-gmpls-scsi-03: (with DISCUSS) >=20 > Hi Daniele, >=20 >> On Aug 3, 2017, at 4:21 AM, Daniele Ceccarelli = wrote: >>=20 >> Hi Suresh, >>=20 >> The GMPLS SCSI is a sub-TLV of the ISCD (interface switching = capability descriptor-RFC4203), which in turn is a sub TLV of the Link = TLV (RFC3630) ... yes we like nesting in GMPLS =F0=9F=98=8A >>=20 >> RFC 3630 (section 2.4.2.) says: " Unrecognized sub-TLVs are ignored." >>=20 >> It seems obvious but it took me a while to go back to the root of the = problem, hence few words would help the reader. How about something = along the lines of: >>=20 >> "Malformed packets should be treated accordingly with error handling = procedures defined in RFC3630.=E2=80=9D ? >=20 > =E2=80=A6 >=20 >>=20 >> Re-reading the draft it seems it's already covered by this statement: >>=20 >> "Size and other formatting restrictions may be imposed by the routing >> protocol ISCD field, refer to and = > target=3D"RFC5307"/>." >>=20 >> Would you like it to be made more explicit? >=20 > Yes. Please. I personally think ignoring a length error as an = unrecognized TLV and moving on is not preferable, but I am happy to step = aside if that decision is explicitly made. >=20 > Regards > Suresh >=20 >=20 From nobody Tue Aug 22 15:27:36 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721161329F7; Tue, 22 Aug 2017 15:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vWYzljzqDtH; Tue, 22 Aug 2017 15:27:32 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8492132A94; Tue, 22 Aug 2017 15:27:31 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v7MMPKFm039596; Tue, 22 Aug 2017 18:27:29 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2cgu5k59x9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Aug 2017 18:27:29 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7MMRSQe009482; Tue, 22 Aug 2017 18:27:28 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7MMRMoF009366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Aug 2017 18:27:25 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 22 Aug 2017 22:27:07 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.245]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0319.002; Tue, 22 Aug 2017 18:27:06 -0400 From: "BRUNGARD, DEBORAH A" To: "draft-ietf-teas-network-assigned-upstream-label@ietf.org" CC: "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: AD review: draft-ietf-teas-network-assigned-upstream-label Thread-Index: AdMbkGQpKY9keg5gRAWe0jK8RuQ3Sg== Date: Tue, 22 Aug 2017 22:27:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.199.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-22_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708220342 Archived-At: Subject: [Teas] AD review: draft-ietf-teas-network-assigned-upstream-label X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 22:27:34 -0000 Hi, I've reviewed this draft and after discussing with your Chairs a bit on it,= I have the following comments: - I think you need to create an IANA registry for this label if you want to= ensure it does not get used in an implementation. For example, MPLS has re= gistries for "special purpose label values". While this is only one value, = I suggest a similar top-level registry, with an entry for this draft. - the draft refers to an implementation survey as justifying there are no b= ackward compatibility concerns with the choice of this label. But there was= no implementation survey. I think today's RFC3473 procedures will have an = upstream node rejecting this label if returned to it and no data traffic wi= ll be transmitted. So this should prevent any harm. I recommend being more = concise in the backward compatibility section on the processing. - Currently the draft updates RFC3473. I think it also updates RFC3471 and = RFC6205 (especially as the example in the draft is WSON and this draft requ= ires a modification of RFC6205 procedures). And you need to clearly identif= y what it is that you are updating in this document vs. the previous docume= nts. - The draft is a bit too short:-) You need to have proper sections on Proce= dures and Label Format. The current Processing section is not sufficient. T= here's more in the use case, than in the Processing section. - Considering the changes for the above, I recommend for your Chairs to hav= e a short (1 week) WG Last Call on the updated draft. If can do SOON (Adria= n's definition:-)), I'll leave it as "AD Evaluation", if drags out, I'll se= nd it back to the WG. Thanks, Deborah From nobody Wed Aug 23 00:11:46 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD62132B0B; Wed, 23 Aug 2017 00:11:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: teas-chairs@ietf.org, db3546@att.com, teas@ietf.org, vbeeram@juniper.net X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150347230353.19454.5490546943595485130.idtracker@ietfa.amsl.com> Date: Wed, 23 Aug 2017 00:11:43 -0700 Archived-At: Subject: [Teas] teas - New Meeting Session Request for IETF 100 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 07:11:43 -0000 A new meeting session request has just been submitted by Vishnu Pavan Beeram, a Chair of the teas working group. --------------------------------------------------------- Working Group Name: Traffic Engineering Architecture and Signaling Area Name: Routing Area Session Requester: Vishnu Beeram Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: mpls ccamp pce rtgwg netmod detnet Second Priority: idr i2rs spring ospf Third Priority: pals bess nvo3 isis People who must be present: Lou Berger Deborah Brungard Vishnu Pavan Beeram Resources Requested: Special Requests: Other Conflicts: IRTF RRG, RTG BOFs --------------------------------------------------------- From nobody Wed Aug 23 08:29:22 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103141329BA for ; Wed, 23 Aug 2017 08:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iX6G2C3Y7e3 for ; Wed, 23 Aug 2017 08:29:18 -0700 (PDT) Received: from 18.mo4.mail-out.ovh.net (18.mo4.mail-out.ovh.net [188.165.54.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B03E132938 for ; Wed, 23 Aug 2017 08:29:18 -0700 (PDT) Received: from player159.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id 55E048DF23 for ; Wed, 23 Aug 2017 17:29:16 +0200 (CEST) Received: from RCM-ns3033854.ip-51-255-71.eu (publico1.tid.es [195.235.92.36]) (Authenticated sender: ietf@lmcontreras.com) by player159.ha.ovh.net (Postfix) with ESMTPSA id 00A5A480080; Wed, 23 Aug 2017 17:29:14 +0200 (CEST) Received: from publico1.tid.es ([195.235.92.36]) by mail.ovh.net with HTTP (HTTP/1.1 POST); Wed, 23 Aug 2017 17:29:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 Aug 2017 17:29:14 +0200 From: ietf@lmcontreras.com To: teas@ietf.org Cc: luismiguel.contrerasmurillo@telefonica.com Message-ID: X-Sender: ietf@lmcontreras.com User-Agent: Roundcube Webmail/1.3.0 X-Originating-IP: 195.235.92.36 X-Webmail-UserID: ietf@lmcontreras.com X-Ovh-Tracer-Id: 11478549552739139563 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelledrtddvgdeludcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 15:29:21 -0000 Hi all, these days I have gone through both draft-ietf-teas-actn-framework. The multi-domain case is one of the scenarios covered by the draft, however I think it requires further elaboration in certain aspects, basically having in mind the case of interconnecting different administrative domains. As per Figure 2, a Customer can request to a Service Provider a Virtual Network Service (VNS). The Service Provider can satisfy such request by its own if it has Access to a number of Network Providers as reflected in the figure. The scenario I'm referring to would be the one in which the Service Provider (let's call it SP1) cannot honor the Customer request by its own but requires some capabilities offered by another Service Provider (SP2 in this case). Mapping Figure 2 to Figure 3 (functional view of the ACTN architecture) we have the Customer Network Controller (CNC) in the Customer side, the Multi Domain Service Coordinator (MDSC) in the Service Provider side, and the Physical Network Controller (PNC) in the Network Provider side. The interfaces used are CMI between CNC and MDSC, and MPI between MDSC and PNC. CMI conveys service related information, while MPI conveys more detailed network/technology related information. As it is described now in the draft, the MDSC is the one in charged of the multi-domain Coordination by coordinating the PNCs of the Network Providers below. However there is no detail about the potential Coordination with another Service Provider that could be necessary for providing the VNS to the Customer. Section 5.1 describes a hierarchical connection of MDSCs that could be interpreted as a way of resolving such SP interconnection. However, for the interconnection of administrative domains interface MPI could not be sufficient. Probably something in between MPI and CMI could be required. So my proposal here would be the definition of a new interface, MMI, between MDSCs pertaining to different administrative domains. That interface conveys in principle service related information, and to some extent it could have as well network/technology related information, depending on the level of trustiness between SP1 and SP2. What do you think? Best regards Luis -- ___________________________________________ Luis M. Contreras ietf@lmcontreras.com luismiguel.contrerasmurillo@telefonica.com From nobody Wed Aug 23 09:11:44 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DF7132418 for ; Wed, 23 Aug 2017 09:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYRknquqfNpR for ; Wed, 23 Aug 2017 09:11:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AA213217D for ; Wed, 23 Aug 2017 09:11:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNE79166; Wed, 23 Aug 2017 16:11:34 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 23 Aug 2017 17:11:34 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.148]) by SJCEML703-CHM.china.huawei.com ([169.254.5.62]) with mapi id 14.03.0301.000; Wed, 23 Aug 2017 09:11:29 -0700 From: Leeyoung To: "ietf@lmcontreras.com" , "teas@ietf.org" CC: "luismiguel.contrerasmurillo@telefonica.com" Thread-Topic: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework Thread-Index: AQHTHCSon3ogMDdj90GD2JWXcbt3zqKSFcJg Date: Wed, 23 Aug 2017 16:11:28 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B404992@SJCEML702-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.599DA937.0058, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 14969bf3b03e47fc47010f32fcc662ef Archived-At: Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 16:11:43 -0000 Hi Miguel, Thanks for sharing your thought. As you pointed out, Section 5.1 describes = an advanced case of a hierarchy of MDSCs. We did not intend to describe the= case where two different/independent SPs are interconnected with the top M= DSC. This advanced form of MDSC hierarchy is intended for one network prov= ider to scale their networks. If the two SPs are trusted entities to each o= ther constituting multi-domain under the same administration forming the MD= SC hierarchy, this can be supported with the current model. As pointed out = in Figure 3, CMI is the business boundary that separates customer and the n= etwork provider and anything under the MDSC is assumed to be under one the = same business entity (i.e., trusted domain under the same administration).= =20 In any case, we regard MDSC-MDSC as a special case of MPI rather than defin= ing a separate interface called MMI (although we originally considered this= interface). =20 Hope this helps.=20 Best regards, Young -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of ietf@lmcontreras.com Sent: Wednesday, August 23, 2017 10:29 AM To: teas@ietf.org Cc: luismiguel.contrerasmurillo@telefonica.com Subject: [Teas] About interconnecting Multiple Administrative domains in dr= aft-ietf-teas-actn-framework Hi all, these days I have gone through both draft-ietf-teas-actn-framework. The mul= ti-domain case is one of the scenarios covered by the draft, however I thin= k it requires further elaboration in certain aspects, basically having in m= ind the case of interconnecting different administrative domains. As per Figure 2, a Customer can request to a Service Provider a Virtual Net= work Service (VNS). The Service Provider can satisfy such request by its ow= n if it has Access to a number of Network Providers as reflected in the fig= ure. The scenario I'm referring to would be the one in which the Service Pr= ovider (let's call it SP1) cannot honor the Customer request by its own but= requires some capabilities offered by another Service Provider (SP2 in thi= s case). Mapping Figure 2 to Figure 3 (functional view of the ACTN architecture) we = have the Customer Network Controller (CNC) in the Customer side, the Multi = Domain Service Coordinator (MDSC) in the Service Provider side, and the Phy= sical Network Controller (PNC) in the Network Provider side.=20 The interfaces used are CMI between CNC and MDSC, and MPI between MDSC and = PNC. CMI conveys service related information, while MPI conveys more detail= ed network/technology related information. As it is described now in the draft, the MDSC is the one in charged of the = multi-domain Coordination by coordinating the PNCs of the Network Providers= below. However there is no detail about the potential Coordination with an= other Service Provider that could be necessary for providing the VNS to the= Customer. Section 5.1 describes a hierarchical connection of MDSCs that could be inte= rpreted as a way of resolving such SP interconnection. However, for the int= erconnection of administrative domains interface MPI could not be sufficien= t. Probably something in between MPI and CMI could be required. So my proposal here would be the definition of a new interface, MMI, betwee= n MDSCs pertaining to different administrative domains. That interface conv= eys in principle service related information, and to some extent it could h= ave as well network/technology related information, depending on the level = of trustiness between SP1 and SP2. What do you think? Best regards Luis -- ___________________________________________ Luis M. Contreras ietf@lmcontreras.com luismiguel.contrerasmurillo@telefonica.com _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Wed Aug 23 09:12:55 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1889A132418 for ; Wed, 23 Aug 2017 09:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-hwjvjDAEcF for ; Wed, 23 Aug 2017 09:12:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67FDD1329CC for ; Wed, 23 Aug 2017 09:12:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNE79301; Wed, 23 Aug 2017 16:12:46 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 23 Aug 2017 17:12:45 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.148]) by SJCEML703-CHM.china.huawei.com ([169.254.5.62]) with mapi id 14.03.0301.000; Wed, 23 Aug 2017 09:12:37 -0700 From: Igor Bryskin To: "ietf@lmcontreras.com" , "teas@ietf.org" CC: "luismiguel.contrerasmurillo@telefonica.com" Thread-Topic: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework Thread-Index: AQHTHCSo9fTwQ80QMUSo/gKzfRNx06KSGtGQ Date: Wed, 23 Aug 2017 16:12:36 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909C3BACB@SJCEML702-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.599DA97E.006E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 14969bf3b03e47fc47010f32fcc662ef Archived-At: Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 16:12:53 -0000 Hi Luis, You said: " Section 5.1 describes a hierarchical connection of MDSCs that could be=20 interpreted as a way of resolving such SP interconnection. However, for=20 the interconnection of administrative domains interface MPI could not be=20 sufficient. Probably something in between MPI and CMI could be required." 1) Why MPI in this hierarchical case may not be sufficient? 2) What would prevent the upper level MDSC from using both MPI and CMI (if = necessary) when talking to a serving MDSC? Cheers, Igor -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of ietf@lmcontreras.com Sent: Wednesday, August 23, 2017 11:29 AM To: teas@ietf.org Cc: luismiguel.contrerasmurillo@telefonica.com Subject: [Teas] About interconnecting Multiple Administrative domains in dr= aft-ietf-teas-actn-framework Hi all, these days I have gone through both draft-ietf-teas-actn-framework. The=20 multi-domain case is one of the scenarios covered by the draft, however=20 I think it requires further elaboration in certain aspects, basically=20 having in mind the case of interconnecting different administrative=20 domains. As per Figure 2, a Customer can request to a Service Provider a Virtual=20 Network Service (VNS). The Service Provider can satisfy such request by=20 its own if it has Access to a number of Network Providers as reflected=20 in the figure. The scenario I'm referring to would be the one in which=20 the Service Provider (let's call it SP1) cannot honor the Customer=20 request by its own but requires some capabilities offered by another=20 Service Provider (SP2 in this case). Mapping Figure 2 to Figure 3 (functional view of the ACTN architecture)=20 we have the Customer Network Controller (CNC) in the Customer side, the=20 Multi Domain Service Coordinator (MDSC) in the Service Provider side,=20 and the Physical Network Controller (PNC) in the Network Provider side.=20 The interfaces used are CMI between CNC and MDSC, and MPI between MDSC=20 and PNC. CMI conveys service related information, while MPI conveys more=20 detailed network/technology related information. As it is described now in the draft, the MDSC is the one in charged of=20 the multi-domain Coordination by coordinating the PNCs of the Network=20 Providers below. However there is no detail about the potential=20 Coordination with another Service Provider that could be necessary for=20 providing the VNS to the Customer. Section 5.1 describes a hierarchical connection of MDSCs that could be=20 interpreted as a way of resolving such SP interconnection. However, for=20 the interconnection of administrative domains interface MPI could not be=20 sufficient. Probably something in between MPI and CMI could be required. So my proposal here would be the definition of a new interface, MMI,=20 between MDSCs pertaining to different administrative domains. That=20 interface conveys in principle service related information, and to some=20 extent it could have as well network/technology related information,=20 depending on the level of trustiness between SP1 and SP2. What do you think? Best regards Luis --=20 ___________________________________________ Luis M. Contreras ietf@lmcontreras.com luismiguel.contrerasmurillo@telefonica.com _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Wed Aug 23 14:01:22 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85841326F7 for ; Wed, 23 Aug 2017 14:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLUPCcFbiWdf for ; Wed, 23 Aug 2017 14:01:17 -0700 (PDT) Received: from 15.mo5.mail-out.ovh.net (15.mo5.mail-out.ovh.net [178.33.107.29]) (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 72D1A126BFD for ; Wed, 23 Aug 2017 14:01:16 -0700 (PDT) Received: from player695.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id C079011E8C1 for ; Wed, 23 Aug 2017 23:01:14 +0200 (CEST) Received: from RCM-ns3048766.ip-151-80-29.eu (7.red-83-35-46.dynamicip.rima-tde.net [83.35.46.7]) (Authenticated sender: ietf@lmcontreras.com) by player695.ha.ovh.net (Postfix) with ESMTPSA id 5017A460074; Wed, 23 Aug 2017 23:01:11 +0200 (CEST) Received: from 7.red-83-35-46.dynamicip.rima-tde.net ([83.35.46.7]) by mail.ovh.net with HTTP (HTTP/1.1 POST); Wed, 23 Aug 2017 23:01:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 Aug 2017 23:01:11 +0200 From: ietf@lmcontreras.com To: Leeyoung Cc: teas@ietf.org, luismiguel.contrerasmurillo@telefonica.com In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172B404992@SJCEML702-CHM.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E172B404992@SJCEML702-CHM.china.huawei.com> Message-ID: <007742f853bec8376cbde5e0c7716c54@lmcontreras.com> X-Sender: ietf@lmcontreras.com User-Agent: Roundcube Webmail/1.3.0 X-Originating-IP: 83.35.46.7 X-Webmail-UserID: ietf@lmcontreras.com X-Ovh-Tracer-Id: 17084968140401754040 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelledrtdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 21:01:21 -0000 Hi Young, thanks for the clarification. As you point out, yes, probably this can be handled as a special case of MPI. Maybe such details can be elaborated later on (I mean, in a separated document) in order to identify the specificities of this case where some Business aspects could be required to be supported as well. Best regards Luis On 2017-08-23 18:11, Leeyoung wrote: > Hi Miguel, > > Thanks for sharing your thought. As you pointed out, Section 5.1 > describes an advanced case of a hierarchy of MDSCs. We did not intend > to describe the case where two different/independent SPs are > interconnected with the top MDSC. This advanced form of MDSC hierarchy > is intended for one network provider to scale their networks. If the > two SPs are trusted entities to each other constituting multi-domain > under the same administration forming the MDSC hierarchy, this can be > supported with the current model. As pointed out in Figure 3, CMI is > the business boundary that separates customer and the network provider > and anything under the MDSC is assumed to be under one the same > business entity (i.e., trusted domain under the same administration). > > In any case, we regard MDSC-MDSC as a special case of MPI rather than > defining a separate interface called MMI (although we originally > considered this interface). > > Hope this helps. > > Best regards, > Young > > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of > ietf@lmcontreras.com > Sent: Wednesday, August 23, 2017 10:29 AM > To: teas@ietf.org > Cc: luismiguel.contrerasmurillo@telefonica.com > Subject: [Teas] About interconnecting Multiple Administrative domains > in draft-ietf-teas-actn-framework > > Hi all, > > these days I have gone through both draft-ietf-teas-actn-framework. > The multi-domain case is one of the scenarios covered by the draft, > however I think it requires further elaboration in certain aspects, > basically having in mind the case of interconnecting different > administrative domains. > > As per Figure 2, a Customer can request to a Service Provider a > Virtual Network Service (VNS). The Service Provider can satisfy such > request by its own if it has Access to a number of Network Providers > as reflected in the figure. The scenario I'm referring to would be the > one in which the Service Provider (let's call it SP1) cannot honor the > Customer request by its own but requires some capabilities offered by > another Service Provider (SP2 in this case). > > Mapping Figure 2 to Figure 3 (functional view of the ACTN > architecture) we have the Customer Network Controller (CNC) in the > Customer side, the Multi Domain Service Coordinator (MDSC) in the > Service Provider side, and the Physical Network Controller (PNC) in > the Network Provider side. > The interfaces used are CMI between CNC and MDSC, and MPI between MDSC > and PNC. CMI conveys service related information, while MPI conveys > more detailed network/technology related information. > > As it is described now in the draft, the MDSC is the one in charged of > the multi-domain Coordination by coordinating the PNCs of the Network > Providers below. However there is no detail about the potential > Coordination with another Service Provider that could be necessary for > providing the VNS to the Customer. > > Section 5.1 describes a hierarchical connection of MDSCs that could be > interpreted as a way of resolving such SP interconnection. However, > for the interconnection of administrative domains interface MPI could > not be sufficient. Probably something in between MPI and CMI could be > required. > > So my proposal here would be the definition of a new interface, MMI, > between MDSCs pertaining to different administrative domains. That > interface conveys in principle service related information, and to > some extent it could have as well network/technology related > information, depending on the level of trustiness between SP1 and SP2. > > What do you think? > > Best regards > > > Luis > > > -- > ___________________________________________ > > Luis M. Contreras > ietf@lmcontreras.com > luismiguel.contrerasmurillo@telefonica.com > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas -- ___________________________________________ Luis M. Contreras ietf@lmcontreras.com luismiguel.contrerasmurillo@telefonica.com From nobody Wed Aug 23 14:06:57 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81001329E6 for ; Wed, 23 Aug 2017 14:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTHgRCDocu91 for ; Wed, 23 Aug 2017 14:06:53 -0700 (PDT) Received: from 20.mo7.mail-out.ovh.net (20.mo7.mail-out.ovh.net [46.105.49.208]) (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 6553B126BFD for ; Wed, 23 Aug 2017 14:06:53 -0700 (PDT) Received: from player788.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 885646818C for ; Wed, 23 Aug 2017 23:06:51 +0200 (CEST) Received: from RCM-ns3048766.ip-151-80-29.eu (7.red-83-35-46.dynamicip.rima-tde.net [83.35.46.7]) (Authenticated sender: ietf@lmcontreras.com) by player788.ha.ovh.net (Postfix) with ESMTPSA id CAE5E18007F; Wed, 23 Aug 2017 23:06:47 +0200 (CEST) Received: from 7.red-83-35-46.dynamicip.rima-tde.net ([83.35.46.7]) by mail.ovh.net with HTTP (HTTP/1.1 POST); Wed, 23 Aug 2017 23:06:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 Aug 2017 23:06:47 +0200 From: ietf@lmcontreras.com To: Igor Bryskin Cc: teas@ietf.org, luismiguel.contrerasmurillo@telefonica.com In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863909C3BACB@SJCEML702-CHM.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD007863909C3BACB@SJCEML702-CHM.china.huawei.com> Message-ID: X-Sender: ietf@lmcontreras.com User-Agent: Roundcube Webmail/1.3.0 X-Originating-IP: 83.35.46.7 X-Webmail-UserID: ietf@lmcontreras.com X-Ovh-Tracer-Id: 17179825206515220305 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelledrtdefgddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Archived-At: Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 21:06:56 -0000 Hi Igor, please, see my comments in-line On 2017-08-23 18:12, Igor Bryskin wrote: > Hi Luis, > > You said: > " Section 5.1 describes a hierarchical connection of MDSCs that could > be > interpreted as a way of resolving such SP interconnection. However, for > the interconnection of administrative domains interface MPI could not > be > sufficient. Probably something in between MPI and CMI could be > required." > > 1) Why MPI in this hierarchical case may not be sufficient? lmcm>> some Business and service related information is probably needed in that case, so it could be needed to complement MPI with such kind of information > 2) What would prevent the upper level MDSC from using both MPI and CMI > (if necessary) when talking to a serving MDSC? > lmcm>> I acknowledge this could be an option. Probably the details can be worked out in a different document either with this option, with the option of complementing MPI to some extent with Business and service information, or by complementing CMI with network/technology/resource information. In any case, maybe the best is to move forward the framework document and explore this alternatives in another document/effort. Thanks again for the feedback Best regards Luis > Cheers, > Igor > > > > > > > > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of > ietf@lmcontreras.com > Sent: Wednesday, August 23, 2017 11:29 AM > To: teas@ietf.org > Cc: luismiguel.contrerasmurillo@telefonica.com > Subject: [Teas] About interconnecting Multiple Administrative domains > in draft-ietf-teas-actn-framework > > Hi all, > > these days I have gone through both draft-ietf-teas-actn-framework. The > multi-domain case is one of the scenarios covered by the draft, however > I think it requires further elaboration in certain aspects, basically > having in mind the case of interconnecting different administrative > domains. > > As per Figure 2, a Customer can request to a Service Provider a Virtual > Network Service (VNS). The Service Provider can satisfy such request by > its own if it has Access to a number of Network Providers as reflected > in the figure. The scenario I'm referring to would be the one in which > the Service Provider (let's call it SP1) cannot honor the Customer > request by its own but requires some capabilities offered by another > Service Provider (SP2 in this case). > > Mapping Figure 2 to Figure 3 (functional view of the ACTN architecture) > we have the Customer Network Controller (CNC) in the Customer side, the > Multi Domain Service Coordinator (MDSC) in the Service Provider side, > and the Physical Network Controller (PNC) in the Network Provider side. > The interfaces used are CMI between CNC and MDSC, and MPI between MDSC > and PNC. CMI conveys service related information, while MPI conveys > more > detailed network/technology related information. > > As it is described now in the draft, the MDSC is the one in charged of > the multi-domain Coordination by coordinating the PNCs of the Network > Providers below. However there is no detail about the potential > Coordination with another Service Provider that could be necessary for > providing the VNS to the Customer. > > Section 5.1 describes a hierarchical connection of MDSCs that could be > interpreted as a way of resolving such SP interconnection. However, for > the interconnection of administrative domains interface MPI could not > be > sufficient. Probably something in between MPI and CMI could be > required. > > So my proposal here would be the definition of a new interface, MMI, > between MDSCs pertaining to different administrative domains. That > interface conveys in principle service related information, and to some > extent it could have as well network/technology related information, > depending on the level of trustiness between SP1 and SP2. > > What do you think? > > Best regards > > > Luis -- ___________________________________________ Luis M. Contreras ietf@lmcontreras.com luismiguel.contrerasmurillo@telefonica.com From nobody Wed Aug 23 14:42:07 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93751132A13 for ; Wed, 23 Aug 2017 14:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_WWN-TUkVJ6 for ; Wed, 23 Aug 2017 14:42:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DA6132A20 for ; Wed, 23 Aug 2017 14:41:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNF10156; Wed, 23 Aug 2017 21:41:52 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 23 Aug 2017 22:41:51 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.148]) by SJCEML701-CHM.china.huawei.com ([169.254.3.191]) with mapi id 14.03.0301.000; Wed, 23 Aug 2017 14:41:47 -0700 From: Igor Bryskin To: "ietf@lmcontreras.com" CC: "teas@ietf.org" , "luismiguel.contrerasmurillo@telefonica.com" Thread-Topic: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework Thread-Index: AQHTHCSo9fTwQ80QMUSo/gKzfRNx06KSGtGQgADJtID//43qQA== Date: Wed, 23 Aug 2017 21:41:47 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909C3BEA7@SJCEML702-CHM.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD007863909C3BACB@SJCEML702-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.599DF6A1.003C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 14969bf3b03e47fc47010f32fcc662ef Archived-At: Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 21:42:05 -0000 Hi Luis, Please, see one more comment in-line. Igor -----Original Message----- From: ietf@lmcontreras.com [mailto:ietf@lmcontreras.com]=20 Sent: Wednesday, August 23, 2017 5:07 PM To: Igor Bryskin Cc: teas@ietf.org; luismiguel.contrerasmurillo@telefonica.com Subject: Re: [Teas] About interconnecting Multiple Administrative domains i= n draft-ietf-teas-actn-framework Hi Igor, please, see my comments in-line On 2017-08-23 18:12, Igor Bryskin wrote: > Hi Luis, >=20 > You said: > " Section 5.1 describes a hierarchical connection of MDSCs that could=20 > be > interpreted as a way of resolving such SP interconnection. However, for > the interconnection of administrative domains interface MPI could not=20 > be > sufficient. Probably something in between MPI and CMI could be=20 > required." >=20 > 1) Why MPI in this hierarchical case may not be sufficient? lmcm>> some Business and service related information is probably needed=20 in that case, so it could be needed to complement MPI with such kind of=20 information IB>> I agree, but upper level MDSC supposedly makes its decisions based on = abstract topologies provided by serving controllers such as lower level MDS= C. Why would this lower level MDSC announce, say, an abstract link to the h= igher level MDSC umless all business related stuff is sorted out between th= e two (perhaps via CMI), right?=20 The other point is that a client of a multi-domain network could be a clien= t of several such networks and hence could carry out the multi-network sync= hronization at its level without each of the serving MDSCs knowing anything= about that. I'd say that CMI and MPI are independent, and both or either of them could = be used regardless of each other. IMHO there is a need for a text in the do= cument elaborating on such scenarios, but there is no need for the special = case MPI. Cheers, Igor > 2) What would prevent the upper level MDSC from using both MPI and CMI > (if necessary) when talking to a serving MDSC? >=20 lmcm>> I acknowledge this could be an option. Probably the details can=20 be worked out in a different document either with this option, with the=20 option of complementing MPI to some extent with Business and service=20 information, or by complementing CMI with network/technology/resource=20 information. In any case, maybe the best is to move forward the framework document=20 and explore this alternatives in another document/effort. Thanks again for the feedback Best regards Luis > Cheers, > Igor >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of=20 > ietf@lmcontreras.com > Sent: Wednesday, August 23, 2017 11:29 AM > To: teas@ietf.org > Cc: luismiguel.contrerasmurillo@telefonica.com > Subject: [Teas] About interconnecting Multiple Administrative domains > in draft-ietf-teas-actn-framework >=20 > Hi all, >=20 > these days I have gone through both draft-ietf-teas-actn-framework. The > multi-domain case is one of the scenarios covered by the draft, however > I think it requires further elaboration in certain aspects, basically > having in mind the case of interconnecting different administrative > domains. >=20 > As per Figure 2, a Customer can request to a Service Provider a Virtual > Network Service (VNS). The Service Provider can satisfy such request by > its own if it has Access to a number of Network Providers as reflected > in the figure. The scenario I'm referring to would be the one in which > the Service Provider (let's call it SP1) cannot honor the Customer > request by its own but requires some capabilities offered by another > Service Provider (SP2 in this case). >=20 > Mapping Figure 2 to Figure 3 (functional view of the ACTN architecture) > we have the Customer Network Controller (CNC) in the Customer side, the > Multi Domain Service Coordinator (MDSC) in the Service Provider side, > and the Physical Network Controller (PNC) in the Network Provider side. > The interfaces used are CMI between CNC and MDSC, and MPI between MDSC > and PNC. CMI conveys service related information, while MPI conveys=20 > more > detailed network/technology related information. >=20 > As it is described now in the draft, the MDSC is the one in charged of > the multi-domain Coordination by coordinating the PNCs of the Network > Providers below. However there is no detail about the potential > Coordination with another Service Provider that could be necessary for > providing the VNS to the Customer. >=20 > Section 5.1 describes a hierarchical connection of MDSCs that could be > interpreted as a way of resolving such SP interconnection. However, for > the interconnection of administrative domains interface MPI could not=20 > be > sufficient. Probably something in between MPI and CMI could be=20 > required. >=20 > So my proposal here would be the definition of a new interface, MMI, > between MDSCs pertaining to different administrative domains. That > interface conveys in principle service related information, and to some > extent it could have as well network/technology related information, > depending on the level of trustiness between SP1 and SP2. >=20 > What do you think? >=20 > Best regards >=20 >=20 > Luis --=20 ___________________________________________ Luis M. Contreras ietf@lmcontreras.com luismiguel.contrerasmurillo@telefonica.com From nobody Wed Aug 23 14:45:46 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26565132A17 for ; Wed, 23 Aug 2017 14:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlQNnlkJPXUH for ; Wed, 23 Aug 2017 14:45:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AA7132A04 for ; Wed, 23 Aug 2017 14:45:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUA52764; Wed, 23 Aug 2017 21:45:36 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 23 Aug 2017 22:45:35 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.148]) by SJCEML703-CHM.china.huawei.com ([169.254.5.62]) with mapi id 14.03.0301.000; Wed, 23 Aug 2017 14:45:27 -0700 From: Leeyoung To: "ietf@lmcontreras.com" CC: "teas@ietf.org" , "luismiguel.contrerasmurillo@telefonica.com" Thread-Topic: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework Thread-Index: AQHTHCSon3ogMDdj90GD2JWXcbt3zqKSFcJggADNMoD//5X+cA== Date: Wed, 23 Aug 2017 21:45:26 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B404AF6@SJCEML702-CHM.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E172B404992@SJCEML702-CHM.china.huawei.com> <007742f853bec8376cbde5e0c7716c54@lmcontreras.com> In-Reply-To: <007742f853bec8376cbde5e0c7716c54@lmcontreras.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.599DF781.0003, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d1a1559b744227637a34bd5f72656452 Archived-At: Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 21:45:45 -0000 Hi Luis, Yes, multiple administrative domains is currently out of the ACTN scope.=20 Thanks. young -----Original Message----- From: ietf@lmcontreras.com [mailto:ietf@lmcontreras.com]=20 Sent: Wednesday, August 23, 2017 4:01 PM To: Leeyoung Cc: teas@ietf.org; luismiguel.contrerasmurillo@telefonica.com Subject: Re: [Teas] About interconnecting Multiple Administrative domains i= n draft-ietf-teas-actn-framework Hi Young, thanks for the clarification. As you point out, yes, probably this can be h= andled as a special case of MPI. Maybe such details can be elaborated later= on (I mean, in a separated document) in order to identify the specificitie= s of this case where some Business aspects could be required to be supporte= d as well. Best regards Luis On 2017-08-23 18:11, Leeyoung wrote: > Hi Miguel, >=20 > Thanks for sharing your thought. As you pointed out, Section 5.1=20 > describes an advanced case of a hierarchy of MDSCs. We did not intend=20 > to describe the case where two different/independent SPs are=20 > interconnected with the top MDSC. This advanced form of MDSC hierarchy=20 > is intended for one network provider to scale their networks. If the=20 > two SPs are trusted entities to each other constituting multi-domain=20 > under the same administration forming the MDSC hierarchy, this can be=20 > supported with the current model. As pointed out in Figure 3, CMI is=20 > the business boundary that separates customer and the network provider=20 > and anything under the MDSC is assumed to be under one the same=20 > business entity (i.e., trusted domain under the same administration). >=20 > In any case, we regard MDSC-MDSC as a special case of MPI rather than=20 > defining a separate interface called MMI (although we originally=20 > considered this interface). >=20 > Hope this helps. >=20 > Best regards, > Young >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of=20 > ietf@lmcontreras.com > Sent: Wednesday, August 23, 2017 10:29 AM > To: teas@ietf.org > Cc: luismiguel.contrerasmurillo@telefonica.com > Subject: [Teas] About interconnecting Multiple Administrative domains=20 > in draft-ietf-teas-actn-framework >=20 > Hi all, >=20 > these days I have gone through both draft-ietf-teas-actn-framework. > The multi-domain case is one of the scenarios covered by the draft,=20 > however I think it requires further elaboration in certain aspects,=20 > basically having in mind the case of interconnecting different=20 > administrative domains. >=20 > As per Figure 2, a Customer can request to a Service Provider a=20 > Virtual Network Service (VNS). The Service Provider can satisfy such=20 > request by its own if it has Access to a number of Network Providers=20 > as reflected in the figure. The scenario I'm referring to would be the=20 > one in which the Service Provider (let's call it SP1) cannot honor the=20 > Customer request by its own but requires some capabilities offered by=20 > another Service Provider (SP2 in this case). >=20 > Mapping Figure 2 to Figure 3 (functional view of the ACTN > architecture) we have the Customer Network Controller (CNC) in the=20 > Customer side, the Multi Domain Service Coordinator (MDSC) in the=20 > Service Provider side, and the Physical Network Controller (PNC) in=20 > the Network Provider side. > The interfaces used are CMI between CNC and MDSC, and MPI between MDSC=20 > and PNC. CMI conveys service related information, while MPI conveys=20 > more detailed network/technology related information. >=20 > As it is described now in the draft, the MDSC is the one in charged of=20 > the multi-domain Coordination by coordinating the PNCs of the Network=20 > Providers below. However there is no detail about the potential=20 > Coordination with another Service Provider that could be necessary for=20 > providing the VNS to the Customer. >=20 > Section 5.1 describes a hierarchical connection of MDSCs that could be=20 > interpreted as a way of resolving such SP interconnection. However,=20 > for the interconnection of administrative domains interface MPI could=20 > not be sufficient. Probably something in between MPI and CMI could be=20 > required. >=20 > So my proposal here would be the definition of a new interface, MMI,=20 > between MDSCs pertaining to different administrative domains. That=20 > interface conveys in principle service related information, and to=20 > some extent it could have as well network/technology related=20 > information, depending on the level of trustiness between SP1 and SP2. >=20 > What do you think? >=20 > Best regards >=20 >=20 > Luis >=20 >=20 > -- > ___________________________________________ >=20 > Luis M. Contreras > ietf@lmcontreras.com > luismiguel.contrerasmurillo@telefonica.com >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas -- ___________________________________________ Luis M. Contreras ietf@lmcontreras.com luismiguel.contrerasmurillo@telefonica.com From nobody Wed Aug 23 14:54:23 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4980C132A22 for ; Wed, 23 Aug 2017 14:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7llQ0AHqdE8H for ; Wed, 23 Aug 2017 14:54:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11345132A1E for ; Wed, 23 Aug 2017 14:54:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNF11153; Wed, 23 Aug 2017 21:54:16 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 23 Aug 2017 22:54:15 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.148]) by SJCEML703-CHM.china.huawei.com ([169.254.5.62]) with mapi id 14.03.0301.000; Wed, 23 Aug 2017 14:54:07 -0700 From: Igor Bryskin To: Leeyoung , "ietf@lmcontreras.com" CC: "luismiguel.contrerasmurillo@telefonica.com" , "teas@ietf.org" Thread-Topic: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework Thread-Index: AQHTHCSo9fTwQ80QMUSo/gKzfRNx06KSkgIAgABQ8oCAAAxeAP//i2pQ Date: Wed, 23 Aug 2017 21:54:06 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909C3BED4@SJCEML702-CHM.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E172B404992@SJCEML702-CHM.china.huawei.com> <007742f853bec8376cbde5e0c7716c54@lmcontreras.com> <7AEB3D6833318045B4AE71C2C87E8E172B404AF6@SJCEML702-CHM.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172B404AF6@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.599DF988.017C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 14969bf3b03e47fc47010f32fcc662ef Archived-At: Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 21:54:21 -0000 Young, A client of a single administrative domain network could be a client of mul= tiple such networks and perform service synchronization across them at its = own level using existing ACTN CMI and MPI as they are, right? So what then = is missing? Igor -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Leeyoung Sent: Wednesday, August 23, 2017 5:45 PM To: ietf@lmcontreras.com Cc: luismiguel.contrerasmurillo@telefonica.com; teas@ietf.org Subject: Re: [Teas] About interconnecting Multiple Administrative domains i= n draft-ietf-teas-actn-framework Hi Luis, Yes, multiple administrative domains is currently out of the ACTN scope.=20 Thanks. young -----Original Message----- From: ietf@lmcontreras.com [mailto:ietf@lmcontreras.com]=20 Sent: Wednesday, August 23, 2017 4:01 PM To: Leeyoung Cc: teas@ietf.org; luismiguel.contrerasmurillo@telefonica.com Subject: Re: [Teas] About interconnecting Multiple Administrative domains i= n draft-ietf-teas-actn-framework Hi Young, thanks for the clarification. As you point out, yes, probably this can be h= andled as a special case of MPI. Maybe such details can be elaborated later= on (I mean, in a separated document) in order to identify the specificitie= s of this case where some Business aspects could be required to be supporte= d as well. Best regards Luis On 2017-08-23 18:11, Leeyoung wrote: > Hi Miguel, >=20 > Thanks for sharing your thought. As you pointed out, Section 5.1=20 > describes an advanced case of a hierarchy of MDSCs. We did not intend=20 > to describe the case where two different/independent SPs are=20 > interconnected with the top MDSC. This advanced form of MDSC hierarchy=20 > is intended for one network provider to scale their networks. If the=20 > two SPs are trusted entities to each other constituting multi-domain=20 > under the same administration forming the MDSC hierarchy, this can be=20 > supported with the current model. As pointed out in Figure 3, CMI is=20 > the business boundary that separates customer and the network provider=20 > and anything under the MDSC is assumed to be under one the same=20 > business entity (i.e., trusted domain under the same administration). >=20 > In any case, we regard MDSC-MDSC as a special case of MPI rather than=20 > defining a separate interface called MMI (although we originally=20 > considered this interface). >=20 > Hope this helps. >=20 > Best regards, > Young >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of=20 > ietf@lmcontreras.com > Sent: Wednesday, August 23, 2017 10:29 AM > To: teas@ietf.org > Cc: luismiguel.contrerasmurillo@telefonica.com > Subject: [Teas] About interconnecting Multiple Administrative domains=20 > in draft-ietf-teas-actn-framework >=20 > Hi all, >=20 > these days I have gone through both draft-ietf-teas-actn-framework. > The multi-domain case is one of the scenarios covered by the draft,=20 > however I think it requires further elaboration in certain aspects,=20 > basically having in mind the case of interconnecting different=20 > administrative domains. >=20 > As per Figure 2, a Customer can request to a Service Provider a=20 > Virtual Network Service (VNS). The Service Provider can satisfy such=20 > request by its own if it has Access to a number of Network Providers=20 > as reflected in the figure. The scenario I'm referring to would be the=20 > one in which the Service Provider (let's call it SP1) cannot honor the=20 > Customer request by its own but requires some capabilities offered by=20 > another Service Provider (SP2 in this case). >=20 > Mapping Figure 2 to Figure 3 (functional view of the ACTN > architecture) we have the Customer Network Controller (CNC) in the=20 > Customer side, the Multi Domain Service Coordinator (MDSC) in the=20 > Service Provider side, and the Physical Network Controller (PNC) in=20 > the Network Provider side. > The interfaces used are CMI between CNC and MDSC, and MPI between MDSC=20 > and PNC. CMI conveys service related information, while MPI conveys=20 > more detailed network/technology related information. >=20 > As it is described now in the draft, the MDSC is the one in charged of=20 > the multi-domain Coordination by coordinating the PNCs of the Network=20 > Providers below. However there is no detail about the potential=20 > Coordination with another Service Provider that could be necessary for=20 > providing the VNS to the Customer. >=20 > Section 5.1 describes a hierarchical connection of MDSCs that could be=20 > interpreted as a way of resolving such SP interconnection. However,=20 > for the interconnection of administrative domains interface MPI could=20 > not be sufficient. Probably something in between MPI and CMI could be=20 > required. >=20 > So my proposal here would be the definition of a new interface, MMI,=20 > between MDSCs pertaining to different administrative domains. That=20 > interface conveys in principle service related information, and to=20 > some extent it could have as well network/technology related=20 > information, depending on the level of trustiness between SP1 and SP2. >=20 > What do you think? >=20 > Best regards >=20 >=20 > Luis >=20 >=20 > -- > ___________________________________________ >=20 > Luis M. Contreras > ietf@lmcontreras.com > luismiguel.contrerasmurillo@telefonica.com >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas -- ___________________________________________ Luis M. Contreras ietf@lmcontreras.com luismiguel.contrerasmurillo@telefonica.com _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Wed Aug 23 15:45:05 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C084132A54 for ; Wed, 23 Aug 2017 15:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-sjQqhc8TdV for ; Wed, 23 Aug 2017 15:45:01 -0700 (PDT) Received: from 11.mo5.mail-out.ovh.net (11.mo5.mail-out.ovh.net [46.105.47.167]) (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 EAEDC132A53 for ; Wed, 23 Aug 2017 15:45:00 -0700 (PDT) Received: from player799.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id D062511B48F for ; Thu, 24 Aug 2017 00:44:58 +0200 (CEST) Received: from RCM-ns3048766.ip-151-80-29.eu (7.red-83-35-46.dynamicip.rima-tde.net [83.35.46.7]) (Authenticated sender: ietf@lmcontreras.com) by player799.ha.ovh.net (Postfix) with ESMTPSA id 88C08520079; Thu, 24 Aug 2017 00:44:55 +0200 (CEST) Received: from 7.red-83-35-46.dynamicip.rima-tde.net ([83.35.46.7]) by mail.ovh.net with HTTP (HTTP/1.1 POST); Thu, 24 Aug 2017 00:44:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 24 Aug 2017 00:44:55 +0200 From: ietf@lmcontreras.com To: Igor Bryskin Cc: luismiguel.contrerasmurillo@telefonica.com, teas@ietf.org In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863909C3BEA7@SJCEML702-CHM.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD007863909C3BACB@SJCEML702-CHM.china.huawei.com> <0C72C38E7EBC34499E8A9E7DD007863909C3BEA7@SJCEML702-CHM.china.huawei.com> Message-ID: <1aa5b1fe421a3e2fd4e29b14a2166952@lmcontreras.com> X-Sender: ietf@lmcontreras.com User-Agent: Roundcube Webmail/1.3.0 X-Originating-IP: 83.35.46.7 X-Webmail-UserID: ietf@lmcontreras.com X-Ovh-Tracer-Id: 390124317978869585 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelledrtdefgddvtdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Archived-At: Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 22:45:03 -0000 Hi Igor, please, see in-line: >> >> 1) Why MPI in this hierarchical case may not be sufficient? > > lmcm>> some Business and service related information is probably needed > in that case, so it could be needed to complement MPI with such kind of > information > > IB>> I agree, but upper level MDSC supposedly makes its decisions > based on abstract topologies provided by serving controllers such as > lower level MDSC. Why would this lower level MDSC announce, say, an > abstract link to the higher level MDSC umless all business related > stuff is sorted out between the two (perhaps via CMI), right? > lmcm>> I agree this is a potential way of proceeding. Maybe just saying in 5.1 that the hierarchical connection of MDSCs could require the support of CMI in case of connecting different administrative domains. On the other hand, as mentioned by Young, if the interconnection of multiple administrative domains is not in the scope, maybe such clarification about the support of CMI can be skipped by explicitly saying that multiple administrative domains are out of scope (then keeping just the comment about the recursive usage of MPI at that level). > The other point is that a client of a multi-domain network could be a > client of several such networks and hence could carry out the > multi-network synchronization at its level without each of the serving > MDSCs knowing anything about that. > lmcm>> This is valid when the Customer is aware of the multi-domain situation, i.e. it is able to interact with all the administrative domains and coordinate the actions, as you mention. However there could be other situations where the Customer is not aware of the multiple administrative domains, and this is resolved by the Service Provider that maintains the commercial relationship with the Customer. > I'd say that CMI and MPI are independent, and both or either of them > could be used regardless of each other. IMHO there is a need for a > text in the document elaborating on such scenarios, but there is no > need for the special case MPI. > lmcm>> If interconnection of multiple administrative domains is not in the scope of the framework document maybe this can be handled apart by a different document focusing on this topic. In that case different options and pros/cons for them could be considered, like the usage of CMI + MPI, or the extension of MPI. I personally like the option of exploring this problem leaving the framework document with its current scope, so I'm open to work on that. Best regards Luis -- ___________________________________________ Luis M. Contreras ietf@lmcontreras.com luismiguel.contrerasmurillo@telefonica.com From nobody Wed Aug 23 15:47:05 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BD3132A5A for ; Wed, 23 Aug 2017 15:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fHflqObIS7m for ; Wed, 23 Aug 2017 15:47:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55698132A54 for ; Wed, 23 Aug 2017 15:47:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUA57786; Wed, 23 Aug 2017 22:46:58 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 23 Aug 2017 23:46:57 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.148]) by SJCEML701-CHM.china.huawei.com ([169.254.3.191]) with mapi id 14.03.0301.000; Wed, 23 Aug 2017 15:46:45 -0700 From: Leeyoung To: Igor Bryskin , "ietf@lmcontreras.com" CC: "luismiguel.contrerasmurillo@telefonica.com" , "teas@ietf.org" Thread-Topic: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework Thread-Index: AQHTHCSon3ogMDdj90GD2JWXcbt3zqKSFcJggADNMoD//5X+cIAAeMsA//+YjPA= Date: Wed, 23 Aug 2017 22:46:45 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B404B70@SJCEML702-CHM.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E172B404992@SJCEML702-CHM.china.huawei.com> <007742f853bec8376cbde5e0c7716c54@lmcontreras.com> <7AEB3D6833318045B4AE71C2C87E8E172B404AF6@SJCEML702-CHM.china.huawei.com> <0C72C38E7EBC34499E8A9E7DD007863909C3BED4@SJCEML702-CHM.china.huawei.com> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863909C3BED4@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.599E05E3.00FF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d1a1559b744227637a34bd5f72656452 Archived-At: Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 22:47:04 -0000 Hi Igor, We did not consider this case; but it would just work well if some implemen= tation wants to do that.=20 Thanks, Young -----Original Message----- From: Igor Bryskin=20 Sent: Wednesday, August 23, 2017 4:54 PM To: Leeyoung ; ietf@lmcontreras.com Cc: luismiguel.contrerasmurillo@telefonica.com; teas@ietf.org Subject: RE: [Teas] About interconnecting Multiple Administrative domains i= n draft-ietf-teas-actn-framework Young, A client of a single administrative domain network could be a client of mul= tiple such networks and perform service synchronization across them at its = own level using existing ACTN CMI and MPI as they are, right? So what then = is missing? Igor -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Leeyoung Sent: Wednesday, August 23, 2017 5:45 PM To: ietf@lmcontreras.com Cc: luismiguel.contrerasmurillo@telefonica.com; teas@ietf.org Subject: Re: [Teas] About interconnecting Multiple Administrative domains i= n draft-ietf-teas-actn-framework Hi Luis, Yes, multiple administrative domains is currently out of the ACTN scope.=20 Thanks. young -----Original Message----- From: ietf@lmcontreras.com [mailto:ietf@lmcontreras.com] Sent: Wednesday, August 23, 2017 4:01 PM To: Leeyoung Cc: teas@ietf.org; luismiguel.contrerasmurillo@telefonica.com Subject: Re: [Teas] About interconnecting Multiple Administrative domains i= n draft-ietf-teas-actn-framework Hi Young, thanks for the clarification. As you point out, yes, probably this can be h= andled as a special case of MPI. Maybe such details can be elaborated later= on (I mean, in a separated document) in order to identify the specificitie= s of this case where some Business aspects could be required to be supporte= d as well. Best regards Luis On 2017-08-23 18:11, Leeyoung wrote: > Hi Miguel, >=20 > Thanks for sharing your thought. As you pointed out, Section 5.1=20 > describes an advanced case of a hierarchy of MDSCs. We did not intend=20 > to describe the case where two different/independent SPs are=20 > interconnected with the top MDSC. This advanced form of MDSC hierarchy=20 > is intended for one network provider to scale their networks. If the=20 > two SPs are trusted entities to each other constituting multi-domain=20 > under the same administration forming the MDSC hierarchy, this can be=20 > supported with the current model. As pointed out in Figure 3, CMI is=20 > the business boundary that separates customer and the network provider=20 > and anything under the MDSC is assumed to be under one the same=20 > business entity (i.e., trusted domain under the same administration). >=20 > In any case, we regard MDSC-MDSC as a special case of MPI rather than=20 > defining a separate interface called MMI (although we originally=20 > considered this interface). >=20 > Hope this helps. >=20 > Best regards, > Young >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of=20 > ietf@lmcontreras.com > Sent: Wednesday, August 23, 2017 10:29 AM > To: teas@ietf.org > Cc: luismiguel.contrerasmurillo@telefonica.com > Subject: [Teas] About interconnecting Multiple Administrative domains=20 > in draft-ietf-teas-actn-framework >=20 > Hi all, >=20 > these days I have gone through both draft-ietf-teas-actn-framework. > The multi-domain case is one of the scenarios covered by the draft,=20 > however I think it requires further elaboration in certain aspects,=20 > basically having in mind the case of interconnecting different=20 > administrative domains. >=20 > As per Figure 2, a Customer can request to a Service Provider a=20 > Virtual Network Service (VNS). The Service Provider can satisfy such=20 > request by its own if it has Access to a number of Network Providers=20 > as reflected in the figure. The scenario I'm referring to would be the=20 > one in which the Service Provider (let's call it SP1) cannot honor the=20 > Customer request by its own but requires some capabilities offered by=20 > another Service Provider (SP2 in this case). >=20 > Mapping Figure 2 to Figure 3 (functional view of the ACTN > architecture) we have the Customer Network Controller (CNC) in the=20 > Customer side, the Multi Domain Service Coordinator (MDSC) in the=20 > Service Provider side, and the Physical Network Controller (PNC) in=20 > the Network Provider side. > The interfaces used are CMI between CNC and MDSC, and MPI between MDSC=20 > and PNC. CMI conveys service related information, while MPI conveys=20 > more detailed network/technology related information. >=20 > As it is described now in the draft, the MDSC is the one in charged of=20 > the multi-domain Coordination by coordinating the PNCs of the Network=20 > Providers below. However there is no detail about the potential=20 > Coordination with another Service Provider that could be necessary for=20 > providing the VNS to the Customer. >=20 > Section 5.1 describes a hierarchical connection of MDSCs that could be=20 > interpreted as a way of resolving such SP interconnection. However,=20 > for the interconnection of administrative domains interface MPI could=20 > not be sufficient. Probably something in between MPI and CMI could be=20 > required. >=20 > So my proposal here would be the definition of a new interface, MMI,=20 > between MDSCs pertaining to different administrative domains. That=20 > interface conveys in principle service related information, and to=20 > some extent it could have as well network/technology related=20 > information, depending on the level of trustiness between SP1 and SP2. >=20 > What do you think? >=20 > Best regards >=20 >=20 > Luis >=20 >=20 > -- > ___________________________________________ >=20 > Luis M. Contreras > ietf@lmcontreras.com > luismiguel.contrerasmurillo@telefonica.com >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas -- ___________________________________________ Luis M. Contreras ietf@lmcontreras.com luismiguel.contrerasmurillo@telefonica.com _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Thu Aug 24 09:06:49 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F9F132BCD; Thu, 24 Aug 2017 09:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVYFoHgXdhFj; Thu, 24 Aug 2017 09:06:38 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E062E1329AF; Thu, 24 Aug 2017 09:06:37 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7OG6ZDg003905; Thu, 24 Aug 2017 17:06:35 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7OG6UP8003863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2017 17:06:34 +0100 Reply-To: From: "Adrian Farrel" To: "'Elwyn Davies'" , Cc: , , References: <150326246998.3553.16986401070448324505@ietfa.amsl.com> In-Reply-To: <150326246998.3553.16986401070448324505@ietfa.amsl.com> Date: Thu, 24 Aug 2017 17:06:24 +0100 Message-ID: <065c01d31cf2$f203e040$d60ba0c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKiBtCv3C99t92nP+D+64XFU4lwwKD1Yexw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23280.000 X-TM-AS-Result: No--18.487-10.0-31-10 X-imss-scan-details: No--18.487-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wvHkpkyUphL9MhomkrNJ+uzNQVzhfYY5ss3M E4JSKf6jwO0XmKlkN6h37jIEiVeZu9Sq6q0CYrH3t1AhvyEKdj4ZKp0SZ4P+dfkUT+PL07ed07z aVZEg+DPE51KUDhTqFI2Pte01jMa1F/Pivu+18V0ER9Ta+6BEXcMdI0UcXEHziJ71fA8tGWgc5Z b9Gn+Kyi9hoxU2ysWvwW0HcKZdPoK0S/LholNXqfzu9Lw9C7fAgHzgwy8qV5qdwU/qXYxHvI1Tb KWhjfzBVguChDYYg16S30HCTNLdYHFXLIFQlX/F+cKX6yCQ13vHeXKrbMIpAOouc5Rcf1B0wJLY AybWdAJoGq134T2nlFUtXMzbYTKJUJc+88wC0T5/n3z4qeww6ILLh2/Jcc7edEG7y+D7o5ARGoG JcaPeD0JXZnlGyrNBJJDVrEv2PB32fv0LTPfvM31UZSPvDstZ0i/hFXziUdOXcnNUa+aFRfcgZS +tipLVlZaHSIhaFDgBmvTbn2Br79a/jIZoZyKFSEQN/D/3cG4fXzVgO0hVqg2G3vz8l/IE8UfEo 6khbdimeRbQwHAp670jL1dNSkkWwQh6YUqfT5IwiJTf3kjwfX2/mTu5B5RIh6BE/IXc9Sjp6M2T fc1dC9itRFsTmvHsye0+js2lbAZ0VhcRz+glNvt3QgyOPXbLtmsMcVX5NwfHiAsZELoUA1J1Vsw qK55IVZOEYEsHFBv2RJd2bEUo1LcH1nZMbpOp9w4QVIZvk2J3T8gwfPR6+Zy1Yc8tPkV9R0u6by ldJV1QTSFNt6LQtapfKHXwH61nx94l9TkMZwueAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: Subject: Re: [Teas] Genart last call review of draft-ietf-teas-pce-central-control-03 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 16:06:42 -0000 Elwyn, Thanks for the review. > Summary: > Almost ready. I found this a well-written and mostly readily = comprehensible > document although it contains a couple of instances of unexplained = SDN/PCE > jargon (notably 'southbound'). My main concern is that the = archtecture > suggests that extensions to PCEP will a.s. be needed and implies that > mechanisms will be needed to provide multiple extensions but neither = specifies > detailed guidance as to how this might be done or points to work in = progress > that would provide this guidance. =20 I'm pretty sure that this architecture should not tell the protocol = designers how to do their jobs. So "detailed guidance" may be too much, = but Section 4 does give "Guidance for Solution Developers". Perhaps the simplest thing is to point at = draft-zhao-pce-pcep-extension-for-pce-controller which is where early = work on protocol extensions lives. It's not a working group document = (yet?) and it still has some issues, but I've changed OLD It is anticipated that new documents will be produced for each use case dependent on support and demand. Such documents will explain the use case and define the necessary protocol extensions. NEW It is anticipated that new documents (such as=20 [I-D.zhao-pce-pcep-extension-for-pce-controller]) will be produced for each use case dependent on support and demand. Such documents will explain the use case and define the necessary protocol = extensions. END > The implication of the statements in this > document are that an implementation or deployment might need to check = if > particlar extensions are implemented in communication partners and = also how to > behave if an unreconixed extension is received especially to avoid = possible > DoS. RFC 5440 already describes how to handle unknown protocol elements. = Additionally, the PCEP Open message allows for exchange of capabilities = information. We can make these points as: OLD The only work expected to be needed is extensions to existing PCEP messages to carry additional or specific information elements for the individual use cases, which maintain backward compatibility and do not impact existing PCEP deployments. Where possible, consistent with the general principles of how protocols are extended, any additions to the protocol should be made in a generic way such that they are open to use in a range of applications. NEW The only work expected to be needed is extensions to existing PCEP messages to carry additional or specific information elements for the individual use cases, which maintain backward compatibility and do not impact existing PCEP deployments. [RFC5440] already describes how legacy implementations handle unknown=20 PCEP extensions and how to use the PCEP Open message to indicate support for PCEP features. Where possible, consistent with the = general principles of how protocols are extended, any additions to the protocol should be made in a generic way such that they are open to use in a range of applications. END > The other minor issues are only just abve the level of nits. >=20 > Major issues: > None >=20 > Minor issues: >=20 > Abstract: The abstract is probably overlong. Ah, why use 3 words when 10 will do? RFC Ed suggests that up to 20 lines is OK. We have 21. I couldn't = immediately see anything gratuitously superfluous, so I'm leaving it as = is. > s1: RFC 4655 is itself an architecture that introduces the PCE. It = would be > helpful to explain that this document is an extension of the basic PCE > arcitecture except that it relies on the specific use of the PCEP for > intercommunication between architectural elements providing traffic = control and > routing whereas RFC 4655 does not assume any particular protocol. Hmmm. You're right. 4655 doesn't make protocol assumptions. In fact it = pre-dated the WG's choice of a protocol. Of course, since then PCEP has been adopted and is the de facto protocol = for PCE.=20 How about... OLD This document introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a southbound interface, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. NEW This document introduces the architecture for PCE as a central controller as an extension of the architecture described in [RFC4655] and assumes the continued use of PCEP as the protocol used between PCE and PCC. The document also examines the motivations and=20 applicability for PCEP as a southbound interface and introduces the=20 implications for the protocol used in this way. A PCE-based central=20 controller can simplify the processing of distributed control plane = by blending it with elements of SDN and without necessarily completely replacing it. END > s3.2: It would be desirable to reiterate the problem of = synchronization > mentioned in s2.1.2 which is relevant to all the high level functions. I agree that synchronization of "parallel" stateful PCEs is a very real = (and potentially hard) problem. I agree that this issue needs to be = exposed wherever the concept of parallel controllers is present. But how is this relevant to Section 3.2? I have added a paragraph to the bottom of Section 4 as... Note that protocol mechanisms to handle synchronization of state in parallel PCE-based controllers will also be required if parallel = controllers are used as described in Section 2.1.2. There is a discussion of = mechanisms to achieve PCE state synchronization in [I-D.ietf-pce-stateful-pce]. > s4: Since this document effectively gurantees that extensions to PCEP = will be > created and since RFC 5440 contains no extensibility = procedures/guidelines, it > seems to me that either this document should indicate how PCEP = extensions and > profiles are added to the base protocol or should point to a = (normative and > currently non-existent) document that updates RFC 5440 and defines how > extensions shoould be structured and provides ways for implementations = to > determine what is supported, if necessary. Actually (as above) I think 5440 does contain adequate procedures. Section 6.2 describes the exchange of capabilities. Section 6.9 handles receipt of unknown messages. Section 7.2 shows how objects are marked as mandatory to process of not = and goes on to describe processing of unknown objects. Section 7.1 describes how to handle unknown TLVs. > s5, para 2: The second part of this paragraph; > However, debate will rage over overall system security and the = opportunity > for attacks in an architecture with a central controller since the = network > can be vulnerable to denial of service attacks on the controller, = and the > forwarding system may be harmed by attacks on the messages sent to > individual NEs. In short, while the interactions with a PCE-based = controller > are not substantially different from those in any other SDN = architecture, > the security implications of SDN are still open for discussion. The = IRTF's > SDN Research Group (SDNRG) discussed this topic. > This text needs to be rewritten to be suitable for inclusion in an RFC = that is > a document of record. Oh. :-) We could (of course?) not hope to reach consensus one a number of issues = related to SDN. So we tried some weasel words. Apparently your BS = detector is functioning perfectly. How about something a little more definitive... However, an architecture with a central controller has a central point = of failure and this is also a security weakness since the network can be vulnerable to denial of service attacks on the controller. Similarly, the central = controller provides a focus for interception and modification of messages sent to individual NEs. In short, while the interactions with a PCE-based = controller are not substantially different to those in any other SDN architecture, the security implications of SDN have not been fully discussed or = described. Therefore, protocol and applicability work around solutions for this architecture must take proper account of these concerns. > s6: The PCE, depending on which of the aspects mentioned in s3 and = the > technology being managed (LSPs, transport paths, etc.) are involved in = a > particular imlemetation/deployment, will need to access the relevant = state > information in NEs and possibly other PCEs using relevant managent = protcol(s) > and MIBs or similar. Integrating this state information with the PCEP > management information wil be key to effective operation of the = centralized PCE > system. Is this any different from any other use of PCE, and especially stateful = PCE? I have added a note to highlight it. An implementation of a PCE-based controller will require access to = information about the state of the network, its nodes, and its links. Some of this will be the TED = as is normal for a PCE and can be collected using the mechanisms already in place (such as listening to = the IGPs, using BGP-LS [RFC7752], or northbound export of YANG-encoded data = [I-D.ietf-teas-yang-te-topo]. More information may be collected in the LSP database as described for = stateful PCEs as described=20 in [RFC7399] and [I-D.ietf-pce-stateful-pce]. Additional information = may be needed for other specific use cases and will need to be collected and passed to the = controller. > s10: It is arguable, IMO, that RFC 5440 and = I-D.ietf-pce-pce-initiated-lsp are > normative references. The architecture implies their usage and = someone > implementing the architecture would need to be familiar with the = details of the > extended PCEP, particularly in respect of the manageability and = security > aspects of the protocol. Sure. > Nits/editorial comments: >=20 > Abstract, para 1: Statements of implied omnipotence by mortals a.s. = lead to > hubristic consequences... s/any definition of "optimal"/virtually any > definition of "optimal"/ Hubris is in the eye of the whichever one of the gods is beholding us = today. s/any definition/most definitions/ > Abstract (and subseqently): The term 'southbound' is SDN specific = jargon and > should be explained. Given that the abstract is already (IMO) too = long, it > would be wise to remove it from the abstract (I don't think it is = essential) > and provide the explation in s1. Removed from Abstract. Added "(i.e., a control protocol for communicating from the central = controller to network elements)" to s1. > s1, para 4: See comment above... s/any form of routed or switched > network./virtually any form of routed or switched network./ Ditto above. > s2, para 2 and Figures 1-7: It would be useful to add a note in s2 to = indicate > that the TED box in all the figures should imply that other databases = may also > be accessed. OK. Added a note > s2, last para (just before Fig.3): s/use case- specific/use = case-specific [or > use case specific]/ Hmmm. An xml2rfc bug. Bypassed. > s2.1, para 1: The text at the beginning of the para doesn't read very = easily - > the 'or' disguises the fact that the two problems are on either sideof = the > 'or'. Suggest someting like:=20 >OLD: > Systems with central controllers are > vulnerable to two problems: failure or overload of the single = controller.=20 > NEW: > Systems with a single central controllers are vulnerable to two = problems: > - controller failure, and > - controller overload. > ENDS OK > s3.1.4, last para: > new protocol extensions may be needed, and some are already being = worked > on in [I-D.ietf-pce-wson-rwa-ext]. > The second clause of this is not future proof: Suggest > s/and some are already being worked on in = [I-D.ietf-pce-wson-rwa-ext]./as, for > example, described in [I-D.ietf-pce-wson-rwa-ext]./ OK > s3.1.5, para 1: s/the header or a packet/the header of a packet/ (I = think - > certainly for IPv6 use case) Ack > s3.2.2, last para: The final sentence is probably superfluous - and, = if it > remains, probably needs a reference to explain what a FEC is. What the FEC? Removed. Thanks again, Adrian From nobody Thu Aug 24 09:24:50 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A79341321AA; Thu, 24 Aug 2017 09:24:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150359188261.24375.3330605898650454722@ietfa.amsl.com> Date: Thu, 24 Aug 2017 09:24:42 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-pce-central-control-04.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 16:24:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : An Architecture for Use of PCE and PCEP in a Network with Central Control Authors : Adrian Farrel Quintin Zhao Robin Li Chao Zhou Filename : draft-ietf-teas-pce-central-control-04.txt Pages : 24 Date : 2017-08-24 Abstract: The Path Computation Element (PCE) has become established as a core component of Software Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network for most definitions of "optimal" and can also monitor changes in resource availability and traffic demands to update the paths. Conventionally, the PCE has been used to derive paths for MPLS Label Switched Paths (LSPs). These paths are supplied using the Path Computation Element Communication Protocol (PCEP) to the head end of the LSP for signaling in the MPLS network. SDN has a far broader applicability than just signaled MPLS traffic engineered networks, and the PCE may be used to determine paths in a wide range of use cases including static LSPs, segment routing, service function chaining (SFC), and indeed most forms of routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-pce-central-control-04 https://datatracker.ietf.org/doc/html/draft-ietf-teas-pce-central-control-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-pce-central-control-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 24 09:52:19 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A0613217D; Thu, 24 Aug 2017 09:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO6lwwjw57gW; Thu, 24 Aug 2017 09:52:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2D5126BF0; Thu, 24 Aug 2017 09:52:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7OGqBhQ029890; Thu, 24 Aug 2017 17:52:11 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7OGq0AJ029685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2017 17:52:00 +0100 Reply-To: From: "Adrian Farrel" To: Cc: , Date: Thu, 24 Aug 2017 17:51:54 +0100 Message-ID: <067e01d31cf9$50f00ce0$f2d026a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdMc99uitj0a2W3GRba43qeGd0NmwQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23280.001 X-TM-AS-Result: No--0.767-10.0-31-10 X-imss-scan-details: No--0.767-10.0-31-10 X-TMASE-MatchedRID: BVERrJw/NWxxzwb0rKc347mR+C0l9vjVA9UhA/EMrwNSc7qxuEmU/nYX jTxEWkwAz0aiq88H5tcYkIWWLQ+ruRgHZ8655DOPOX/V8P8ail3Yr6U3ZlQkdtmzcdRxL+xwKra uXd3MZDVoX8S1oEDAVcoVp/4u7fFsD7BfPvm7sRkJ1mEqEgl6tXBWrD2pegUwsJ/jxlXnd3dp9x HuM9AfUiKeUbONtgeTe1ZwdZI0d1+GWChB6AgT5w== Archived-At: Subject: [Teas] IETF last call on draft-ietf-teas-pce-central-control X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 16:52:18 -0000 Hi Deborah, Now that last call is over, here is a note to track changes made in response to the various reviews. RTG-Dir review from Julien Responded on 7/17 No changes arising OPS-Dir review from Tianran No changes suggested GEN-Art review from Elwyn Many small changes per email New revision posted. Back to you. Adrian From nobody Fri Aug 25 08:30:22 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7757A1321D8; Fri, 25 Aug 2017 08:30:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-teas-lsp-diversity@ietf.org, teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150367501539.19775.5475949027773148116.idtracker@ietfa.amsl.com> Date: Fri, 25 Aug 2017 08:30:15 -0700 Archived-At: Subject: [Teas] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-teas-lsp-diversity-08=3A_=28with_COMMENT=29?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 15:30:15 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-teas-lsp-diversity-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Maybe RFC4920 should be a normative reference (due to sec 1.1)? From nobody Fri Aug 25 09:08:58 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49533132C1E; Fri, 25 Aug 2017 09:08:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-teas-pce-central-control@ietf.org, Vishnu Beeram , teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150367733729.19686.3787564400476421032.idtracker@ietfa.amsl.com> Date: Fri, 25 Aug 2017 09:08:57 -0700 Archived-At: Subject: [Teas] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-teas-pce-central-control-04=3A_=28with_COMMENT=29?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 16:08:57 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-teas-pce-central-control-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a clearly written document. While reading the document, I also had a quick look at the teas charter and am wondering how this work is covered by the charter. This shouldn't stop publication, but maybe there is a need to update the charter, especially if more work in this space is expected. From nobody Fri Aug 25 13:18:15 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02021120721 for ; Fri, 25 Aug 2017 13:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alKDl2r2KIVp for ; Fri, 25 Aug 2017 13:18:12 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 1BC51124207 for ; Fri, 25 Aug 2017 13:18:12 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 474EF42B05 for ; Fri, 25 Aug 2017 14:11:43 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 1YBf1w00v2SSUrH01YBi3y; Fri, 25 Aug 2017 14:11:43 -0600 X-Authority-Analysis: v=2.2 cv=F98nTupN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc: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=CmDbLvfhJlgutTowrNmUm+p3gvhiaw83TEKWwPCcFLY=; b=vWlOeKtGtLuCLEW/LoIUWAR20J mVKFdrPPU4xRHU9uqCV1fwGUl3H7SKwnxH+ZRiI3keqwLg3C2Fxyl7+e5SoWvNDJwsa6Kgd6tkmI5 /h0d0EV2pOp1q4VMbdDDe9rEk; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:42206 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dlKx9-004Nid-9M; Fri, 25 Aug 2017 14:11:39 -0600 To: Xufeng Liu , Igor Bryskin , vbeeram@juniper.net, tsaad@cisco.com, hshah@ciena.com, OSCAR GONZALEZ DE DIOS , Italo.Busi@huawei.com, carlo.perocchio@ericsson.com, "Beller, Dieter (Nokia - DE)" , sergio.belotti@nokia.com, TEAS WG From: Lou Berger Message-ID: Date: Fri, 25 Aug 2017 16:11:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dlKx9-004Nid-9M X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:42206 X-Source-Auth: lberger@labn.net X-Email-Count: 14 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 20:18:14 -0000 Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, TEAS WG Chairs PS Please include all listed in the headers of this message in your response. From nobody Fri Aug 25 14:19:33 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E628E132C5E for ; Fri, 25 Aug 2017 14:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72B16-_5rVTz for ; Fri, 25 Aug 2017 14:19:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF72132C4B for ; Fri, 25 Aug 2017 14:19:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUE09810; Fri, 25 Aug 2017 21:19:27 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 25 Aug 2017 22:19:26 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.148]) by SJCEML703-CHM.china.huawei.com ([169.254.5.62]) with mapi id 14.03.0301.000; Fri, 25 Aug 2017 14:19:09 -0700 From: Igor Bryskin To: Lou Berger , Xufeng Liu , "vbeeram@juniper.net" , "tsaad@cisco.com" , "hshah@ciena.com" , "OSCAR GONZALEZ DE DIOS" , Italo Busi , "carlo.perocchio@ericsson.com" , "Beller, Dieter (Nokia - DE)" , "sergio.belotti@nokia.com" , TEAS WG Thread-Topic: Regarding IPR on draft-ietf-teas-yang-te-topo Thread-Index: AQHTHd54/AG5QCEBjU2gtOwYjxbFFKKVk1Gw Date: Fri, 25 Aug 2017 21:19:08 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909C3F462@SJCEML702-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.240] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59A0945F.01DB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4d57c8e5b70f2c7453c5f0bf47fb2fa1 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 21:19:32 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K DQpDaGVlcnMsDQpJZ29yDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3Ug QmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAy NSwgMjAxNyA0OjEyIFBNDQpUbzogWHVmZW5nIExpdTsgSWdvciBCcnlza2luOyB2YmVlcmFtQGp1 bmlwZXIubmV0OyB0c2FhZEBjaXNjby5jb207IGhzaGFoQGNpZW5hLmNvbTsgT1NDQVIgR09OWkFM RVogREUgRElPUzsgSXRhbG8gQnVzaTsgY2FybG8ucGVyb2NjaGlvQGVyaWNzc29uLmNvbTsgQmVs bGVyLCBEaWV0ZXIgKE5va2lhIC0gREUpOyBzZXJnaW8uYmVsb3R0aUBub2tpYS5jb207IFRFQVMg V0cNClN1YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdG9w bw0KDQpBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KDQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJh dGlvbiBmb3IgV0cgTGFzdCBDYWxsDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFw cGxpZXMgdG8gZHJhZnRzIGlkZW50aWZpZWQgYWJvdmU/DQoNClBsZWFzZSBzdGF0ZSBlaXRoZXI6 DQoNCiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRy YWZ0Ig0Kb3INCiJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJh ZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3 aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzY2OSwgNTM3OCBhbmQgODE3OSBmb3IgbW9y ZSBkZXRhaWxzKT8NCg0KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoN Cg0KIlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElF VEYgSVBSIHJ1bGVzIg0Kb3INCiJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0K DQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxz IHlvdSB0aGluaw0KYXBwcm9wcmlhdGUuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1l bnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3ZXIgdGhlDQphYm92ZSBieSByZXNw b25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJl DQphd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFu Y2UgdG8gdGhlIG5leHQNCnN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQg ZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkDQpjb250cmlidXRvci4gTk9URTogVEhJUyBBUFBM SUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdTDQpUTyBMSU5FUy4NCg0K SWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0 IGFyZSBub3QgbGlzdGVkDQphcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5 b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlcg0KdGhlIElFVEYgSVBSIHJ1bGVzIHdoaWNoIGVu Y291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlDQphd2FyZSBvZiBJUFIg b2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20NCnBh cnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8g eW91cg0KdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0 aGUgUkZDcyBsaXN0ZWQgYWJvdmUNCmFuZA0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3Jv dXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQoNClRoYW5rIHlvdSwNClRF QVMgV0cgQ2hhaXJzDQoNClBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRl cnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXINCnJlc3BvbnNlLg0KDQoNCg== From nobody Fri Aug 25 15:21:41 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA1A1323B8 for ; Fri, 25 Aug 2017 15:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33yQ5Mczh2rO for ; Fri, 25 Aug 2017 15:21:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6ED8132358 for ; Fri, 25 Aug 2017 15:21:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNI48471; Fri, 25 Aug 2017 22:21:35 +0000 (GMT) Received: from YYZEML703-CHM.china.huawei.com (10.218.33.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 25 Aug 2017 23:21:34 +0100 Received: from YYZEML701-CHM.china.huawei.com ([169.254.4.16]) by YYZEML703-CHM.china.huawei.com ([169.254.5.70]) with mapi id 14.03.0301.000; Fri, 25 Aug 2017 18:21:24 -0400 From: "Aihuaguo (Aihua Guo, CRC)" To: Lou Berger , Xufeng Liu , "Igor Bryskin" , "vbeeram@juniper.net" , "tsaad@cisco.com" , "hshah@ciena.com" , OSCAR GONZALEZ DE DIOS , Italo Busi , "carlo.perocchio@ericsson.com" , "Beller, Dieter (Nokia - DE)" , "sergio.belotti@nokia.com" , TEAS WG Thread-Topic: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo Thread-Index: AQHTHd9UJpCfwwnTFkO0QfIIZymr0KKVpNKA Date: Fri, 25 Aug 2017 22:21:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59A0A2EF.01A6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.16, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3743f567cd4ab347aa1c8021c94d9308 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 22:21:40 -0000 No, I'm not aware of any IPR that applies to this draft. Aihua -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, August 25, 2017 4:12 PM To: Xufeng Liu; Igor Bryskin; vbeeram@juniper.net; tsaad@cisco.com; hshah@c= iena.com; OSCAR GONZALEZ DE DIOS; Italo Busi; carlo.perocchio@ericsson.com;= Beller, Dieter (Nokia - DE); sergio.belotti@nokia.com; TEAS WG Subject: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until = a response has been received from each author and listed contributor. NOTE:= THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any = contribution or discussion related to your undisclosed IPR. For more inform= ation, please see the RFCs listed above and http://trac.tools.ietf.org/grou= p/iesg/trac/wiki/IntellectualProperty. Thank you, TEAS WG Chairs PS Please include all listed in the headers of this message in your respons= e. _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Fri Aug 25 23:26:24 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4697B132A11 for ; Fri, 25 Aug 2017 23:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7phGU03_WxJa for ; Fri, 25 Aug 2017 23:26:20 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00131.outbound.protection.outlook.com [40.107.0.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD2B132A0E for ; Fri, 25 Aug 2017 23:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dKjTAopuY3Vudyp5xkoHlO9BCkgIQkfXCrRMEv4MoZ4=; b=carN5um2oIgkBpX0el6dafilc0BYmypP9OHwgjwbuh/RZvo5VlCEDtMwNn/m561eNwX6ZyiEedR3iT/X++RCYPJaZK18Y9xLAU/c0a15ddfxLsf8bDUeI2CJpZOnEinPD7xgQcrsyGhL1v3hONF7nMA8ygAUPm+czNpIsV42YfM= Received: from AM5PR0701MB1825.eurprd07.prod.outlook.com (10.167.216.10) by AM5PR0701MB3025.eurprd07.prod.outlook.com (10.168.156.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Sat, 26 Aug 2017 06:26:17 +0000 Received: from AM5PR0701MB1825.eurprd07.prod.outlook.com ([fe80::f971:92dc:679e:c114]) by AM5PR0701MB1825.eurprd07.prod.outlook.com ([fe80::f971:92dc:679e:c114%14]) with mapi id 15.20.0013.005; Sat, 26 Aug 2017 06:26:15 +0000 From: "Beller, Dieter (Nokia - DE/Stuttgart)" To: Lou Berger , Xufeng Liu , "Igor Bryskin" , "vbeeram@juniper.net" , "tsaad@cisco.com" , "hshah@ciena.com" , OSCAR GONZALEZ DE DIOS , Italo Busi , "carlo.perocchio@ericsson.com" , "Belotti, Sergio (Nokia - IT/Vimercate)" , TEAS WG , "Aihuaguo (Aihua Guo, CRC)" Thread-Topic: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo Thread-Index: AQHTHd6niHIuQ2UKIEeP6LUIoSfmeqKVpTsAgACHeAM= Date: Sat, 26 Aug 2017 06:26:15 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [40.68.254.90] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB3025; 6:yKLomp8qdqh5iWU+/X+rTJ38sKSBCbS9ytJJ8pF7SnEOXj64fQxocXcUy6TpUOUPSlbDRW97JfYmbsYsJ6xvJNczb3ePln+iBIPur9eGHr8Rh7zR9Z5owc0ex+2mQvpOTjvUaFoBOarrDac8UDg0DWaC8OG7FP0VsX8WpPxsoDP7UeDb/D8fXi90DzxEbtRbz9dE03P3m8nQ+OHGPMtC3vHe0ExtfjcLiCLi21vbM/zlwGkpqw0FzFKJeDqb/r+z31X2a5hnoC4kIMqvEaWYBb0iexnuk/3gyFg25wWd15agrTTxI+RQQB6QrUxbCF0SXy2ZWN3nvfBkwENUOq08Mw==; 5:QFJGxcQIMPXi4+042rqCml1ZpB95U/fq8uDd/JuiWoEfV/pC++2St4z1JSdGhbYsDmcjvtZ79kN87y4bSLkZqWLzu5iGS7DWn6+oU7r0Og4Nc5ROetmK639Fd80i0+xkFETlg+i5G5xGOq8kf+Rtgg==; 24:1mrrL1i3ZZWdjOCz4567n6PC0LMZS+us50cBhDm4cuB/pnpAMMkZXLO8QnChWoI8fvuraCZxPHiJCA4l50ZK1H+bV+WmNIixFbBLg0/iPgs=; 7:ifjt7EbDjezq0kNqj8HyVx+lb0nCSXLTmwrNnko+kNFRIGfiPsXRhfMHW+oJDo0yKbkp96PAB7e+vxlD4+MMKLj6vw/5Ws6a4gNXz+QunuvCNWuP9ky6eNh+GSCiA9FzCG9cezB56ng3W/QFURAxKlYRYpcrkOgA6XoI1njW0fk8B1+IXFa37JNukGx9Xut91YZrkrpZeem6VOjNp/qksUSz+3OfFVVRWAqe+9J6jQI= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(377454003)(13464003)(199003)(189002)(6436002)(189998001)(1941001)(229853002)(6506006)(68736007)(2950100002)(14971765001)(5250100002)(2501003)(33656002)(478600001)(101416001)(6116002)(102836003)(3846002)(74316002)(966005)(230783001)(2201001)(7696004)(5660300001)(106356001)(14454004)(105586002)(236005)(9686003)(54896002)(6306002)(55016002)(99286003)(66066001)(8666007)(6246003)(53546010)(606006)(53936002)(7416002)(8676002)(25786009)(8936002)(7736002)(81156014)(81166006)(3660700001)(3280700002)(2900100001)(50986999)(86362001)(76176999)(54356999)(97736004)(2906002)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB3025; H:AM5PR0701MB1825.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 73c26438-13d2-4754-3e47-08d4ec4b5aed x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB3025; x-ms-traffictypediagnostic: AM5PR0701MB3025: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(50582790962513)(82608151540597)(95692535739014)(138986009662008); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB3025; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB3025; x-forefront-prvs: 04111BAC64 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=dieter.beller@nokia.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB1825CD475D0AD0590CF9F804E2980AM5PR0701MB1825_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2017 06:26:15.6563 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB3025 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 06:26:23 -0000 --_000_AM5PR0701MB1825CD475D0AD0590CF9F804E2980AM5PR0701MB1825_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft Thanks, Dieter ________________________________ From: Aihuaguo (Aihua Guo, CRC) Sent: Saturday, August 26, 2017 12:21:24 AM To: Lou Berger; Xufeng Liu; Igor Bryskin; vbeeram@juniper.net; tsaad@cisco.= com; hshah@ciena.com; OSCAR GONZALEZ DE DIOS; Italo Busi; carlo.perocchio@e= ricsson.com; Beller, Dieter (Nokia - DE/Stuttgart); Belotti, Sergio (Nokia = - IT/Vimercate); TEAS WG Subject: RE: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo No, I'm not aware of any IPR that applies to this draft. Aihua -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, August 25, 2017 4:12 PM To: Xufeng Liu; Igor Bryskin; vbeeram@juniper.net; tsaad@cisco.com; hshah@c= iena.com; OSCAR GONZALEZ DE DIOS; Italo Busi; carlo.perocchio@ericsson.com;= Beller, Dieter (Nokia - DE); sergio.belotti@nokia.com; TEAS WG Subject: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until = a response has been received from each author and listed contributor. NOTE:= THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any = contribution or discussion related to your undisclosed IPR. For more inform= ation, please see the RFCs listed above and http://trac.tools.ietf.org/grou= p/iesg/trac/wiki/IntellectualProperty. Thank you, TEAS WG Chairs PS Please include all listed in the headers of this message in your respons= e. _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_AM5PR0701MB1825CD475D0AD0590CF9F804E2980AM5PR0701MB1825_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
No, I'm not aware of any IPR that applies to this draft

Thanks,
Dieter
From: Aihuaguo (Aihua Guo= , CRC) <aihuaguo@huawei.com>
Sent: Saturday, August 26, 2017 12:21:24 AM
To: Lou Berger; Xufeng Liu; Igor Bryskin; vbeeram@juniper.net; tsaad= @cisco.com; hshah@ciena.com; OSCAR GONZALEZ DE DIOS; Italo Busi; carlo.pero= cchio@ericsson.com; Beller, Dieter (Nokia - DE/Stuttgart); Belotti, Sergio = (Nokia - IT/Vimercate); TEAS WG
Subject: RE: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo
 
No, I'm not aware of any IPR that applies to this = draft.

Aihua


-----Original Message-----
From: Teas [mailto:teas-bounces@ie= tf.org] On Behalf Of Lou Berger
Sent: Friday, August 25, 2017 4:12 PM
To: Xufeng Liu; Igor Bryskin; vbeeram@juniper.net; tsaad@cisco.com; hshah@c= iena.com; OSCAR GONZALEZ DE DIOS; Italo Busi; carlo.perocchio@ericsson.com;= Beller, Dieter (Nokia - DE); sergio.belotti@nokia.com; TEAS WG
Subject: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo

Authors, Contributors, WG,

As part of the preparation for WG Last Call

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropria= te.

If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until = a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTE= D IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any contribution or discussion related= to your undisclosed IPR. For more information, please see the RFCs listed = above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty<= /a>.

Thank you,
TEAS WG Chairs

PS Please include all listed in the headers of this message in your respons= e.


_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org= /mailman/listinfo/teas
 --_000_AM5PR0701MB1825CD475D0AD0590CF9F804E2980AM5PR0701MB1825_-- From nobody Sun Aug 27 15:03:15 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCF71320CF; Sun, 27 Aug 2017 15:03:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-teas-pce-central-control@ietf.org, Vishnu Beeram , teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150387138757.9798.12253471138493060140.idtracker@ietfa.amsl.com> Date: Sun, 27 Aug 2017 15:03:07 -0700 Archived-At: Subject: [Teas] Spencer Dawkins' Yes on draft-ietf-teas-pce-central-control-04: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 22:03:08 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-teas-pce-central-control-04: Yes 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This topic is not my area (duh, but I mean knowledge, not AD responsibility), and I learned enough to ballot Yes while reviewing. I find myself wondering why it’s more helpful than some other architecture drafts I’ve reviewed, and note that it’s also pretty close to a forward-looking applicability statement for PCE (re: https://tools.ietf.org/html/rfc2026#section-3.2). No action requested for this document, but something for ADs to think about, when we’re thinking about architecture documents in general. I did see a couple of places that were not as clear to me as most of the document was. In https://tools.ietf.org/html/draft-ietf-teas-pce-central-control-04#section-3.1.1, the description is short, which could be fine, but meant I was guessing at a lot of high-level details that I could dig out of https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-21 for myself, but it might be helpful to include a couple of points, like whether the PCCs in this technology are (always?) LSRs participating in the IGP (OSPF or IS-IS), and whether the PCEs are (always?) either LSRs or servers also participating in the IGP, and whether the IGP is (always?) used to set up LSPs, for readers who have a (G)MPLS or MPLS-TE network now, to figure out how it maps at a high level to what they already have. I’m guessing from https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-21#section-5.5, but I’m guessing. I’m not quite sure what to do with this part of the security considerations: In short, while the interactions with a PCE-based controller are not substantially different to those in any other SDN architecture, the security implications of SDN have not been fully discussed or described. Therefore, protocol and applicability work around solutions for this architecture must take proper account of these concerns. It is expected that each new document that is produced for a specific use case will also include considerations of the security impacts of the use of a PCE-based central controller on the network type and services being managed. If I’m reading this literally, it’s saying that we haven’t finished discussing SDN security considerations in general yet, so each new document will consider the security impact of a PCE-based central controller on the network type and services being managed as an SDN. Is that what was meant? If I’m reading the manageability considerations section correctly, perhaps it’s worth pointing out what the extension story is for the IGPs that will be used in some of the technologies discussed earlier in the document, if that’s part of this work as well. From nobody Sun Aug 27 18:55:10 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAD2132709; Sun, 27 Aug 2017 18:55:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-teas-lsp-diversity@ietf.org, teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150388530282.9943.6245697101970024623.idtracker@ietfa.amsl.com> Date: Sun, 27 Aug 2017 18:55:02 -0700 Archived-At: Subject: [Teas] Spencer Dawkins' No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 01:55:03 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-teas-lsp-diversity-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I’m looking at this text, 0x04 = Penultimate node exception Indicates that the penultimate node of the LSP being signaled MAY be shared with the excluded path even when this violates the exclusion flags. and wondering whether you could either provide some recommendation about doing this/not doing this, or give an example of why doing this/not doing this makes operational sense. The other exceptions do make sense to me, so I’m only curious about this one. From nobody Mon Aug 28 03:40:38 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796D4132A8F for ; Mon, 28 Aug 2017 03:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.601 X-Spam-Level: X-Spam-Status: No, score=-12.601 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biYS-S3gLmPh for ; Mon, 28 Aug 2017 03:40:35 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D0E132932 for ; Mon, 28 Aug 2017 03:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2136; q=dns/txt; s=iport; t=1503916833; x=1505126433; h=to:from:subject:message-id:date:mime-version; bh=z1vid1K6cpZkMXIPqA18RSv+kdnP7ady4680kZmYg8M=; b=dOt2Xn93xPnvMu61l/SPXMvEiauyJzrFPx4G2X/z72PTTGO2bIo6IwQ/ Gdd3uvixIObx9tu+sb2NKE45Ang5SWlI9Cv0ocHTVmKhgj8f96YCB3B9R YldyOIx3qnBHxMCtxkB27+EtfBdyDjyg0hDCF32nFQYpJjjMa5rjukq/s g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZBgAh8qNZ/xbLJq1cHAEBBAEBCgEBh?= =?us-ascii?q?VODd4sRoXqHUIoCFAECAQEBAQEBAWsdC4VCdQE9Al8NBgIBAYotsUeCJyeLMwE?= =?us-ascii?q?BCAEBAQEkgyqDUIIOiwWCYQWgZJRGghKFZoNZhxeNS4hyNiFBTDIhCBwVh2Y+N?= =?us-ascii?q?opoAQEB?= X-IronPort-AV: E=Sophos;i="5.41,441,1498521600"; d="scan'208,217";a="696800968" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2017 10:40:28 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7SAeSAu014047 for ; Mon, 28 Aug 2017 10:40:28 GMT To: "teas@ietf.org" From: Benoit Claise Message-ID: Date: Mon, 28 Aug 2017 12:40:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8163C7BDA1547C6BA9FF73F9" Content-Language: en-US Archived-At: Subject: [Teas] YANG mistake in draft-ietf-teas-yang-rsvp-te X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 10:40:37 -0000 This is a multi-part message in MIME format. --------------8163C7BDA1547C6BA9FF73F9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, See 2.3.2. YANG Module file "ietf-rsvp-te@2017-03-10.yang" module ietf-rsvp-te { And 2.4.2. YANG Module file "ietf-rsvp-te@2017-03-10.yang" module ietf-rsvp-te-mpls { Both refer to ietf-rsvp-te@2017-03-10.yang The second entry should be: 2.4.2. YANG Module file "ietf-rsvp-te-mpls@2017-03-10.yang" module ietf-rsvp-te-mpls { Please post a new draft version, so that the second YANG module is correctly extracted. Regards, Benoit --------------8163C7BDA1547C6BA9FF73F9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

See 
2.3.2.  YANG Module

   <CODE BEGINS> file "ietf-rsvp-te@2017-03-10.yang"
   module ietf-rsvp-te {


And

2.4.2.  YANG Module

   <CODE BEGINS> file "ietf-rsvp-te@2017-03-10.yang"
   module ietf-rsvp-te-mpls {

Both refer to ietf-rsvp-te@2017-03-10.yang
The second entry should be:

2.4.2.  YANG Module

   <CODE BEGINS> file "ietf-rsvp-te-mpls@2017-03-10.yang"
   module ietf-rsvp-te-mpls {
Please post a new draft version, so that the second YANG module is correctly extracted.

Regards, Benoit
--------------8163C7BDA1547C6BA9FF73F9-- From nobody Mon Aug 28 06:01:13 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A058132199 for ; Mon, 28 Aug 2017 06:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXEQk65hP9on for ; Mon, 28 Aug 2017 06:01:07 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0136.outbound.protection.outlook.com [104.47.41.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DE41252BA for ; Mon, 28 Aug 2017 06:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u74pBodi39t511ZeFxi7wTjqOkLnxBSjPW5GJUshkIY=; b=v5vGpnhZZY3S4XwYqTngSfDFcdZsYhYKFplCuFyFcT5iD24yEbYS5oj1xv0kcmdXQnSq8LuivFSdeb74A8k9Qqyrw5rKSgMN5wnmaOA/dZjCr9h3RVHlTuM5zzHtvlyGZwvSsfeeuYhJsHteVOS7tAzFK5TEHJSNIk7n8BRyp+Y= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0898.namprd02.prod.outlook.com (10.160.154.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Mon, 28 Aug 2017 13:01:05 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1385.014; Mon, 28 Aug 2017 13:01:05 +0000 From: Xufeng Liu To: Lou Berger , Igor Bryskin , "vbeeram@juniper.net" , "tsaad@cisco.com" , "hshah@ciena.com" , "OSCAR GONZALEZ DE DIOS" , "Italo.Busi@huawei.com" , "carlo.perocchio@ericsson.com" , "Beller, Dieter (Nokia - DE)" , "sergio.belotti@nokia.com" , TEAS WG Thread-Topic: Regarding IPR on draft-ietf-teas-yang-te-topo Thread-Index: AQHTHd6ndBOwzI6j3UOfkb747RFYPqKZv5wQ Date: Mon, 28 Aug 2017 13:01:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWYyN2M4MzQxLThiZjAtMTFlNy05YzI4LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFxmMjdjODM0My04YmYwLTExZTctOWMyOC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjI0MjgiIHQ9IjEzMTQ4Mzk4ODY0OTQ4NTg0NSIgaD0iaThpNmRIVk9GZTQzL1ViOW1CMlV6b3NEOEo0PSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0898; 6:kNdSnhnlKWo4YbvuITglt7BUx4lNY57UaBOtJsK3lU+sYHDgVP8/P1G8KQN4LvwUeELn1DFGpan/Ie9ZwbAQjodtrAaJitZ0tfyMvrugeBQ9K74Tcjxo7hPNtMLODq4f2hEMlbChymQ6muvd6kwb4ceF1id7RWLV77CTu+kLuTBGeNB83SlVGfjW7JpB2cC3xaf9hNX9mU9lztKNvAxUI7VFjl4H0w+iGjW8nc/4BlnMvw89navp0tlYppK18qLNIkKsiFDJHWjvRYdFUwE61cgsJwKF8Bg8ApTqTmJ29dHKQUmEq8Ad5m/Scowpau0LpOvzgifGu+LhTbNFxxjJJg==; 5:x5n1xBRhoFWcaD5M1JofZAWU3PbfDoxaBnrVWU0+WR6Jdselx+jRaOdc5kWeJ5L5Jr3KgWZROEVTztN/udbadolUTn/RndqnBt4L8WGAaEJ8URnqY1HQgukdGDIsgK3UYIM6Lvl2n2+oPCHNWZ+K1g==; 24:GKdjBeiF6fgQCuM/fBdltKtjSjMXegxIlv20opECrWcmRouCKmxnedur2j0lJaoXI37vnJsjQ6ElHWk6p+Qb7KikqY5WYCa6+xW6MRRlWx0=; 7:Xu+03ACitjU+hIWac7yqApTsysJH/qIEj4qeCT6adQHkhRqevaXjhfSPBHjyV3jew4pJ/nxSO+3ws6mYcEvSdj3C9XS/hy7Dq/VNiORpa02zqwP5tdNhzzVjIdeI4J6NDdRT8NLa0znpJCWk8Xp3O+yLdWUqdEW1xNeV8A95WveOrFLlIAIb6pV5cb/cnZ9DM+uWnOxwdQDb8Z3UiwTV1Thqr5w9XbjX+SvjisRpYZE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 64c6c2ee-05e6-42a9-f975-08d4ee14d7f0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0201MB0898; x-ms-traffictypediagnostic: BN3PR0201MB0898: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(138986009662008)(82608151540597)(95692535739014)(21534305686606)(50582790962513); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0898; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0898; x-forefront-prvs: 0413C9F1ED x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(377454003)(13464003)(199003)(54356999)(76176999)(50986999)(2501003)(14454004)(8936002)(189998001)(2950100002)(77096006)(105586002)(6506006)(74316002)(106356001)(68736007)(966005)(33656002)(5660300001)(305945005)(53546010)(7416002)(72206003)(101416001)(6436002)(97736004)(86362001)(230783001)(229853002)(7696004)(3846002)(102836003)(6116002)(7736002)(55016002)(99286003)(66066001)(6306002)(9686003)(2900100001)(8666007)(53936002)(2201001)(478600001)(6246003)(25786009)(8676002)(80792005)(3280700002)(3660700001)(81166006)(1941001)(2906002)(81156014)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0898; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2017 13:01:05.3545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0898 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 13:01:11 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N Cg0KVGhhbmtzLA0KLSBYdWZlbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4gU2VudDogRnJpZGF5 LCBBdWd1c3QgMjUsIDIwMTcgNDoxMiBQTQ0KPiBUbzogWHVmZW5nIExpdSA8WHVmZW5nX0xpdUBq YWJpbC5jb20+OyBJZ29yIEJyeXNraW4NCj4gPGlnb3IuYnJ5c2tpbkBodWF3ZWkuY29tPjsgdmJl ZXJhbUBqdW5pcGVyLm5ldDsgdHNhYWRAY2lzY28uY29tOw0KPiBoc2hhaEBjaWVuYS5jb207IE9T Q0FSIEdPTlpBTEVaIERFIERJT1MNCj4gPG9zY2FyLmdvbnphbGV6ZGVkaW9zQHRlbGVmb25pY2Eu Y29tPjsgSXRhbG8uQnVzaUBodWF3ZWkuY29tOw0KPiBjYXJsby5wZXJvY2NoaW9AZXJpY3Nzb24u Y29tOyBCZWxsZXIsIERpZXRlciAoTm9raWEgLSBERSkNCj4gPGRpZXRlci5iZWxsZXJAbm9raWEu Y29tPjsgc2VyZ2lvLmJlbG90dGlAbm9raWEuY29tOyBURUFTIFdHDQo+IDx0ZWFzQGlldGYub3Jn Pg0KPiBTdWJqZWN0OiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRv cG8NCj4gDQo+IEF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csDQo+IA0KPiBBcyBwYXJ0IG9mIHRo ZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBDYWxsDQo+IA0KPiBBcmUgeW91IGF3YXJlIG9mIGFu eSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0cyBpZGVudGlmaWVkIGFib3ZlPw0KPiANCj4gUGxl YXNlIHN0YXRlIGVpdGhlcjoNCj4gDQo+ICJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRo YXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KPiBvcg0KPiAiWWVzLCBJJ20gYXdhcmUgb2YgSVBS IHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KPiANCj4gSWYgc28sIGhhcyB0aGlzIElQUiBi ZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNz DQo+IDM2NjksIDUzNzggYW5kIDgxNzkgZm9yIG1vcmUgZGV0YWlscyk/DQo+IA0KPiBJZiB5ZXMg dG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KPiANCj4gIlllcywgdGhlIElQUiBo YXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0KPiBv cg0KPiAiTm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCINCj4gDQo+IElmIHlvdSBh bnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5r IGFwcHJvcHJpYXRlLg0KPiANCj4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRo b3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUgYWJvdmUNCj4gYnkgcmVzcG9uZGlu ZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2Fy ZSBvZiBhbnkNCj4gcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2Ug dG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZQ0KPiBoYXMgYmVlbiByZWNlaXZlZCBm cm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQgY29udHJpYnV0b3IuIE5PVEU6IFRISVMgQVBQTElF Uw0KPiBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUyBUTyBMSU5FUy4NCj4g DQo+IElmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdz IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbg0KPiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJl bWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVURiBJUFINCj4gcnVsZXMg d2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUgYXdhcmUg b2YgSVBSIG9mIG90aGVycw0KPiBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFp biBmcm9tIHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvcg0KPiBkaXNjdXNzaW9u IHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBw bGVhc2Ugc2VlIHRoZQ0KPiBSRkNzIGxpc3RlZCBhYm92ZSBhbmQNCj4gaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQo+ IA0KPiBUaGFuayB5b3UsDQo+IFRFQVMgV0cgQ2hhaXJzDQo+IA0KPiBQUyBQbGVhc2UgaW5jbHVk ZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3Bv bnNlLg0KPiANCg0K From nobody Mon Aug 28 06:06:51 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E25F13291F for ; Mon, 28 Aug 2017 06:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wa0CHTNNQu1Y for ; Mon, 28 Aug 2017 06:06:48 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 F2237132357 for ; Mon, 28 Aug 2017 06:06:47 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id r133so1312343pgr.3 for ; Mon, 28 Aug 2017 06:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wgh8ZJItEeUKnkn7NItq062OIWxnIUhPzgvv/6vMJgc=; b=eAaH37Zy4BbVqrvXJnZ1tFa1nlKaJp7lJv/3+ktSpjdKt2Iv4hh17GHScwcWgMqdM0 V9YjTQp6Kutz4T3NMSonXPN1IE3cTGzWBrYIrL88ypjsOXeY2V9D/yqxTphPQFlvpHUq 01/PwfhodWRSDHACn5u2JQnOLN0xg2n5GvsgX1BYahn3KJy49cfnAnuluksHLU/J879p NYUDgDqba/IlN+KNdiNo2pititqT0q68wEQz6f7uiq/z5iInpnpe3Dd69JfOwu6xQSqH PTcg5bdeh1sEiyR4aJ4MVLqA8p30RwVOpRgq4XYP70K/hGHzHU/wwV8yKGzr9EHK/J70 Nwqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wgh8ZJItEeUKnkn7NItq062OIWxnIUhPzgvv/6vMJgc=; b=iYXQLZ/3eHBRiEdMs7676VjdS8Pr/bnyjVm0oxxmqyOQplJ1EZP/Gr86ebfS3QTNdi fTkqWUiejsF6p2TI9ygGX5Idm12EtVRwgqvVcpEYVahh+ArhpC7Jp1uTjdQDEPOv3DCj cLNPGuwGTRql2v5Q9UP3vewEv+Rx8A8sORy9MDU149QJCUWzMw78xRO96nMWQl2XoTp5 YmEKCLuDCRKSiGNThtSUqsB/DPb+smtQyKYKwNDtF9/5h+/hkyW0BtCyq/lDXJkbWy6k PP8IaIm2oNYzj/wUZBv7wujInx9pCQCe6zba7On85vmYgH4DiTmKIHCl5gzI8Q6uvk4o kWrA== X-Gm-Message-State: AHYfb5hsiIXi8mWcbTUh/2fTGbUGwPRm/L41LhdQChf0z7DKoUtnsbX4 BZj1xSpbOiTIh09XlxSxMibsLXQ6iw== X-Received: by 10.84.194.195 with SMTP id h61mr633853pld.371.1503925607511; Mon, 28 Aug 2017 06:06:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.166.81 with HTTP; Mon, 28 Aug 2017 06:06:46 -0700 (PDT) In-Reply-To: References: From: Vishnu Pavan Beeram Date: Mon, 28 Aug 2017 09:06:46 -0400 Message-ID: To: Lou Berger Cc: Xufeng Liu , Igor Bryskin , Vishnu Pavan Beeram , "Tarek Saad (tsaad)" , "Shah, Himanshu" , OSCAR GONZALEZ DE DIOS , Italo Busi , carlo.perocchio@ericsson.com, "Beller, Dieter (Nokia - DE)" , "Belotti, Sergio (Nokia - IT)" , TEAS WG Content-Type: multipart/alternative; boundary="94eb2c18a24e9abd1d0557cff781" Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 13:06:50 -0000 --94eb2c18a24e9abd1d0557cff781 Content-Type: text/plain; charset="UTF-8" No, I'm not aware of any IPR that applies to this draft. Regards, -Pavan On Fri, Aug 25, 2017 at 4:11 PM, Lou Berger wrote: > Authors, Contributors, WG, > > As part of the preparation for WG Last Call > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > TEAS WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --94eb2c18a24e9abd1d0557cff781 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, I'm not aware of any IPR that applies to= this draft.

Regards,
-Pavan

On Fri, Aug 25, 2017 at 4:11 PM,= Lou Berger <lberger@labn.net> wrote:
Authors, Contributors, WG,

As part of the preparation for WG Last Call

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

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

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S<= br> TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/= group/iesg/trac/wiki/IntellectualProperty.

Thank you,
TEAS WG Chairs

PS Please include all listed in the headers of this message in your
response.


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

--94eb2c18a24e9abd1d0557cff781-- From nobody Mon Aug 28 07:07:36 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260D1132D0E for ; Mon, 28 Aug 2017 07:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcqzs0_tT6HB for ; Mon, 28 Aug 2017 07:07:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532EB1243F6 for ; Mon, 28 Aug 2017 07:07:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNL96994; Mon, 28 Aug 2017 14:06:56 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.201.109.59]) by lhreml701-cah.china.huawei.com ([10.201.108.42]) with mapi id 14.03.0301.000; Mon, 28 Aug 2017 15:06:47 +0100 From: Italo Busi To: Lou Berger , Xufeng Liu , "Igor Bryskin" , "vbeeram@juniper.net" , "tsaad@cisco.com" , "hshah@ciena.com" , OSCAR GONZALEZ DE DIOS , "carlo.perocchio@ericsson.com" , "Beller, Dieter (Nokia - DE)" , "sergio.belotti@nokia.com" , TEAS WG Thread-Topic: Regarding IPR on draft-ietf-teas-yang-te-topo Thread-Index: AQHTHd++co+LvD8lh0GC6kIqoNRQIqKZ0fRQ Date: Mon, 28 Aug 2017 14:06:46 +0000 Message-ID: <91E3A1BD737FDF4FA14118387FF6766B15793B0C@lhreml504-mbs> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.144.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59A42382.021C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3feba206b56474d91f00b973c826f9c5 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 14:07:35 -0000 SGkgTG91LA0KDQpObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0 aGlzIGRyYWZ0DQoNClRoYW5rcywgSXRhbG8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSANClNlbnQ6IHZlbmVy ZMOsIDI1IGFnb3N0byAyMDE3IDIyOjEyDQpUbzogWHVmZW5nIExpdTsgSWdvciBCcnlza2luOyB2 YmVlcmFtQGp1bmlwZXIubmV0OyB0c2FhZEBjaXNjby5jb207IGhzaGFoQGNpZW5hLmNvbTsgT1ND QVIgR09OWkFMRVogREUgRElPUzsgSXRhbG8gQnVzaTsgY2FybG8ucGVyb2NjaGlvQGVyaWNzc29u LmNvbTsgQmVsbGVyLCBEaWV0ZXIgKE5va2lhIC0gREUpOyBzZXJnaW8uYmVsb3R0aUBub2tpYS5j b207IFRFQVMgV0cNClN1YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0Zi10ZWFzLXlh bmctdGUtdG9wbw0KDQpBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KDQpBcyBwYXJ0IG9mIHRo ZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBDYWxsDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQ UiB0aGF0IGFwcGxpZXMgdG8gZHJhZnRzIGlkZW50aWZpZWQgYWJvdmU/DQoNClBsZWFzZSBzdGF0 ZSBlaXRoZXI6DQoNCiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0 byB0aGlzIGRyYWZ0Ig0Kb3INCiJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRv IHRoaXMgZHJhZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29t cGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzNjY5LCA1Mzc4IGFuZCA4MTc5 IGZvciBtb3JlIGRldGFpbHMpPw0KDQpJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUg ZWl0aGVyOg0KDQoiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNl IHdpdGggSUVURiBJUFIgcnVsZXMiDQpvcg0KIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNj bG9zZWQiDQoNCklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFs IGRldGFpbHMgeW91IHRoaW5rIGFwcHJvcHJpYXRlLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBh IGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZSBhYm92ZSBi eSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5 b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQgd2lsbCBub3Qg YWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2Vp dmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRvci4gTk9URTogVEhJUyBB UFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdTIFRPIExJTkVTLg0K DQpJZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBi dXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQg eW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzIHdoaWNoIGVu Y291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBv ZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0 aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlv dXIgdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUg UkZDcyBsaXN0ZWQgYWJvdmUgYW5kIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2ll c2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpURUFTIFdH IENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9m IHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNlLg0KDQoNCg== From nobody Mon Aug 28 07:13:07 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD244132D0F for ; Mon, 28 Aug 2017 07:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8nb6N4C10N6 for ; Mon, 28 Aug 2017 07:12:58 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA28F132D10 for ; Mon, 28 Aug 2017 07:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3524; q=dns/txt; s=iport; t=1503929578; x=1505139178; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=q5hmoaRBmQ8lRcBxzGHVms/6k6DBt+jsY7SrxYOeof8=; b=YSgqsStY18ixHWwSkqoLiZps0iWpxZJIAGWEiD5tj6LfmG4cv65cwTtk 2M0gzRYLc0hC/4t7P820ip/agbaq0RvbDBnmCmPHjFP5aWzMAsOFOY29X yuUx8whbefP4fb4HXGCSjat8o8gsaUNFvcQv4WWWkeydBmvWVBIZHgm8C 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAABVJKRZ/5tdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy0tZIEVB44NkBiBTyKWJg6CBCyFGwIag2A/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAyMRQBEEAgEIDgMDAQIDAiYCAgIwFQgIAgQBEooxELAsgieEFQGHSQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEfgQ2CHYICgU6BYysLgnKEQgESAR8HMQKCWTCCMQW?= =?us-ascii?q?gZAKHVIxwghJahQyKcJY8AR84gQILdxVJEgGGTQE6dgGINYEjgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,441,1498521600"; d="scan'208";a="449480490" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2017 14:12:57 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7SECvH5010832 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Aug 2017 14:12:57 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 28 Aug 2017 10:12:56 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1263.000; Mon, 28 Aug 2017 10:12:56 -0400 From: "Tarek Saad (tsaad)" To: Lou Berger , Xufeng Liu , "Igor Bryskin" , "vbeeram@juniper.net" , "hshah@ciena.com" , "OSCAR GONZALEZ DE DIOS" , "Italo.Busi@huawei.com" , "carlo.perocchio@ericsson.com" , "Beller, Dieter (Nokia - DE)" , "sergio.belotti@nokia.com" , TEAS WG Thread-Topic: Regarding IPR on draft-ietf-teas-yang-te-topo Thread-Index: AQHTHd5xoBvUhWriF0y+CrmnevTF1KKZ08GA Date: Mon, 28 Aug 2017 14:12:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.252.112] Content-Type: text/plain; charset="utf-8" Content-ID: <4A86DFC1D59B9945A64322A68757FB02@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 14:13:06 -0000 SSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Lg0KDQpS ZWdhcmRzLA0KVGFyZWsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBC ZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQpEYXRlOiBGcmlkYXksIEF1Z3VzdCAyNSwgMjAxNyBh dCA0OjEyIFBNDQpUbzogWHVmZW5nIExpdSA8WHVmZW5nX0xpdUBqYWJpbC5jb20+LCBJZ29yIEJy eXNraW4gPGlnb3IuYnJ5c2tpbkBodWF3ZWkuY29tPiwgInZiZWVyYW1AanVuaXBlci5uZXQiIDx2 YmVlcmFtQGp1bmlwZXIubmV0PiwgVGFyZWsgU2FhZCA8dHNhYWRAY2lzY28uY29tPiwgImhzaGFo QGNpZW5hLmNvbSIgPGhzaGFoQGNpZW5hLmNvbT4sIE9TQ0FSIEdPTlpBTEVaIERFIERJT1MgPG9z Y2FyLmdvbnphbGV6ZGVkaW9zQHRlbGVmb25pY2EuY29tPiwgIkl0YWxvLkJ1c2lAaHVhd2VpLmNv bSIgPEl0YWxvLkJ1c2lAaHVhd2VpLmNvbT4sICJjYXJsby5wZXJvY2NoaW9AZXJpY3Nzb24uY29t IiA8Y2FybG8ucGVyb2NjaGlvQGVyaWNzc29uLmNvbT4sICJCZWxsZXIsIERpZXRlciAoTm9raWEg LSBERSkiIDxkaWV0ZXIuYmVsbGVyQG5va2lhLmNvbT4sICJzZXJnaW8uYmVsb3R0aUBub2tpYS5j b20iIDxzZXJnaW8uYmVsb3R0aUBub2tpYS5jb20+LCBURUFTIFdHIDx0ZWFzQGlldGYub3JnPg0K U3ViamVjdDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZS10b3BvDQoN CiAgICBBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KICAgIA0KICAgIEFzIHBhcnQgb2YgdGhl IHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGwNCiAgICANCiAgICBBcmUgeW91IGF3YXJlIG9m IGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0cyBpZGVudGlmaWVkIGFib3ZlPw0KICAgIA0K ICAgIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQogICAgDQogICAgIk5vLCBJJ20gbm90IGF3YXJlIG9m IGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQogICAgb3INCiAgICAiWWVzLCBJ J20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KICAgIA0KICAgIElm IHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYg SVBSIHJ1bGVzDQogICAgKHNlZSBSRkNzIDM2NjksIDUzNzggYW5kIDgxNzkgZm9yIG1vcmUgZGV0 YWlscyk/DQogICAgDQogICAgSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhl cjoNCiAgICANCiAgICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlh bmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQogICAgb3INCiAgICAiTm8sIHRoZSBJUFIgaGFzIG5v dCBiZWVuIGRpc2Nsb3NlZCINCiAgICANCiAgICBJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJv dmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluaw0KICAgIGFwcHJvcHJpYXRlLg0K ICAgIA0KICAgIElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRy aWJ1dG9yIHBsZWFzZSBhbnN3ZXIgdGhlDQogICAgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlz IGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZQ0KICAgIGF3YXJlIG9m IGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUg bmV4dA0KICAgIHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBl YWNoIGF1dGhvciBhbmQgbGlzdGVkDQogICAgY29udHJpYnV0b3IuIE5PVEU6IFRISVMgQVBQTElF UyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUw0KICAgIFRPIExJTkVTLg0K ICAgIA0KICAgIElmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1l ZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZA0KICAgIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRv ciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyDQogICAgdGhlIElFVEYg SVBSIHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3Ug YXJlDQogICAgYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwg b3IgdG8gcmVmcmFpbiBmcm9tDQogICAgcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9u IG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyDQogICAgdW5kaXNjbG9zZWQgSVBSLiBGb3Ig bW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUNCiAgICBh bmQNCiAgICBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9J bnRlbGxlY3R1YWxQcm9wZXJ0eS4NCiAgICANCiAgICBUaGFuayB5b3UsDQogICAgVEVBUyBXRyBD aGFpcnMNCiAgICANCiAgICBQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFk ZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQogICAgcmVzcG9uc2UuDQogICAgDQogICAgDQog ICAgDQoNCg== From nobody Mon Aug 28 12:24:29 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2076513293A; Mon, 28 Aug 2017 12:24:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Elwyn Davies To: Cc: draft-ietf-teas-pce-central-control.all@ietf.org, ietf@ietf.org, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150394826804.19875.11489576374495678242@ietfa.amsl.com> Date: Mon, 28 Aug 2017 12:24:28 -0700 Archived-At: Subject: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 19:24:28 -0000 Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-teas-pce-central-control-04 Reviewer: Elwyn Davies Review Date: 2017-08-28 IETF LC End Date: 2017-08-24 IESG Telechat date: 2017-08-31 Summary: Thanks for addressing my Last Call comments on -03. The new version is ready with one introduced nit. Also I am still of the abstract is somewhat overlong. Nit: s6, para 2: The SDN term 'northbound' has appeared in the new version. Needs brief explanation. Major issues: Minor issues: Nits/editorial comments: From nobody Mon Aug 28 15:02:15 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C40120721; Mon, 28 Aug 2017 15:02:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150395773325.13147.17175623030110052437@ietfa.amsl.com> Date: Mon, 28 Aug 2017 15:02:13 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-12.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 22:02:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Updates to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs Authors : Mike Taillon Tarek Saad Rakesh Gandhi Zafar Ali Manav Bhatia Filename : draft-ietf-teas-gmpls-lsp-fastreroute-12.txt Pages : 24 Date : 2017-08-28 Abstract: This document updates the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC 4090 to support Packet Switched Capable (PSC) Generalized Multi- Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these updates enable the re-direction of bidirectional traffic onto bypass tunnels that ensure co-routedness of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in control-plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute-12 https://datatracker.ietf.org/doc/html/draft-ietf-teas-gmpls-lsp-fastreroute-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-gmpls-lsp-fastreroute-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 28 19:52:04 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC26F132715; Mon, 28 Aug 2017 19:52:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-teas-lsp-diversity@ietf.org, teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150397512291.13163.11334943635287191344.idtracker@ietfa.amsl.com> Date: Mon, 28 Aug 2017 19:52:02 -0700 Archived-At: Subject: [Teas] Ben Campbell's No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 02:52:03 -0000 Ben Campbell has entered the following ballot position for draft-ietf-teas-lsp-diversity-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >From the abstract: "Three different mechanisms are supported how LSP diversity can be accomplished in the provider or core network:..." Is there a missing word around "... supported how..."? From nobody Tue Aug 29 00:25:21 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E70132D48 for ; Tue, 29 Aug 2017 00:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9qdxxtt30eV for ; Tue, 29 Aug 2017 00:25:05 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0134.outbound.protection.outlook.com [104.47.1.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899AA132705 for ; Tue, 29 Aug 2017 00:24:59 -0700 (PDT) Received: from VI1PR0602MB3309.eurprd06.prod.outlook.com (10.170.232.26) by VI1PR0602MB2831.eurprd06.prod.outlook.com (10.175.22.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Tue, 29 Aug 2017 07:24:56 +0000 Received: from VI1PR0602MB3309.eurprd06.prod.outlook.com ([fe80::f49c:2800:83e9:af16]) by VI1PR0602MB3309.eurprd06.prod.outlook.com ([fe80::f49c:2800:83e9:af16%13]) with mapi id 15.01.1385.008; Tue, 29 Aug 2017 07:24:56 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= To: "Tarek Saad (tsaad)" , Lou Berger , Xufeng Liu , Igor Bryskin , "vbeeram@juniper.net" , "hshah@ciena.com" , "Italo.Busi@huawei.com" , "carlo.perocchio@ericsson.com" , "Beller, Dieter (Nokia - DE)" , "sergio.belotti@nokia.com" , TEAS WG Thread-Topic: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo Thread-Index: AQHTIJfpB/hEqMMngUOsN8Z5R38rIg== Date: Tue, 29 Aug 2017 07:24:56 +0000 Message-ID: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oscar.gonzalezdedios@telefonica.com; x-originating-ip: [195.235.92.36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0602MB2831; 6:2TCtEFka5cMgXYkXwWKCQohR5iuGYrdpHzuT1itAAV8sLjTk6QUnsxksbGoXJ27iq/quX6QOntNbiBW1BShC8dLBDzPilaSlHMNDb4a9H3gKb5JdZ/rLf9gW/oCxvzYWokXyTK/tdDrV2XTXY2ImIaRhIbvUMkHGs5Lv4x6oycglyEQiTzvE9w4J9J6L304G8gies/3zJYy8Xxo5DfhA5kUj+558rJnERSIFzLHJmE7Djf9UjAco/G03AWT0WchrIfCw+P5EJ6ABILMFDzjSwNWsK8x+MHMSxroePSZcMKCJJjwZrnqqdSt/Bd2VItVd4KbuXV+9TECxkQTA6J9YcQ==; 5:2ehvakdpKtkd+G1gkc323MJVCSDX8+JEzns8uVjq/MnZmblAjoxJhbTs/kYjZrldrXY0ZMJMNljso1ixq0ZOYs5NDuSFf8FgMblc18+n1/6vlifUxFtIsmFzRmH3xH0kbXqbUOiOqO/Q9NBMcj90Ow==; 24:R8RH+NgBH0MfK0H8Ci8buRE0Cy8cltbJLGH824ywh8l6nl81iP4oRcAaVrj7oGaRz9RSICLaboTrOyqQXHl5rIOZi+2qb02EAg3Cv1VbJRo=; 7:DWsiN9NvrZbSgaSD4IUNMC//5oZyJIxFnglTajCVtoh8+Zuon/3x5RknyN8fstahMcGPPpT6bKYMhrTZvCnBxWzKbG3hWINFjprL7hRGh6iYG3S09DmaU/twBokP5GjJlkyzLHc3fyaffBSsF5moIPY57tQovngn7Kdod7lWtF0mdQc6yMeQbNvoN6xDrsxLDVGFYO59eMmP2H0NCT8dw0uutP5Z25Cdu7xXKxA0gdc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bf4b3562-8994-420e-26b4-08d4eeaf0c8b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0602MB2831; x-ms-traffictypediagnostic: VI1PR0602MB2831: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(138986009662008)(82608151540597)(95692535739014)(21534305686606)(50582790962513); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0602MB2831; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0602MB2831; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(25724002)(377454003)(189002)(199003)(40134004)(13464003)(99286003)(3846002)(2900100001)(8676002)(2501003)(83506001)(5660300001)(6306002)(966005)(6116002)(305945005)(102836003)(7736002)(478600001)(1941001)(14454004)(86362001)(2201001)(68736007)(3660700001)(6512007)(5250100002)(81156014)(81166006)(3280700002)(229853002)(25786009)(8666007)(53936002)(6486002)(6506006)(230783001)(50986999)(6436002)(8936002)(54356999)(36756003)(101416001)(6246003)(105586002)(7416002)(4001350100001)(66066001)(97736004)(189998001)(2906002)(106356001)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0602MB2831; H:VI1PR0602MB3309.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <325427621AF50E43BC421275CAA1B441@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 07:24:56.2278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0602MB2831 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 07:25:19 -0000 No, I'm not aware of any IPR that applies to this draft. Best Regards, Oscar El 28/8/17 16:12, "Teas on behalf of Tarek Saad (tsaad)" escribi=F3: >I'm not aware of any IPR that applies to this draft. > >Regards, >Tarek > >-----Original Message----- >From: Lou Berger >Date: Friday, August 25, 2017 at 4:12 PM >To: Xufeng Liu , Igor Bryskin >, "vbeeram@juniper.net" , >Tarek Saad , "hshah@ciena.com" , OSCAR >GONZALEZ DE DIOS , >"Italo.Busi@huawei.com" , >"carlo.perocchio@ericsson.com" , "Beller, >Dieter (Nokia - DE)" , >"sergio.belotti@nokia.com" , TEAS WG > >Subject: Regarding IPR on draft-ietf-teas-yang-te-topo > > Authors, Contributors, WG, > > As part of the preparation for WG Last Call > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer >the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not >listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed >above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > TEAS WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o From nobody Tue Aug 29 06:04:05 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4617F132055; Tue, 29 Aug 2017 06:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IduEieHTAZmH; Tue, 29 Aug 2017 06:03:56 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57251200F3; Tue, 29 Aug 2017 06:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4394; q=dns/txt; s=iport; t=1504011836; x=1505221436; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=X6aizUwH/kxSQ4BP0Li2+cjG+BHJQJbF3YwdxF+/8x4=; b=blSv/P92ppNjrSLk8+25iM/A4dVWef83AW33DNtojUSudHvoVmDSuVnZ s9YMglPJX0DeSzfao6iKQ6uH7zGqFwSEEmG+SeJuAZd2Kf3nsD2zxVWan gA8E13WOukauwaXHRUbyp0kywdECma5gxbtrd3tzzYpa/ujVv1LfniUEY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAQBkZaVZ/40NJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tZIEVB4Nwih2QG5gYghIhDYUZAhqDdT8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhRkCAQMBASEROgsQAgEIEggCJgICAiULFQIOAgQOBYoxELBFgieLXwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2BDYIdggKBToFiLIJ9gyaBTxeCfDCCMQWgaAKHV4x?= =?us-ascii?q?zghJahQ2KcpZBAR84gQ13FR8qEgGHCHaKEoEPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,444,1498521600"; d="scan'208";a="476655804" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Aug 2017 13:03:55 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v7TD3tES019274 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 13:03:55 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 29 Aug 2017 08:03:55 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1263.000; Tue, 29 Aug 2017 08:03:55 -0500 From: "Rakesh Gandhi (rgandhi)" To: "draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org" CC: "teas@ietf.org" , Alia Atlas , "vbeeram@juniper.net" , DEBORAH BRUNGARD , "teas-chairs@ietf.org" , The IESG Thread-Topic: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-12.txt Thread-Index: AQHTIElVSAm9mQRcjUG/jg3uP96Z1aKbXrkA Date: Tue, 29 Aug 2017 13:03:55 +0000 Message-ID: References: <150395773325.13147.17175623030110052437@ietfa.amsl.com> In-Reply-To: <150395773325.13147.17175623030110052437@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.251.252] Content-Type: text/plain; charset="utf-8" Content-ID: <5468C1ABF55C1647B4AEE6DD73AB1EAB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-12.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 13:04:03 -0000 SGkgV0csDQoNCldlIGhhdmUgdXBkYXRlZCB0aGUgZG9jdW1lbnQgd2l0aCBlZGl0b3JpYWwgY2hh bmdlcyBhbmQgaGF2ZSBhZGRlZCBlbGFib3JhdGlvbi9jbGFyaWZpY2F0aW9uIG9mIGNhc2VzIGFz IGZvbGxvd2luZy4gDQoNCi0gIEVsYWJvcmF0ZWQgb24gYnlwYXNzIGFzc2lnbm1lbnQgKHRvIGNv dmVyIGxvb3NlIGhvcHMgY2FzZSkNCi0gIEFkZGVkIHRleHQgZm9yIGFkZGluZy9yZW1vdmluZy9j aGFuZ2luZyBvZiBieXBhc3MgYXNzaWdubWVudCANCi0gIFNlY3Rpb24gNC41LjM6IHJlbW92ZSBs b2NhbCBwb2xpY3ksIGFkZGVkIHVzZSBvZiBzZXNzaW9uLWF0dHJpYnV0ZSBmbGFnIChub2RlIHBy b3RlY3Rpb24gZGVzaXJlZCkNCi0gIFNlY3Rpb24gNTogY2xhcmlmaWVkIHRoYXQgUGF0aCBtZXNz YWdlIGlzIG1vZGlmaWVkIGFzIHBlciBbUkZDNDA5MF0gICANCi0gIFNlY3Rpb24gNS4yLjQ6IGFk ZGVkIHRleHQgZm9yIG5vZGUgZmFpbHVyZSBjYXNlDQotIE1pc2MuIGVkaXRvcmlhbCBjaGFuZ2Vz DQoNCldlbGNvbWUgeW91ciByZXZpZXcgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLiANCg0KTWFu eSB0aGFua3MgdG8gQWxpYSBmb3IgdGhlIHJldmlldyBjb21tZW50cy4NCg0KUmVnYXJkcywNClJh a2VzaCAoZm9yIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycykNCg0KDQpPbiAyMDE3LTA4LTI4LCA2 OjAyIFBNLCAiVGVhcyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8dGVh cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ IHdyb3RlOg0KDQogICAgDQogICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KICAgIFRoaXMgZHJh ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRyYWZmaWMgRW5naW5lZXJpbmcgQXJjaGl0ZWN0dXJl IGFuZCBTaWduYWxpbmcgV0cgb2YgdGhlIElFVEYuDQogICAgDQogICAgICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBVcGRhdGVzIHRvIFJlc291cmNlIFJlc2VydmF0aW9uIFByb3RvY29sIEZvciBG YXN0IFJlcm91dGUgb2YgVHJhZmZpYyBFbmdpbmVlcmluZyBHTVBMUyBMU1BzDQogICAgICAgICAg ICBBdXRob3JzICAgICAgICAgOiBNaWtlIFRhaWxsb24NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFRhcmVrIFNhYWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJha2VzaCBH YW5kaGkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFphZmFyIEFsaQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTWFuYXYgQmhhdGlhDQogICAgCUZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGUtMTIudHh0DQogICAgCVBhZ2Vz ICAgICAgICAgICA6IDI0DQogICAgCURhdGUgICAgICAgICAgICA6IDIwMTctMDgtMjgNCiAgICAN CiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgdGhlIFJlc291cmNl IFJlc2VydmF0aW9uIFByb3RvY29sIC0gVHJhZmZpYw0KICAgICAgIEVuZ2luZWVyaW5nIChSU1ZQ LVRFKSBGYXN0IFJlcm91dGUgKEZSUikgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFJGQw0KICAgICAg IDQwOTAgdG8gc3VwcG9ydCBQYWNrZXQgU3dpdGNoZWQgQ2FwYWJsZSAoUFNDKSBHZW5lcmFsaXpl ZCBNdWx0aS0NCiAgICAgICBQcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKEdNUExTKSBMYWJlbCBT d2l0Y2hlZCBQYXRocyAoTFNQcykuICBUaGVzZQ0KICAgICAgIHVwZGF0ZXMgYWxsb3cgdGhlIGNv b3JkaW5hdGlvbiBvZiBhIGJpZGlyZWN0aW9uYWwgYnlwYXNzIHR1bm5lbA0KICAgICAgIGFzc2ln bm1lbnQgcHJvdGVjdGluZyBhIGNvbW1vbiBmYWNpbGl0eSBpbiBib3RoIGZvcndhcmQgYW5kIHJl dmVyc2UNCiAgICAgICBkaXJlY3Rpb25zIG9mIGEgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQ LiAgSW4gYWRkaXRpb24sIHRoZXNlDQogICAgICAgdXBkYXRlcyBlbmFibGUgdGhlIHJlLWRpcmVj dGlvbiBvZiBiaWRpcmVjdGlvbmFsIHRyYWZmaWMgb250byBieXBhc3MNCiAgICAgICB0dW5uZWxz IHRoYXQgZW5zdXJlIGNvLXJvdXRlZG5lc3Mgb2YgZGF0YSBwYXRocyBpbiB0aGUgZm9yd2FyZCBh bmQNCiAgICAgICByZXZlcnNlIGRpcmVjdGlvbnMgYWZ0ZXIgRlJSIGFuZCBhdm9pZCBSU1ZQIHNv ZnQtc3RhdGUgdGltZW91dCBpbg0KICAgICAgIGNvbnRyb2wtcGxhbmUuDQogICAgDQogICAgDQog ICAgDQogICAgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQg aXM6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10ZWFz LWdtcGxzLWxzcC1mYXN0cmVyb3V0ZS8NCiAgICANCiAgICBUaGVyZSBhcmUgYWxzbyBodG1saXpl ZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGUtMTINCiAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGVhcy1nbXBscy1sc3AtZmFz dHJlcm91dGUtMTINCiAgICANCiAgICBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtdGVhcy1nbXBscy1sc3AtZmFzdHJlcm91dGUtMTINCiAgICANCiAgICANCiAgICBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICANCiAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRlYXMgbWFpbGluZyBsaXN0DQog ICAgVGVhc0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGVhcw0KICAgIA0KDQo= From nobody Tue Aug 29 11:44:07 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161B213248B; Tue, 29 Aug 2017 11:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6KLp-4Rla2H; Tue, 29 Aug 2017 11:44:04 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5DC81321AF; Tue, 29 Aug 2017 11:44:00 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7TIhvAA004094; Tue, 29 Aug 2017 19:43:57 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7TIhuTX004033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2017 19:43:57 +0100 Reply-To: From: "Adrian Farrel" To: Cc: , , "'Elwyn Davies'" , "'Spencer Dawkins at IETF'" Date: Tue, 29 Aug 2017 19:43:56 +0100 Message-ID: <0c2701d320f6$c59730e0$50c592a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdMg9sKVYkubRDVnSTyUEyhRJI2X0g== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23290.002 X-TM-AS-Result: No--5.120-10.0-31-10 X-imss-scan-details: No--5.120-10.0-31-10 X-TMASE-MatchedRID: 1TycQnOjzCyWbWgt5lV9b/sh29cwU+QFknjBMY7iKBIT7Jk2iWWPBuE5 6ObAtII83lR/flD8ufybkXkfwEV3duDBvYycsJwVngIgpj8eDcC063Wh9WVqgpgZQ9043V5eTBA mQTLpnXCgcQ9540RHYTsAVzN+Ov/slCoMrIBzDgL0tg7orWZnt7D8BHADHscU1jLwm/wxBXgi07 x2VoFGHQ== Archived-At: Subject: [Teas] Nits in draft-ietf-teas-pce-central-control-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 18:44:06 -0000 Hi, Elwyn and Spencer have made some valuable observations. Although nothing is a big deal, it would be nice if you could move the document into "Approved, Point Raised" after the telechat so that we can clean them up. Thanks, Adrian From nobody Tue Aug 29 15:45:00 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E01B9132D96; Tue, 29 Aug 2017 15:44:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-teas-pce-central-control@ietf.org, Vishnu Beeram , teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150404669791.21588.5843127228175404279.idtracker@ietfa.amsl.com> Date: Tue, 29 Aug 2017 15:44:57 -0700 Archived-At: Subject: [Teas] Ben Campbell's No Objection on draft-ietf-teas-pce-central-control-04: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 22:44:58 -0000 Ben Campbell has entered the following ballot position for draft-ietf-teas-pce-central-control-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just some editorial comments: - The abstract is unusually long, and seems more like an introduction. The second to last paragraph could almost stand by itself as a useful abstract. - The terms "southbound" and "northbound" could use definition. (I find these terms cause lots of confusion, since not everyone draws the diagrams with the same idea of what goes on top or bottom.) - 2.1.1: It's probably too late at this point to change it, but I find the use of "domains" unfortunate. That may be one of the most overloaded terms in the IETF lexicon, if not in that of the networking crowd at large. Since you describe them as "partitions", I think "partitions" would have been better. - 2.1.2, 2nd to last paragraph: "This is nominally a simple task if there are just two controllers, but can actually be quite complex if state changes in the network are not to be lost." That sentence seems self-contradictory. I don't think it's simple, nominally or otherwise. From nobody Tue Aug 29 22:43:06 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2276D126B71; Tue, 29 Aug 2017 22:42:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-teas-lsp-diversity@ietf.org, teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150407177904.21566.4554462507948409747.idtracker@ietfa.amsl.com> Date: Tue, 29 Aug 2017 22:42:59 -0700 Archived-At: Subject: [Teas] Adam Roach's No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 05:42:59 -0000 Adam Roach has entered the following ballot position for draft-ietf-teas-lsp-diversity-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Abstract should stand on its own; and, as such, needs to expand the "XRO" and "EXRS" acronyms (similar to the Introduction). For completeness, the definition of the "E" flag in section 2.1 probably needs to indicate that bit 0x08 is reserved, and MUST be set to 0 send, ignored on receipt. In section 3.2, on page 19, concerning the following text: If, subsequent to the initial signaling of a diverse LSP, the requested exclusion constraints for the diverse LSP are no longer satisfied and an alternative path for the diverse LSP that can satisfy those constraints exists, then: The phrasing "no longer satisfied" seems a bit incomplete, as (by my understanding) the constraints might not have been satisfied in the first place, if the L-bit was set in the initial request. I presume that, if this were to happen, you'd want to signal when a compliant path became available -- but the current text doesn't indicate that this is okay. Perhaps something like: "...are no longer satisfied (or, in the case that the initial request triggered a "Failed to satisfy Exclude Route" error subcode, remain unsatisfied), and an alternative path for..." From nobody Wed Aug 30 02:23:18 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA521321C4; Wed, 30 Aug 2017 02:23:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ignas Bagdonas To: Cc: ietf@ietf.org, teas@ietf.org, draft-ietf-teas-lsp-diversity.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150408498245.21623.17739725352149405409@ietfa.amsl.com> Date: Wed, 30 Aug 2017 02:23:02 -0700 Archived-At: Subject: [Teas] Opsdir last call review of draft-ietf-teas-lsp-diversity-08 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 09:23:02 -0000 Reviewer: Ignas Bagdonas Review result: Has Issues Hi there. I have reviewed this document as part of the Operations Directorate's document review process. Overall the document seems to be heading in the right direction. There are some issues related to clarity of RFC2119 language usage, especially less restrictive forms and how that would relate to interoperability, the handling of undefined values and errors, terminology could be aligned better to base GMPLS and TE specifications. The document does not cover manageability or operational considerations at all - given that it is proposing protocol extensions that require operator involvement, a section on operational considerations and possible extensions to management models and procedures should be covered. The Path-Key based signalling form seems to have interdomain signalling related security aspects that would need to be looked a bit deeper. The document would benefit from terminology and acronyms section specific to the proposed mechanism. The larger comment on time scale and granularity aspects of SRLG aware path calculation. The document is based on the assumption of a longer time period between LSP signalling requests and path reoptimizations. What is the reason for it, and what would be needed if the proposed solution is expected to operate in closer to real time environment (minutes instead of weeks)? What is the source of the time granularity restriction? Diversity information flooding specifics are stated as being out of scope. How would that impact interoperability? PAS identifier name space may be smaller or not comparable with SRLG group identifier name space, is there a need to have any form of mapping mechanism in place? Small nits: - Example based on figure 1 has got details wrong. - Terms need to be consistent throughout the document - initiated/controlled is used interchangeably, this seems to be coming from the merge of the 3 original drafts. - There is no "IPv4/IPv6" diversity identifier, they are separate per address family and text should be expanded to describe them separately. - Could the text describing the operation of L bit be simplified by stating that L bit has the same semantics as in any other object - strict/loose hop selection, and therefore diversity identifier is interpreted as a strict or loose entity that MUST or MAY be taken into account? There is a set of editorial nits and fixes throughout the document, a marked version of the document is attached. Thank you. Ignas From nobody Wed Aug 30 02:37:41 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2727E13235C for ; Wed, 30 Aug 2017 02:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8hba1d210xs for ; Wed, 30 Aug 2017 02:37:38 -0700 (PDT) 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 EC8311321A0 for ; Wed, 30 Aug 2017 02:37:37 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-40-59a6875f9037 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0D.65.21299.F5786A95; Wed, 30 Aug 2017 11:37:35 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 30 Aug 2017 11:37:34 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IpKBp6Idp5xuomoJfUecTFPGzNlzkb2Cf3pqCCV/xoc=; b=JtbgsaNLyt7aDK9ho5wXiDooGeVSPfm5M6/BH8pfWug+Ty5zuTHOQdpi2A/V0j9YL4h+RO9omVzajdZd3WrcdKdIOD6p5FxaPX9w8Gd2Cs5rC3SalMK7HyW8MSLbp4xJq47j1QLo9ovNW1tK9F6Vdaqx+QuAd7X/3BceTCfLc80= Received: from DB5PR07MB1574.eurprd07.prod.outlook.com (10.165.212.140) by DB5PR07MB1432.eurprd07.prod.outlook.com (10.166.4.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Wed, 30 Aug 2017 09:37:32 +0000 Received: from DB5PR07MB1574.eurprd07.prod.outlook.com ([fe80::2866:abc3:80f5:fd91]) by DB5PR07MB1574.eurprd07.prod.outlook.com ([fe80::2866:abc3:80f5:fd91%13]) with mapi id 15.20.0013.011; Wed, 30 Aug 2017 09:37:32 +0000 From: Carlo Perocchio To: Lou Berger , Xufeng Liu , "Igor Bryskin" , "vbeeram@juniper.net" , "tsaad@cisco.com" , "hshah@ciena.com" , OSCAR GONZALEZ DE DIOS , "Italo.Busi@huawei.com" , "Beller, Dieter (Nokia - DE)" , "sergio.belotti@nokia.com" , TEAS WG Thread-Topic: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo Thread-Index: AQHTHd9Sx7G4BHwUZ029+5ldlrgERKKcqtRw Date: Wed, 30 Aug 2017 09:37:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.0.200.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB1432; 6:vOx4xd+qrdXSVxXZruY4a91O21vtY4mJ+vcxJmsVr3a9nXv2xN14pdacqUkzuseP4uUhxNUSTktK3UNPtkS9LckAL69P3QAVKvW2TyGupP6MswYYpAnTEMoPPvvJb0twq6IYiNrYFTUPna10abZXI48elaEWGQeuX7z+CoNUJId5YHQsxHPhEn2Zieu5F8ht4IkKYMvMxu1LtULF9ccQUoiEX2agbXNUT+whiwKisUSRXx1ynBfHzWKZRk+qqFbKvUzmPherDQ3905Ol5WxwlN6qukxSWXJPb46/LPQYMOxNQzKs9Jbl1w5C0RHIG2eoAu3C2kzRJNFg890NlFDMqA==; 5:wkdggp/aq2U13A+WyM+FQSvqsEG9JYN5akoyhX5xGEdeFPxrNx7pJhrWxCxaR1BovBzmI7j50X91d+IHU3HnsdurRISblsD8rqBaTsebDXKqFw5Yw7PjTrg8Uveh54J1R8dUr1BlXjkn0HfbBWc5nw==; 24:HAbjvSHZQfuIilv6VIQn07DD5pFnXVn6Mwi8oQdYl7iJG6UAHJXcisr/DLI6g5b5JlcK5FMZ866NEZm0Z2HKaj1bvSmg+6lYlM2VhJdyLvk=; 7:259u9j7ZCWmdfGi4xoMhj9AR9Zvc60ffhN3GGnl9Pq62ROXZojdu3GrSVo0P/yAyhoU6NNe4onxq1j41qdRJFp6LaQilHDo6ftguLXSJLmghbrREQiNAEMpUH2XHzIUB5pXjC+cDUd6wFcxVMcwHFrMmadL9pt9rT/5Wih+wsTmL4DfCMoyH114yKUFzeKuiMjOAIrrCnPB0/DKShzIpV57N6z4Kvw2BV+oMnwFXWzg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 886356eb-6e0d-4326-c763-08d4ef8abd5a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB1432; x-ms-traffictypediagnostic: DB5PR07MB1432: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(138986009662008)(82608151540597)(95692535739014)(21534305686606)(50582790962513); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1432; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1432; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(199003)(377454003)(13464003)(189002)(6436002)(7696004)(86362001)(2950100002)(54356999)(33656002)(68736007)(76176999)(8676002)(50986999)(2900100001)(2501003)(5250100002)(7736002)(2201001)(14454004)(53546010)(53936002)(9686003)(5660300001)(305945005)(189998001)(7416002)(8666007)(230783001)(25786009)(74316002)(55016002)(229853002)(478600001)(1941001)(99286003)(6306002)(6116002)(102836003)(3846002)(66066001)(6506006)(105586002)(2906002)(3280700002)(3660700001)(6246003)(8936002)(106356001)(966005)(101416001)(97736004)(81166006)(81156014)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB1432; H:DB5PR07MB1574.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=carlo.perocchio@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 09:37:32.4169 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1432 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRTA+e5ju7NGN9M8aEWO7A8zbWZxI6kWPS5JFEH0ILKVF7XZjN31 MCYsbZamlWnhLNJimKgps5dlRsmwFuXGzGxlkSbVMmmYYUOn7XoX9N/vnN/5DuccPgoP7SYj qUytntNp1VkKSQhh3nl/+eLU0zW7lpTYlzKNll6CeWitR4zfrmT83laSOZM/RDCeqi+I6R8t IhjTnxaCGX7uw5jqBjPO1DrMaM009pV7gmDLx6wke8o2RLIWiw9jO71VUrYnr1vKepvzJeyH dy6MLRzDt8p2hySncVmZRzldwqp9IRnWX33Sw6Wzjv8cSDCiNzOKkIwCOgme/W4gBA6lbQi+ nNEUoZAAP0fwcNwpEQKCLsGhvLOIEE05Br4mGy4GnxGcv3EZCe8lgV6er4WYIMLoQRwmmvxS QcyiVfDo6veAoAJiLUx61gnpMDoRnoyYJAITdAyc858kBZbTe8Bn/ITEmVZCRfHFKZbRyTBQ 2jZVj+jZMPqiARMYpyPg3UAVJu5Dg+WRAxc5HDyfJ0iRo8FZVxmsmQuuqrNImBPoAim0dtik ooiHu6VDSOTNUNbYjotF/Rj0530MdooFS10jJoorCM7mtUhEoQFnk1Uqii4SXr/pC4o54Db5 g2KchELvj+ByHNy8ZUIXUFzlf3uIHAfVrcMSkRdBzfVBvHLqNjPBbh4gqhFRh8J5jt9/KD1x aTynyzzA89naeC2nb0aBz/b0zlhMC+r6oWpHNIUU0+U9fM2uUFJ9lM851I6AwhVh8oPGQEqe ps45wemyU3VHsji+HUVRhCJCrnrs3BlKp6v1nIbjDnO6fxajZJFGZChIuiQfeeDaK9nu3rDx mEUdu8JlsI9Yld1+2yZjRVSuwa9+eb+yLTplS9rb6bnrZ+o7VBVS920H5y6Zp1Gevla7ADYr 9LEHJ8t21BUnDVPbwHEkr7c4FS+cM3rvsf19zofcFLPe0PetrSw+o/d75+pRz++F9XFkc+2y iPnl7xUEn6FWxuI6Xv0XRAYaQWgDAAA= Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 09:37:40 -0000 No, I'm not aware of any IPR that applies to this draft. Thanks, Carlo. -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, August 25, 2017 10:12 PM To: Xufeng Liu ; Igor Bryskin ; vbeeram@juniper.net; tsaad@cisco.com; hshah@ciena.com; OSCAR GONZALEZ D= E DIOS ; Italo.Busi@huawei.com; Carlo = Perocchio ; Beller, Dieter (Nokia - DE) ; sergio.belotti@nokia.com; TEAS WG Subject: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until = a response has been received from each author and listed contributor. NOTE:= THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any = contribution or discussion related to your undisclosed IPR. For more inform= ation, please see the RFCs listed above and http://trac.tools.ietf.org/grou= p/iesg/trac/wiki/IntellectualProperty. Thank you, TEAS WG Chairs PS Please include all listed in the headers of this message in your respons= e. _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Wed Aug 30 02:54:03 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 424EE132D4C; Wed, 30 Aug 2017 02:53:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150408683523.21615.17940727473182051278@ietfa.amsl.com> Date: Wed, 30 Aug 2017 02:53:55 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-gmpls-scsi-04.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 09:53:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Generalized Interface Switching Capability Descriptor - Switching Capability Specific Information Authors : Daniele Ceccarelli Lou Berger Filename : draft-ietf-teas-gmpls-scsi-04.txt Pages : 7 Date : 2017-08-30 Abstract: This document defines a generic information structure for information carried in routing protocol Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) fields. This "Generalized SCSI" can be used with routing protocols that define GMPLS ISCDs, and any specific technology. This document does not modify any existing technology specific formats and is defined for use in conjunction with new GMPLS Switching Capability types. The context for this document is Generalized MPLS, and the reader is expected to be familiar with the GMPLS architecture and associate protocol standards. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-scsi/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-gmpls-scsi-04 https://datatracker.ietf.org/doc/html/draft-ietf-teas-gmpls-scsi-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-gmpls-scsi-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 30 08:22:22 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0961326FE; Wed, 30 Aug 2017 08:22:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: draft-ietf-teas-pce-central-control.all@ietf.org, ietf@ietf.org, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150410652452.21632.6924902183838903689@ietfa.amsl.com> Date: Wed, 30 Aug 2017 08:22:04 -0700 Archived-At: Subject: [Teas] Secdir last call review of draft-ietf-teas-pce-central-control-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:22:05 -0000 Reviewer: Matthew Miller Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: Reviewer: Matthew A. Miller Review Date: 2017-08-30 IETF LC End Date: 2017-08-25 IESG Telechat date: 2017-08-31 Summary: This document is ready for publication as Informational, with one potential nit. This document describes an overall architecture (with some variants) utilizing central PCE-based controller for SDN, and its implication on PCEP. The document notes the tradeoffs between the variants, including some of the vulnerabilities. My nit is in the Security Considerations; I'm not sure how likely in practice a central controller architecture will be operated with "higher level of security", and therefore not sure it's worth calling out like this. I can see how a central controller makes management easier, and that has a potential benefit of better visibility into the network's operation and finding problems (including security-related) sooner and better. Otherwise I think the rest of this section addresses the concerns that a central controller architecture has. From nobody Wed Aug 30 11:11:18 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FDC1326EA; Wed, 30 Aug 2017 11:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWIR_MLUpWMf; Wed, 30 Aug 2017 11:11:07 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0103.outbound.protection.outlook.com [104.47.38.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A53132355; Wed, 30 Aug 2017 11:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h0HId4kAMVZIL8nr6O7Pg/+aClZ8o7CakDNWAaPeiY8=; b=LYMie2bNCCtsMY9ccaSoAn3fwjcrpMgHhkpR08Zw7msKxhauHqbAFCcltUl+ZtUSDI2Pd7PeDBm/AAiE6EWagOzT82yjynFZ1F6by25xdt46uEWfxPlJMDfsvssFweYd+OCQd/IDQN71wQoZ4+ZTsG6ElHaqBVkoW6lpLHOtrVs= Received: from CO2PR05MB971.namprd05.prod.outlook.com (10.141.226.17) by CO2PR05MB668.namprd05.prod.outlook.com (10.141.230.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Wed, 30 Aug 2017 18:11:04 +0000 Received: from CO2PR05MB971.namprd05.prod.outlook.com ([10.141.226.17]) by CO2PR05MB971.namprd05.prod.outlook.com ([10.141.226.17]) with mapi id 15.20.0013.005; Wed, 30 Aug 2017 18:11:04 +0000 From: Adrian Farrel To: Matthew Miller , "secdir@ietf.org" CC: "draft-ietf-teas-pce-central-control.all@ietf.org" , "ietf@ietf.org" , "teas@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-teas-pce-central-control-04 Thread-Index: AQHTIaO9swi/FejJaU6mn0gkr6jvyqKdMj5w Date: Wed, 30 Aug 2017 18:11:04 +0000 Message-ID: References: <150410652452.21632.6924902183838903689@ietfa.amsl.com> In-Reply-To: <150410652452.21632.6924902183838903689@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=afarrel@juniper.net; x-originating-ip: [193.110.55.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR05MB668; 6:PSyP2gD04QaumuEeYzOEvUMA0iErn9ngaixYAE7dlQxq8wv/0DKyO4zW7hfOjcVctZ9XkxSwSmxh7/i9VY0vil0C0uCL9krXbpsD3F7T+CYZ9RSNoUHO3SNiQdm6E9R7ORBHAnCNB3WVmuy/I3y6vwV4slljAxmuA6Zq0BnBUButxb5a+Grrus/TrSE0QhlELODWlIHFUTmzR9HqaYsI8E1e0mm2nv/Bn/y2P5THb3qvDpN5O7wukx+N4elnLG3iTftoroBXV0ZC/JfimfIi1PwlmSTh1StFaA5qEf5pHMmvaaaBP4gdI3fZB62EBjTupDhxC/SLoZcTuORl/ASP4Q==; 5:xtp7Iy1Te7cJ5qf49Moa8vSNqx+9C7fqi616E+FKusCmWV4Q5lZa04caY1Q6hN1hcEyTaWyD6AVVVf6jG7dynDSj9rlyzEyeo0/ipUqkhyAWTilxipLqDMFx6f26DkCNYfF1yk1jpi35O70PhNG02w==; 24:nSncw90/TdaNsYjubfENV9qHCEfRdAxpRaAHslUd94AvibcK22/Bd4dxcrtSz/zY0E0/v8jOObPI6O1Puhge9Ycr8H/252S2OqIC6bhNoj0=; 7:+97kWB2Vc5JwDnL62BxkSrstxOm5WVbM5vRAOwHwIRScF0+7JSQMkoxJcIxVZKmUI4R6u7KSB9MqzXEo6twckAzWiN7dncaTvL4WNufds7mWGgDSO0b5fERFERdBqJvqWr+su/Dek0MfLdnEuTjnp63spRzb/XvicNUCd21PVCdgjUOTR0bpP7UKNb3ogczr0X82efI45bdPYMgXnD/kFDsb3fqejo2Jryw23jtHxTw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 67763ad8-6349-4e68-4dc6-08d4efd27ab7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB668; x-ms-traffictypediagnostic: CO2PR05MB668: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB668; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB668; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(13464003)(377424004)(189002)(199003)(74316002)(97736004)(4326008)(105586002)(2906002)(106356001)(33656002)(7696004)(3660700001)(230783001)(3280700002)(229853002)(6436002)(7736002)(76176999)(77096006)(305945005)(54356999)(6506006)(50986999)(2950100002)(66066001)(101416001)(5660300001)(53546010)(68736007)(2501003)(189998001)(14454004)(99286003)(55016002)(8676002)(6116002)(3846002)(81156014)(81166006)(102836003)(9686003)(54906002)(53936002)(8936002)(478600001)(25786009)(86362001)(6246003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB668; H:CO2PR05MB971.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 18:11:04.5367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB668 Archived-At: Subject: Re: [Teas] Secdir last call review of draft-ietf-teas-pce-central-control-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 18:11:10 -0000 VGhhbmtzIE1hdHRoZXcsDQoNClRoZSBwb2ludCBJIHdhcyBhaW1pbmcgZm9yIGlzIHRoYXQgY29u dHJvbCBwbGFuZXMgYXJlIG9mdGVuIG9wZXJhdGVkIHdpdGggYSAiZG9tYWluIG9mIHRydXN0IiBv ciAiY2hhaW4gb2YgdHJ1c3QiIG1vZGVsIChmb3IgYmV0dGVyIG9yIHdvcnNlKSBidXQgdGhhdCBt YW5hZ2VtZW50IHN5c3RlbXMgYXJlIG9mdGVuIG9wZXJhdGVkIHdpdGggc2VjdXJlIGNoYW5uZWxz IGJldHdlZW4gbWFuYWdlbWVudCBzdGF0aW9uIGFuZCBtYW5hZ2VkIG5vZGUuDQoNCkkgdGhpbmss IGluIG90aGVyIHdvcmRzLCB0aGF0IHRoZSBwb2ludCBjb3ZlcmVkIGJ5IHRoZSB0ZXh0IGlzIHRy dWUgaW4gdG9kYXkncyBuZXR3b3Jrcy4NCg0KQmVzdCwNCkFkcmlhbg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWF0dGhldyBNaWxsZXIgW21haWx0bzpsaW51eHdvbGYraWV0 ZkBvdXRlci1wbGFuZXMubmV0XSANClNlbnQ6IDMwIEF1Z3VzdCAyMDE3IDE2OjIyDQpUbzogc2Vj ZGlyQGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi10ZWFzLXBjZS1jZW50cmFsLWNvbnRyb2wuYWxs QGlldGYub3JnOyBpZXRmQGlldGYub3JnOyB0ZWFzQGlldGYub3JnDQpTdWJqZWN0OiBTZWNkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29udHJvbC0w NA0KDQpSZXZpZXdlcjogTWF0dGhldyBNaWxsZXINClJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQoN CkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRp cmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBi ZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4g cHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMu ICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1l bnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpEb2N1bWVudDoN ClJldmlld2VyOiBNYXR0aGV3IEEuIE1pbGxlcg0KUmV2aWV3IERhdGU6IDIwMTctMDgtMzANCklF VEYgTEMgRW5kIERhdGU6IDIwMTctMDgtMjUNCklFU0cgVGVsZWNoYXQgZGF0ZTogMjAxNy0wOC0z MQ0KDQpTdW1tYXJ5Og0KDQpUaGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiBh cyBJbmZvcm1hdGlvbmFsLCB3aXRoIG9uZSBwb3RlbnRpYWwgbml0Lg0KDQpUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBhbiBvdmVyYWxsIGFyY2hpdGVjdHVyZSAod2l0aCBzb21lIHZhcmlhbnRzKSB1 dGlsaXppbmcgY2VudHJhbCBQQ0UtYmFzZWQgY29udHJvbGxlciBmb3IgU0ROLCBhbmQgaXRzIGlt cGxpY2F0aW9uIG9uIFBDRVAuICBUaGUgZG9jdW1lbnQgbm90ZXMgdGhlIHRyYWRlb2ZmcyBiZXR3 ZWVuIHRoZSB2YXJpYW50cywgaW5jbHVkaW5nIHNvbWUgb2YgdGhlIHZ1bG5lcmFiaWxpdGllcy4N Cg0KTXkgbml0IGlzIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9uczsgSSdtIG5vdCBzdXJl IGhvdyBsaWtlbHkgaW4gcHJhY3RpY2UgYSBjZW50cmFsIGNvbnRyb2xsZXIgYXJjaGl0ZWN0dXJl IHdpbGwgYmUgb3BlcmF0ZWQgd2l0aCAiaGlnaGVyIGxldmVsIG9mIHNlY3VyaXR5IiwgYW5kIHRo ZXJlZm9yZSBub3Qgc3VyZSBpdCdzIHdvcnRoIGNhbGxpbmcgb3V0IGxpa2UgdGhpcy4NCg0KSSBj YW4gc2VlIGhvdyBhIGNlbnRyYWwgY29udHJvbGxlciBtYWtlcyBtYW5hZ2VtZW50IGVhc2llciwg YW5kIHRoYXQgaGFzIGEgcG90ZW50aWFsIGJlbmVmaXQgb2YgYmV0dGVyIHZpc2liaWxpdHkgaW50 byB0aGUgbmV0d29yaydzIG9wZXJhdGlvbiBhbmQgZmluZGluZyBwcm9ibGVtcyAoaW5jbHVkaW5n IHNlY3VyaXR5LXJlbGF0ZWQpIHNvb25lciBhbmQgYmV0dGVyLg0KDQpPdGhlcndpc2UgSSB0aGlu ayB0aGUgcmVzdCBvZiB0aGlzIHNlY3Rpb24gYWRkcmVzc2VzIHRoZSBjb25jZXJucyB0aGF0IGEg Y2VudHJhbCBjb250cm9sbGVyIGFyY2hpdGVjdHVyZSBoYXMuDQoNCg0K From nobody Wed Aug 30 12:52:06 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A8A132351; Wed, 30 Aug 2017 12:51:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-teas-lsp-diversity@ietf.org, teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org, ibagdona.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150412271755.21516.1901292161465183277.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 12:51:57 -0700 Archived-At: Subject: [Teas] Warren Kumari's No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:51:58 -0000 Warren Kumari has entered the following ballot position for draft-ietf-teas-lsp-diversity-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Adam's position. I also think that Ignas Bagdonas' OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-teas-lsp-diversity-08-opsdir-lc-bagdonas-2017-08-30/ ) needs careful consideration / addressing. I almost balloted DISCUSS from them, but trust that they will be addressed. I did find much of the document well written and an easy read. The diagrams were also (surprisingly) clear. I have some nits / comments, mainly around the abstract. 1: "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)" - s/ReserVation/ReSerVation/ (otherwise the (R)RSVP would be (R)RVP) 2: " Three different mechanisms are supported how LSP diversity can be accomplished in the provider or core network: ..." - this doesn't really parse. Perhaps " Three different mechanisms providing LSP diversity in the provider or core network are supported:..." ? Not great, but ... 3: "The solution described in this document is based on the assumption that LSPs are requested sequentially, i.e., the time period between the LSP setup requests for the two LSPs may be longer (days, weeks, months)." -- may be longer than what? Perhaps "may be relatively long" or "may be on the order of days / weeks / months"? 4" "Re-routing the first LSP that may have existed for a longer period of time is not considered." - again, longer than what? Longer than the second (/ Ntn)? Longer than months? From nobody Wed Aug 30 13:11:16 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A671326EC; Wed, 30 Aug 2017 13:11:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-teas-lsp-diversity@ietf.org, teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150412387490.21541.14703587072043039242.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 13:11:14 -0700 Archived-At: Subject: [Teas] Kathleen Moriarty's No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:11:15 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-teas-lsp-diversity-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the SecDir review, but don't see a response so I am bringing attention to it here: https://mailarchive.ietf.org/arch/msg/secdir/pLKMfe4j8dPeNdEgWYu3SAnC-rs From nobody Wed Aug 30 13:20:59 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4481321F1; Wed, 30 Aug 2017 13:20:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-teas-lsp-diversity@ietf.org, teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150412445206.21557.275657217562057272.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 13:20:52 -0700 Archived-At: Subject: [Teas] Eric Rescorla's No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:20:52 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-teas-lsp-diversity-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not sure that the security considerations here are accurate. Specifically, the PAS seems like it might potentially leak information about paths, because if I am able to learn someone else's PAS values, I can tell if they are routed along the same paths as I am. Is that correct? If so, it seems like it might be useful to recommend self-encrypting PAS values so that two identical paths given to separate people have different PAS values. Also, it seems like it S 2.3 would be clearer if you factored out the algorithm for processing the XRO values from the differential treatment depending on the L bit. Perhaps you could just have one list and use [SHOULD (L=1), MUST(L=0)] or something? From nobody Wed Aug 30 20:50:39 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FC41328EA; Wed, 30 Aug 2017 20:50:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-teas-pce-central-control@ietf.org, Vishnu Beeram , teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150415143178.16864.7645859577213327042.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 20:50:31 -0700 Archived-At: Subject: [Teas] Adam Roach's No Objection on draft-ietf-teas-pce-central-control-04: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 03:50:32 -0000 Adam Roach has entered the following ballot position for draft-ietf-teas-pce-central-control-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I like how clearly this document spells out the nature of the work that is to be performed to adapt PCEP to enable the described network architecture. It's not entirely clear to me what value it has as an archival document (rather than simply being used internally by the working group to guide future development). Has the working group explicitly discussed why they might want this published as an RFC? This document uses the term "control plane" rather extensively without concretely defining it. While I can infer some things about what is meant, it appears to be intended as a very concrete and specific term. In particular, it seems to diverge from how that term is used in (e.g.) voice networks, to the point of meaning nearly the opposite (that is: I've gathered that it refers to the exchange of routing information on the same paths as are used to exchange traffic). If there is a formal definition of the term in some referenced document, I would think a citation to it would be useful. If not, please take a stab at a formal definition of this term early in this document. Section 2.1.2 suggests that inter-controller state sync can be achieved by sharing a common back-end database ("...or by using a shared database."). Without further qualifying the database as being also distributed, this simply pushes the single point of failure from the controller to the database. Please add terms to qualify the database itself as being highly-available/distributed. From nobody Wed Aug 30 21:00:06 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2A812422F; Wed, 30 Aug 2017 21:00:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-teas-lsp-diversity@ietf.org, teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150415200057.16839.12339537452181087892.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 21:00:00 -0700 Archived-At: Subject: [Teas] Suresh Krishnan's No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 04:00:01 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-teas-lsp-diversity-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 2.1 Is there a separate diversity identifier type called "IPv6 Client Initiated Identifier" as referenced in the following text "When the diversity identifier type is set to "IPv6 Client Initiated Identifier"" If there isn't such a DI Type, can you please fix this text. From nobody Thu Aug 31 01:32:20 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AB1132358; Thu, 31 Aug 2017 01:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2CTr9rQYwto; Thu, 31 Aug 2017 01:32:10 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0098.outbound.protection.outlook.com [104.47.38.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925F613239C; Thu, 31 Aug 2017 01:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=arUONHtmbMl1wm2JGoecQHtCHl371QDh4Ht43XKF9jk=; b=hkgrXeSxu8IapBBmBc++OUU5fVz0hWOo71EqqQqvPg7xxEeySWQnS2JEKBqrnUQrkG42IURzndarREJ4HtqrXwNCI/4R6gLAD5JaYkGj+DW/DwR4uL8DDKIUmnDQi8hDE1KbS8OPs/1/vQjwyLosWdcg4aQ/ybrtfbWdcYyzgr0= Received: from DM2PR05MB973.namprd05.prod.outlook.com (10.141.176.149) by DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Thu, 31 Aug 2017 08:32:08 +0000 Received: from DM2PR05MB973.namprd05.prod.outlook.com ([fe80::1982:6249:31cd:ffc2]) by DM2PR05MB973.namprd05.prod.outlook.com ([fe80::1982:6249:31cd:ffc2%13]) with mapi id 15.20.0013.007; Thu, 31 Aug 2017 08:32:07 +0000 From: Adrian Farrel To: Adam Roach , The IESG CC: "draft-ietf-teas-pce-central-control@ietf.org" , Vishnu Pavan Beeram , "teas-chairs@ietf.org" , "Vishnu Pavan Beeram" , "teas@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-teas-pce-central-control-04: (with COMMENT) Thread-Index: AQHTIgxO4cN06Z1htkmtSNPWZEE+3aKeFBgw Date: Thu, 31 Aug 2017 08:32:07 +0000 Message-ID: References: <150415143178.16864.7645859577213327042.idtracker@ietfa.amsl.com> In-Reply-To: <150415143178.16864.7645859577213327042.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=afarrel@juniper.net; x-originating-ip: [193.110.55.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR05MB528; 6:qSwpMb7d0NWT/f8uHSiDAJsmWhO+D8VvhElmsLPj9zleO2d1aVZBwl26LEucxJ4T9HtOHzbY2yc3geCvj4lj+9ER5oFB4DNep6gCFJzeTwttIuB6OJXOnUxa5XKONXCOEhnR/kSOlIdMfWD8qTqf1Wy1pXohpW4NYhUbHHDVLNMnTdNEQW7xGF7PUA/Er6jPoeXcPirXqUAYr8ZzpoEq2+dexjBbNnYPzz40xTv9o91w7anMqRKQ+yq1fwXrMnOdJZIH6Zi5Oi/WgC7RhKYvhwyyyuH1CyWE0SzWQHnMcrEr4ffwz8MZ8tYmE+k5zWE9sqXPXUBPT6lnBKrpdjeLZQ==; 5:It8+2yc30gOlykXL+NELzM/3EB3FPS92jnNCYBID0lIEJeFjhUXEr+RSgr2Wyi26WUnzwHnjXyD79HKuMpq7ugEyrokGx+2B6Vz3yMZYgXpDETjwWcOkV9A5TXksK+tnYtirK9xLTM5qH8o/eTgeFw==; 24:SpiebsOqE0oLoBOFL2mM8eSNB4CO1MOhxXyAv69WqXtHi+9xU2XJnFN2RXcdzaMEYjpyf4nFDhzZkQR1+NopEZQv+g28julOwo4A317NkEM=; 7:yZ0ZOOJPnl/XnGlvDv9Te4kIRHNnd1SWWeBYOV2ZR7Gj7N/sLK3bhZE50Cx/uoFYghWBTKGsQwrDIRQUqabmZ2sO0DqlFeSQOz511i8tR1ZJXiRYsRhN54xim2MQ9KqGOVer/Yrvbp7+LoyRHrQNdJjlIuNzQIW5ELp3eIGkHBK7enHlBKPoISDK9WylqIGX+Rlx2TxSc7VJ4DCmao15USiTiSiyqsJtU1mIskmab7c= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(189002)(101416001)(55016002)(229853002)(2950100002)(106356001)(105586002)(7736002)(6436002)(74316002)(8936002)(4326008)(76176999)(14454004)(33656002)(50986999)(54356999)(2900100001)(25786009)(6506006)(3280700002)(3660700001)(2906002)(6116002)(3846002)(102836003)(478600001)(81156014)(86362001)(81166006)(8676002)(230783001)(66066001)(7696004)(189998001)(54906002)(5660300001)(5250100002)(9686003)(305945005)(99286003)(68736007)(53936002)(6246003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB528; H:DM2PR05MB973.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 10ed756e-be9d-4a2c-0c39-08d4f04ac435 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR05MB528; x-ms-traffictypediagnostic: DM2PR05MB528: x-exchange-antispam-report-test: UriScan:(35073007944872)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR05MB528; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR05MB528; x-forefront-prvs: 04163EF38A received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2017 08:32:07.4928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB528 Archived-At: Subject: Re: [Teas] Adam Roach's No Objection on draft-ietf-teas-pce-central-control-04: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 08:32:13 -0000 SGVsbG8gQWRhbSwNCg0KPiBJIGxpa2UgaG93IGNsZWFybHkgdGhpcyBkb2N1bWVudCBzcGVsbHMg b3V0IHRoZSBuYXR1cmUgb2YgdGhlIHdvcmsgDQo+IHRoYXQgaXMgdG8gYmUgcGVyZm9ybWVkIHRv IGFkYXB0IFBDRVAgdG8gZW5hYmxlIHRoZSBkZXNjcmliZWQgDQo+IG5ldHdvcmsgYXJjaGl0ZWN0 dXJlLiBJdCdzIG5vdCBlbnRpcmVseSBjbGVhciB0byBtZSB3aGF0IHZhbHVlIGl0DQo+IGhhcyBh cyBhbiBhcmNoaXZhbCBkb2N1bWVudCAocmF0aGVyIHRoYW4gc2ltcGx5IGJlaW5nIHVzZWQgDQo+ IGludGVybmFsbHkgYnkgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gZ3VpZGUgZnV0dXJlIGRldmVsb3Bt ZW50KS4NCj4gSGFzIHRoZSB3b3JraW5nIGdyb3VwIGV4cGxpY2l0bHkgZGlzY3Vzc2VkIHdoeSB0 aGV5IG1pZ2h0IHdhbnQNCj4gdGhpcyBwdWJsaXNoZWQgYXMgYW4gUkZDPw0KDQpJJ2xsIGxldCB0 aGUgV0cgY2hhaXJzIGNvbW1lbnQgb24gd2hhdCB0aGUgb3BpbmlvbiBvZiB0aGUgV0cgaXMsIGJ1 dCBJIHdvdWxkIG5vdGUgdGhhdCB0aGUgcHVibGljYXRpb24gcmVxdWVzdCBjYW1lIGZyb20gdGhl IFdHIHNvIChJIGFzc3VtZSkgdGhlIFdHIHJlcXVlc3RlZCBwdWJsaWNhdGlvbi4NCg0KRm9yIG1l IChhcyBlZGl0b3IsIGFuZCB0aGVyZWZvcmUgc29tZW9uZSB3aG8gYm90aGVyZWQgdG8gcHJvZHVj ZSB0aGlzIGFzIGEgY2FuZGlkYXRlIGZvciBiZWluZyBhbiBhcmNoaXZhbCBkb2N1bWVudCkgdGhl IHZhbHVlIGhlcmUgd2FzIG1ha2luZyBhIHN0YXRlbWVudCB0aGF0IHdhcyBwZXJzaXN0ZW50IGFu ZCBzdGFibGUsIGFuZCByZWNvcmRpbmcgdGhlIHJlc3VsdCBvZiBkaXNjdXNzaW9ucyBhbmQgZGVj aXNpb25zIGluIHRoZSBXRy4gVEVBUyBhcHBlYXJlZCAodG8gbWUpIHRvIGhhdmUgc29tZSBwcmV0 dHkgd2lkZSByYW5naW5nIGRpc2N1c3Npb25zIHRoYXQga2VwdCByZWludmVudGluZyB0aGVtc2Vs dmVzLiBQb2ludGluZyBiYWNrIHRvIG1haWxpbmcgbGlzdCB0aHJlYWRzIHdhcyBub3QgYSBnb29k IHNvbHV0aW9uLCBhbmQgKGFzIHlvdSBjYW4gc2VlIGZyb20gdGhlIHNpemUgb2YgdGhlIGRvY3Vt ZW50KSB3YXMgbmV2ZXIgZ29pbmcgdG8gbWFrZSBpdCBwb3NzaWJsZSB0byBmaW5kIGFsbCBvZiB0 aGUgY29ybmVycy4gU28sIHdvcmtpbmcgYXMgdGhlIFRlY2huaWNhbCBBZHZpc29yIGZvciB0aGUg V0csIEkgdXNlZCB0aGlzIGRvY3VtZW50IHRvIHB1bGwgdG9nZXRoZXIgYW5kIGNhcHR1cmUgdGhv c2Ugb3BpbmlvbnMgYW5kIHRoZSBXRyBjb25zZW5zdXMgc28gdGhhdCB3ZSBjb3VsZCBuYWlsIGl0 IGRvd24gYW5kIGNvbnRpbnVlIHdvcmsgd2l0aG91dCByZW9wZW5pbmcgdGhlIGRlYmF0ZSBldmVy eSB0aHJlZSBtb250aHMuDQoNCj4gVGhpcyBkb2N1bWVudCB1c2VzIHRoZSB0ZXJtICJjb250cm9s IHBsYW5lIiByYXRoZXIgZXh0ZW5zaXZlbHkNCj4gd2l0aG91dCBjb25jcmV0ZWx5IGRlZmluaW5n IGl0LiBXaGlsZSBJIGNhbiBpbmZlciBzb21lIHRoaW5ncyBhYm91dA0KPiB3aGF0IGlzIG1lYW50 LCBpdCBhcHBlYXJzIHRvIGJlIGludGVuZGVkIGFzIGEgdmVyeSBjb25jcmV0ZSBhbmQNCj4gc3Bl Y2lmaWMgdGVybS4gSW4gcGFydGljdWxhciwgaXQgc2VlbXMgdG8gZGl2ZXJnZSBmcm9tIGhvdyB0 aGF0IHRlcm0NCj4gaXMgdXNlZCBpbiAoZS5nLikgdm9pY2UgbmV0d29ya3MsIHRvIHRoZSBwb2lu dCBvZiBtZWFuaW5nIG5lYXJseSB0aGUNCj4gb3Bwb3NpdGUgKHRoYXQgaXM6IEkndmUgZ2F0aGVy ZWQgdGhhdCBpdCByZWZlcnMgdG8gdGhlIGV4Y2hhbmdlIG9mIA0KPiByb3V0aW5nIGluZm9ybWF0 aW9uIG9uIHRoZSBzYW1lIHBhdGhzIGFzIGFyZSB1c2VkIHRvIGV4Y2hhbmdlDQo+IHRyYWZmaWMp LiBJZiB0aGVyZSBpcyBhIGZvcm1hbCBkZWZpbml0aW9uIG9mIHRoZSB0ZXJtIGluIHNvbWUgcmVm ZXJlbmNlZA0KPiBkb2N1bWVudCwgSSB3b3VsZCB0aGluayBhIGNpdGF0aW9uIHRvIGl0IHdvdWxk IGJlIHVzZWZ1bC4gSWYgbm90LCANCj4gcGxlYXNlIHRha2UgYSBzdGFiIGF0IGEgZm9ybWFsIGRl ZmluaXRpb24gb2YgdGhpcyB0ZXJtIGVhcmx5IGluIHRoaXMNCj4gZG9jdW1lbnQuDQoNCkkgY2h1 Y2tsZWQgcXVpdGUgYSBsb3QgYXQgdGhpcy4gVGhhbmtzLg0KDQpJJ20gbm90IGdvaW5nIHRvIGdy ZXAgb3V0IHRoZSBkZWZpbml0aW9uIG9mICJjb250cm9sIHBsYW5lIiBpbiBhbnkgb2YgdGhlIHZv aWNlIGRvY3VtZW50cy4gVGhhdCdzIHByb2JhYmx5IGEgZGlzdHJhY3Rpb24sIGJ1dCBJJ20gc3Vy ZSBpdCBpcyB0aGVyZSwgY2xlYXJseSBkZWZpbmVkLCBhbmQgYWx3YXlzIHJlZmVyZW5jZWQuIEkg d291bGQgbm90ZSB0aGF0IHByb3RvY29scyBzdWNoIGFzIFNTNyBhcmUgY29udHJvbCBwbGFuZSBw cm90b2NvbHMgaW4gZXhhY3RseSB0aGUgd2F5IHRoZSB0ZXJtIGlzIHVzZWQgYWNyb3NzIHRoZSB3 aG9sZSBSb3V0aW5nIEFyZWEgZXZlbiBpZiB0aGUgcHJvdG9jb2wgaXMgdXNlZCBpbiBhIGRpZmZl cmVudCBsYXllciBvZiB0aGUgbmV0d29yay4NCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCB5b3UgaGF2 ZSBnb3Qgc3Vja2VkIGluIHRvIHdoYXQgaXMgZWZmZWN0aXZlbHkgYSBkaXNjdXNzaW9uIG9mIGEg Y29udHJvbCBjaGFubmVsIGFuZCBub3QgdGhlIGNvbnRyb2wgcGxhbmUgaXRzZWxmLiBUaGlzIG1h eSBsZWFkIHlvdSB0byBjb25zaWRlciB0aGF0IGFuIElHUCBydW5uaW5nIGluIGFuIElQIG5ldHdv cmsgaXMgYSBzcGVjaWFsIGNhc2Ugd2hlcmUgdGhlIGNvbnRyb2wgY2hhbm5lbCBpcyBjb2luY2lk ZW50IHdpdGggdGhlIGRhdGEgY2hhbm5lbCBhbmQgYWxsb3dzIHRoZSBjb250cm9sIHByb3RvY29s IHRvIG1vbml0b3IgdGhlIGRhdGEgY2hhbm5lbC4gQnV0LCBpbiBnZW5lcmFsLCBhIGNvbnRyb2wg cGxhbmUgY2FuIGJlIGRpc3RyaWJ1dGVkIG9yIGNlbnRyYWxpemVkLCBhbmQgdGhlIGNvbnRyb2wg Y2hhbm5lbHMgY2FuIGJlIGluLWJhbmQsIGluLWZpYmVyIChidXQgb3V0LW9mLWJhbmQpLCBvciBv dXQtb2YtYmFuZC4gKEFjdHVhbGx5LCB0aGUgSVBQTSBXRyBpcyBjdXJyZW50bHkgYWxzbyBsb29r aW5nIGF0IGluLWRhdGEgY29udHJvbCBjaGFubmVscyAtIGJ1dCB0aGF0IG1heSBiZSBhIGRpZmZl cmVudCBtYXR0ZXIuKSANCg0KVGhpcyBkb2N1bWVudCB3b3VsZCBwcm9iYWJseSBub3QgYmUgdGhl IHBsYWNlIHRvIGF0dGVtcHQgYSBjb25zZW5zdXMgZGVmaW5pdGlvbiBvZiB3aGF0IHRoZSBjb250 cm9sICBwbGFuZSBpcy4gU3VjaCBhIGRlZmluaXRpb24gbWlnaHQgYXR0cmFjdCBsb3RzIG9mIGNp dGF0aW9ucywgYW5kIHRoaXMgZG9lc24ndCBzZWVtIHRoZSByaWdodCBkb2N1bWVudCBmb3IgdGhh dC4gIFNvIG1heWJlIHdlIHNob3VsZCBsb29rIGZvciBhIHNlcGFyYXRlIGRlZmluaXRpb24gc29t ZXdoZXJlLg0KDQpBcm91bmQgYSBodW5kcmVkIHllYXJzIGFnbyBJIHdyb3RlOiAiVGhlIENvbnRy b2wgUGxhbmUgaXMgd2hlcmUgdGhlIHNpZ25hbGluZyBhbmQgY29udHJvbCBwcm90b2NvbHMgb3Bl cmF0ZSB0byBkeW5hbWljYWxseSBpbnRlcmFjdCBiZXR3ZWVuIGNvbXB1dGVycy4iIEl0J3Mgd29y dGggbm90aW5nIHRoYXQgc29tZSBwZW9wbGUgY29uc2lkZXIgdGhlIE1hbmFnZW1lbnQgUGxhbmUg YXMgYmVpbmcgcGFydCBvZiB0aGUgQ29udHJvbCBQbGFuZSwgYW5kIHNvbWUgcGVvcGxlIHRoaW5r IHRoYXQgdGhlIFJvdXRpbmcgUGxhbmUgaXMgZGlzdGluY3QgZm9ybSB0aGUgQ29udHJvbCBQbGFu ZS4NCg0KSSB3ZW50IGFuZCBjaGVja2VkIGluIFJGQyA0Mzk3LCBidXQgZXZlbiB0aGF0IGFzc3Vt ZXMgImNvbnRyb2wgcGxhbmUiIGFzIGEgd2VsbC1rbm93biBjb250ZXh0IHdoaWxlIGRlZmluaW5n ICJjb250cm9sIHBsYW5lIG5ldHdvcmsiLCAiY29udHJvbGxlciIsIGFuZCAiY29udHJvbCBwbGFu ZSBwcm90b2NvbCIuDQoNCkRvZXMgdGhpcyBnZXQgdXMgYW55d2hlcmUsIG9yIGlzIHRoZSB0ZXJt IHN1ZmZpY2llbnRseSB3ZWxsIHVuZGVyc3Rvb2QgaW4gaXRzIGNvbnRleHQgdGhhdCB3ZSBzaG91 bGQgbW92ZSBvbj8gSSBkb3VidCB0aGF0IHlvdSdsbCBmaW5kIHRoZSBlbmVyZ3kgaW4gdGhlIFJv dXRpbmcgQXJlYSB0byB3b3JrIG9uIGZvcm1hbCBkZWZpbml0aW9ucyBmb3IgdGhlc2UgdGhpbmdz IChhZnRlciBhbGwsIHRoaXMgaXMgbm90IHRoZSBJVFUtVCksIGJ1dCBtYXliZSB0aGUgSUVTRyB3 b3VsZCBsaWtlIHRvIGxlYWQgb24gdGhpcyBmdW5kYW1lbnRhbCBhcmNoaXRlY3R1cmFsIHdvcms6 IHRoZXkgY291bGQgc3RlZXIgYnkgdHJ5aW5nIHRvIGNhcHR1cmUgYSBkZWZpbml0aW9uIG9mIHRo ZXNlIHRlcm1zIHRoYXQgd291bGQgc3BhbiB0aGUgd2hvbGUgSUVURi4NCg0KPiBTZWN0aW9uIDIu MS4yIHN1Z2dlc3RzIHRoYXQgaW50ZXItY29udHJvbGxlciBzdGF0ZSBzeW5jIGNhbiBiZSBhY2hp ZXZlZCBieQ0KPiBzaGFyaW5nIGEgY29tbW9uIGJhY2stZW5kIGRhdGFiYXNlICgiLi4ub3IgYnkg dXNpbmcgYSBzaGFyZWQgZGF0YWJhc2UuIikuDQo+IFdpdGhvdXQgZnVydGhlciBxdWFsaWZ5aW5n IHRoZSBkYXRhYmFzZSBhcyBiZWluZyBhbHNvIGRpc3RyaWJ1dGVkLCB0aGlzIHNpbXBseQ0KPiBw dXNoZXMgdGhlIHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlIGZyb20gdGhlIGNvbnRyb2xsZXIgdG8g dGhlIGRhdGFiYXNlLiBQbGVhc2UNCj4gYWRkIHRlcm1zIHRvIHF1YWxpZnkgdGhlIGRhdGFiYXNl IGl0c2VsZiBhcyBiZWluZyBoaWdobHktYXZhaWxhYmxlL2Rpc3RyaWJ1dGVkLg0KDQpZZXMuIEl0 IGlzIHdvcnRoIGFkZGluZyBzb21ldGhpbmcgbGlrZS4uLg0KSXQgc2hvdWxkIGJlIG5vdGVkIHRo YXQgYWRkcmVzc2luZyB0aGUgc3luY2hyb25pemF0aW9uIHByb2JsZW0gdGhyb3VnaCBhIHNoYXJl ZCBkYXRhYmFzZSBtYXkgYmUgaGlkaW5nIHRoZSBpc3N1ZXMgb2YgY29uZ2VzdGlvbiBhbmQgb2Yg YSBzaW5nbGUgcG9pbnQgb2YgZmFpbHVyZTogd2hvbGUgdGhlIGNvbnRyb2xsZXJzIG1heSBoYXZl IGJlZW4gbWFkZSByZXNpbGllbnQgYnkgYWxsb3dpbmcgcmVkdW5kYW5jeSwgdGhlIHNoYXJlZCBk YXRhYmFzZSBpcyBzdGlsbCBhIHByb2JsZW0gYW5kIHNvIHRoZSB3aG9sZSBzeXN0ZW0gaXMgc3Rp bGwgdnVsbmVyYWJsZS4NCg0KQ2hlZXJzLA0KQWRyaWFuDQo= From nobody Thu Aug 31 05:08:11 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE22132D6E; Thu, 31 Aug 2017 05:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuitVDxSLxZ0; Thu, 31 Aug 2017 05:08:01 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B03132D5D; Thu, 31 Aug 2017 05:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2371; q=dns/txt; s=iport; t=1504181278; x=1505390878; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=N1WrMua3rcuwPoae0GKi4qQsUX7AN42/H1AND4urxjU=; b=KTH6R5p/Wx9bDxBreKpj89x4gt1KBMP/BvVtfjf9WR9T9VaflPUDawWZ aP6SWz5GGwB1inXkSu9M11cCmKqMA6eAcvyGxaijkIqwiRhPFftQ1dCem Ke7gwfmRocnR+qEA6zEzw4H7FJj01AxYf+JskiSnPs00B5LFMZTvya5FE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAgAx+6dZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD6BFYN3ixSRG5YnDoIELoUZAoRXFgECAQEBAQEBAWsohRkBBSM?= =?us-ascii?q?VQRALGAICJgICVwYBDAgBAReKFhCuZ4Ini0UBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RkFgQ2CHYNQgWIsgn2EQgESAYMygmEBBIoDlmyHW4NaiRyCE4Vng1kkhneNUoh?= =?us-ascii?q?zJgkogQILMiEIHBWFYRwZgVA+NgGICoIyAQEB?= X-IronPort-AV: E=Sophos;i="5.41,453,1498521600"; d="scan'208";a="696873956" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2017 12:07:53 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7VC7rr0002393; Thu, 31 Aug 2017 12:07:53 GMT To: Warren Kumari , The IESG Cc: draft-ietf-teas-lsp-diversity@ietf.org, ibagdona.ietf@gmail.com, lberger@labn.net, teas-chairs@ietf.org, teas@ietf.org References: <150412271755.21516.1901292161465183277.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <0ff6ad10-ada1-1cb1-7b01-0ad9b3c0aed9@cisco.com> Date: Thu, 31 Aug 2017 14:07:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150412271755.21516.1901292161465183277.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Teas] Warren Kumari's No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:08:04 -0000 On 8/30/2017 9:51 PM, Warren Kumari wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-teas-lsp-diversity-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Adam's position. I also think that Ignas Bagdonas' OpsDir review ( > https://datatracker.ietf.org/doc/review-ietf-teas-lsp-diversity-08-opsdir-lc-bagdonas-2017-08-30/ > ) needs careful consideration / addressing. I almost balloted DISCUSS from > them, but trust that they will be addressed. Exactly my thoughts as well, mentioned to Deborah yesterday. Regards, Benoit > > I did find much of the document well written and an easy read. The diagrams > were also (surprisingly) clear. > > I have some nits / comments, mainly around the abstract. > 1: "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)" - > s/ReserVation/ReSerVation/ (otherwise the (R)RSVP would be (R)RVP) > > 2: " Three different mechanisms are supported how LSP diversity can be > accomplished in the provider or core network: ..." - this doesn't really parse. > Perhaps " Three different mechanisms providing LSP diversity in the provider or > core network are supported:..." ? Not great, but ... > > 3: "The solution described in this document is based on the assumption that > LSPs are requested sequentially, i.e., the time period between the LSP setup > requests for the two LSPs may be longer (days, weeks, months)." -- may be > longer than what? Perhaps "may be relatively long" or "may be on the order of > days / weeks / months"? > > 4" "Re-routing the first LSP that may have existed for a longer period of time > is not considered." - again, longer than what? Longer than the second (/ Ntn)? > Longer than months? > > > . > From nobody Thu Aug 31 08:30:49 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E585D126B71 for ; Thu, 31 Aug 2017 08:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=cienacorp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZtkpB8Q6rB7 for ; Thu, 31 Aug 2017 08:30:44 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0057.outbound.protection.outlook.com [104.47.32.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E667B13236D for ; Thu, 31 Aug 2017 08:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cienacorp.onmicrosoft.com; s=selector1-ciena-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nHPFGSDm7A1mMVqA+C0umjqLU3yEf83XQxlEVYSi5nU=; b=Ufvs7WpIAtoR1M31m/oX8uBVHpcldpHIpxUwQj6VLSlGjuq6/9ye0+OKHCE0nQO5qgublk/661eJjyiiGjTNCZsDyWfzaL9K+2WJx4D3FOADbXWW3SPKwEFxkAiH0bZZbnRDkadUAuU2e4baxG8hTLkSrd2HZtkQEA9eOC/fflA= Received: from BN6PR04MB1029.namprd04.prod.outlook.com (10.174.234.23) by BN6PR04MB1012.namprd04.prod.outlook.com (10.174.234.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Thu, 31 Aug 2017 15:30:39 +0000 Received: from BN6PR04MB1029.namprd04.prod.outlook.com ([10.174.234.23]) by BN6PR04MB1029.namprd04.prod.outlook.com ([10.174.234.23]) with mapi id 15.20.0013.012; Thu, 31 Aug 2017 15:30:39 +0000 From: "Shah, Himanshu" To: Lou Berger , Xufeng Liu , Igor Bryskin , "vbeeram@juniper.net" , "tsaad@cisco.com" , OSCAR GONZALEZ DE DIOS , "Italo.Busi@huawei.com" , "carlo.perocchio@ericsson.com" , "Beller, Dieter (Nokia - DE)" , "sergio.belotti@nokia.com" , TEAS WG Thread-Topic: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo Thread-Index: AQHTHd9bJUOYAOBJMkai38LMHN4FDqKeXWQA Date: Thu, 31 Aug 2017 15:30:38 +0000 Message-ID: <7C5B540D-E2A8-4AE9-BAD6-987BB6ECF7F4@ciena.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.0.170702 authentication-results: spf=none (sender IP is ) smtp.mailfrom=hshah@ciena.com; x-originating-ip: [65.200.62.25] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR04MB1012; 6:Gj5RayvWCeVDLRdOxzj4UA61ObxRU1KrzUjVw7krrgVNW6GU3bG0JsLPX8t2ensiQu08rY7OjNNBAYaB4eOXT4aafIziFALaDz7UbJd/Wh6STgeT4Wn46Hcmgen8KFxIgV0cH+VxVK5Z/mhRh33pn7xZK251W6ZVJ9ewB8G8VotJ9n5mgRLrjynxcYEIZKHOrEu55yB6rDiiAKkGTMVOfitcg4lDfVG6ankNfNg4zx4ZZbwyAk+yptGOS2JpP2QndpfRttWtxJ5WGWULYszcvpaN0kfJuSXQACzdy6kjua6cepUxD2y+z8vmhTyTGgq2o4YZHwhg9R6AduOopRv8yw==; 5:pOYbTRONQh/NPIQIkwX8f5MYY6Mr9KgoUt1uM3j2+Nlmh//VrLboN7mHbCdfxXF5H14eIzP/Lfry20AyUY20kujPqYOXAZCJ06sG5d3TaZSyL2C77mnpMqQoPMiuvvxlOCs8SvJR0qSJaOZTm1GI6Q==; 24:He66QOW3bf3TieJYMZoNb5XR40oqFNbzuhJAaC7IDCRiS7fr6548BZzT9gLb1qjh8nPW50y/Jg1qK+6qfOAIuKrktkH9i6ZDv6/HtfFZHTk=; 7:/wOz1z221DBUgTc676ugfZ58zwzXmd2xZ2iSZ37hJR48NoMnSp/V2eu3ddFiS3qljs3IG0SSJxMwvjXbP5dmH5te8B5tCmiwa94RgcU430Fpr6MMqdj28YSh/wRzn1nf2cCVGhXnvXo105JjHdi3eEnJsguW10wbtX8hToTgLouXFwJeoGSvYfrH54R3CjerYXEo1zRLbm/QoMHe1hHA+Fo+xPyhZwfqVAAROQ5uZps= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 90a2fc34-20f2-48c3-8b21-08d4f0853bf7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR04MB1012; x-ms-traffictypediagnostic: BN6PR04MB1012: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(50582790962513)(82608151540597)(95692535739014)(21748063052155)(21534305686606)(138986009662008); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR04MB1012; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR04MB1012; x-forefront-prvs: 04163EF38A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(199003)(189002)(2906002)(7736002)(2201001)(478600001)(1941001)(76176999)(82746002)(50986999)(6116002)(54356999)(102836003)(3846002)(229853002)(8666007)(86362001)(3660700001)(6506006)(105586002)(7416002)(106356001)(66066001)(33656002)(6436002)(68736007)(77096006)(6486002)(230783001)(3280700002)(25786009)(5660300001)(36756003)(6512007)(2950100002)(101416001)(54896002)(83716003)(6306002)(81156014)(81166006)(14454004)(4001350100001)(83506001)(966005)(2900100001)(8676002)(97736004)(8936002)(236005)(2501003)(99286003)(189998001)(53936002)(6246003)(53546010)(606006)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR04MB1012; H:BN6PR04MB1029.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_7C5B540DE2A84AE9BAD6987BB6ECF7F4cienacom_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2017 15:30:39.2227 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR04MB1012 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 15:30:48 -0000 --_000_7C5B540DE2A84AE9BAD6987BB6ECF7F4cienacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K DQoNClRoYW5rcywNCkhpbWFuc2h1DQoNCkZyb206IFRlYXMgPHRlYXMtYm91bmNlc0BpZXRmLm9y Zz4gb24gYmVoYWxmIG9mIExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQpEYXRlOiBGcmlk YXksIEF1Z3VzdCAyNSwgMjAxNyBhdCA0OjE4IFBNDQpUbzogWHVmZW5nIExpdSA8WHVmZW5nX0xp dUBqYWJpbC5jb20+LCBJZ29yIEJyeXNraW4gPGlnb3IuYnJ5c2tpbkBodWF3ZWkuY29tPiwgVmlz aG51IEJlZXJhbSA8dmJlZXJhbUBqdW5pcGVyLm5ldD4sIFRhcmVrIFNhYWQgPHRzYWFkQGNpc2Nv LmNvbT4sICJTaGFoLCBIaW1hbnNodSIgPGhzaGFoQGNpZW5hLmNvbT4sIE9TQ0FSIERFIERJT1Mg PG9zY2FyLmdvbnphbGV6ZGVkaW9zQHRlbGVmb25pY2EuY29tPiwgIkl0YWxvLkJ1c2lAaHVhd2Vp LmNvbSIgPEl0YWxvLkJ1c2lAaHVhd2VpLmNvbT4sICJjYXJsby5wZXJvY2NoaW9AZXJpY3Nzb24u Y29tIiA8Y2FybG8ucGVyb2NjaGlvQGVyaWNzc29uLmNvbT4sIERpZXRlciBCZWxsZXIgPGRpZXRl ci5iZWxsZXJAbm9raWEuY29tPiwgU2VyZ2lvIEJlbG90dGkgPHNlcmdpby5iZWxvdHRpQG5va2lh LmNvbT4sICJ0ZWFzQGlldGYub3JnIiA8dGVhc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtUZWFzXSBS ZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRvcG8NCg0KQXV0aG9ycywg Q29udHJpYnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24gZm9yIFdHIExh c3QgQ2FsbA0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0 cyBpZGVudGlmaWVkIGFib3ZlPw0KDQpQbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoiTm8sIEknbSBu b3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCm9yDQoiWWVz LCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KDQpJZiBzbywg aGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBy dWxlcw0KKHNlZSBSRkNzIDM2NjksIDUzNzggYW5kIDgxNzkgZm9yIG1vcmUgZGV0YWlscyk/DQoN CklmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJZZXMsIHRoZSBJ UFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyIN Cm9yDQoiTm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCINCg0KSWYgeW91IGFuc3dl ciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsNCmFw cHJvcHJpYXRlLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBj b250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlz IGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZQ0KYXdhcmUgb2YgYW55 IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0 DQpzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRo b3IgYW5kIGxpc3RlZA0KY29udHJpYnV0b3IuIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0Yg WU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUw0KVE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24g dGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3Rl ZA0KYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2Js aWdhdGlvbnMgdW5kZXINCnRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0 byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZQ0KYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBh biBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tDQpwYXJ0aWNpcGF0aW5nIGlu IGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXINCnVuZGlzY2xv c2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVk IGFib3ZlDQphbmQNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93 aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpURUFTIFdHIENoYWlycw0K DQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVz c2FnZSBpbiB5b3VyDQpyZXNwb25zZS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KVGVhcyBtYWlsaW5nIGxpc3QNClRlYXNAaWV0Zi5vcmc8bWFp bHRvOlRlYXNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RlYXMNCg0KDQo= --_000_7C5B540DE2A84AE9BAD6987BB6ECF7F4cienacom_ Content-Type: text/html; charset="utf-8" Content-ID: <5E4AA7DC427DBA4C8803C78434C4ACDB@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2Fucy1zZXJpZjsNCgljb2xv cjojMDQzMkZGOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOml0YWxpYzt9DQpz cGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFt ZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDQzMkZGIj5ObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlz IGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFz JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzA0MzJGRiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+ PC9pPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+ SGltYW5zaHU8L3NwYW4+PC9pPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+PG86 cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPlRlYXMgJmx0O3RlYXMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9m IExvdSBCZXJnZXIgJmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZy aWRheSwgQXVndXN0IDI1LCAyMDE3IGF0IDQ6MTggUE08YnI+DQo8Yj5UbzogPC9iPlh1ZmVuZyBM aXUgJmx0O1h1ZmVuZ19MaXVAamFiaWwuY29tJmd0OywgSWdvciBCcnlza2luICZsdDtpZ29yLmJy eXNraW5AaHVhd2VpLmNvbSZndDssIFZpc2hudSBCZWVyYW0gJmx0O3ZiZWVyYW1AanVuaXBlci5u ZXQmZ3Q7LCBUYXJlayBTYWFkICZsdDt0c2FhZEBjaXNjby5jb20mZ3Q7LCAmcXVvdDtTaGFoLCBI aW1hbnNodSZxdW90OyAmbHQ7aHNoYWhAY2llbmEuY29tJmd0OywgT1NDQVIgREUgRElPUyAmbHQ7 b3NjYXIuZ29uemFsZXpkZWRpb3NAdGVsZWZvbmljYS5jb20mZ3Q7LCAmcXVvdDtJdGFsby5CdXNp QGh1YXdlaS5jb20mcXVvdDsNCiAmbHQ7SXRhbG8uQnVzaUBodWF3ZWkuY29tJmd0OywgJnF1b3Q7 Y2FybG8ucGVyb2NjaGlvQGVyaWNzc29uLmNvbSZxdW90OyAmbHQ7Y2FybG8ucGVyb2NjaGlvQGVy aWNzc29uLmNvbSZndDssIERpZXRlciBCZWxsZXIgJmx0O2RpZXRlci5iZWxsZXJAbm9raWEuY29t Jmd0OywgU2VyZ2lvIEJlbG90dGkgJmx0O3Nlcmdpby5iZWxvdHRpQG5va2lhLmNvbSZndDssICZx dW90O3RlYXNAaWV0Zi5vcmcmcXVvdDsgJmx0O3RlYXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDogPC9iPltUZWFzXSBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRl LXRvcG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+QXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5BcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFz dCBDYWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QXJl IHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdHMgaWRlbnRpZmllZCBh Ym92ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5QbGVh c2Ugc3RhdGUgZWl0aGVyOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZxdW90O05vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRv IHRoaXMgZHJhZnQmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5vcjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZxdW90O1llcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFm dCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPklm IHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYg SVBSIHJ1bGVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KHNlZSBSRkNzIDM2NjksIDUzNzggYW5kIDgx NzkgZm9yIG1vcmUgZGV0YWlscyk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+SWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mcXVvdDtZZXMsIHRo ZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxl cyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPm9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+JnF1b3Q7 Tm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCZxdW90OzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBw cm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+YXBwcm9wcmlhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+SWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0 b3IgcGxlYXNlIGFuc3dlciB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5hYm92ZSBieSByZXNwb25k aW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+YXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVu dCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+c3RhZ2Ug dW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBs aXN0ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5jb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVT IFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdTPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+VE8gTElORVMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+SWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3Mg YnV0IGFyZSBub3QgbGlzdGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+YXMgYW4gYXV0aG9yIG9yIGNv bnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXI8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj50aGUgSUVURiBJUFIgcnVsZXMgd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8g bm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5hd2FyZSBvZiBJ UFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb208 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5wYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3Ig ZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj51bmRpc2Nsb3Nl ZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBh Ym92ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9 Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVj dHVhbFByb3BlcnR5Ij5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMv d2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eTwvYT4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhbmsgeW91LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRFQVMg V0cgQ2hhaXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ UFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBvZiB0aGlzIG1lc3Nh Z2UgaW4geW91cjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnJlc3BvbnNlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+VGVhcyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YSBocmVm PSJtYWlsdG86VGVhc0BpZXRmLm9yZyI+VGVhc0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhczwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7C5B540DE2A84AE9BAD6987BB6ECF7F4cienacom_-- From nobody Thu Aug 31 08:31:55 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FEF126B71; Thu, 31 Aug 2017 08:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVokxGbWeoM4; Thu, 31 Aug 2017 08:31:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B6098132E1E; Thu, 31 Aug 2017 08:31:41 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7VFVdwC070754 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 31 Aug 2017 10:31:40 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Adrian Farrel , The IESG Cc: "draft-ietf-teas-pce-central-control@ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" , Vishnu Pavan Beeram References: <150415143178.16864.7645859577213327042.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Thu, 31 Aug 2017 10:31:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FDC640FA304AF2578445A8FC" Content-Language: en-US Archived-At: Subject: Re: [Teas] Adam Roach's No Objection on draft-ietf-teas-pce-central-control-04: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 15:31:47 -0000 This is a multi-part message in MIME format. --------------FDC640FA304AF2578445A8FC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/31/17 03:32, Adrian Farrel wrote: > Hello Adam, > >> I like how clearly this document spells out the nature of the work >> that is to be performed to adapt PCEP to enable the described >> network architecture. It's not entirely clear to me what value it >> has as an archival document (rather than simply being used >> internally by the working group to guide future development). >> Has the working group explicitly discussed why they might want >> this published as an RFC? > I'll let the WG chairs comment on what the opinion of the WG is, but I would note that the publication request came from the WG so (I assume) the WG requested publication. Yes, but that is frequently done in a somewhat pro-forma fashion, so much so that the IESG has issued specific guidance on the topic (). That said, you, Spencer, and Deborah have all made good points in favor of publication. I'm not trying to stand in the way; I'm just making sure the question has been considered. >> This document uses the term "control plane" rather extensively >> without concretely defining it. While I can infer some things about >> what is meant, it appears to be intended as a very concrete and >> specific term. In particular, it seems to diverge from how that term >> is used in (e.g.) voice networks, to the point of meaning nearly the >> opposite (that is: I've gathered that it refers to the exchange of >> routing information on the same paths as are used to exchange >> traffic). If there is a formal definition of the term in some referenced >> document, I would think a citation to it would be useful. If not, >> please take a stab at a formal definition of this term early in this >> document. [snip] > Around a hundred years ago I wrote: "The Control Plane is where the signaling and control protocols operate to dynamically interact between computers." It's worth noting that some people consider the Management Plane as being part of the Control Plane, and some people think that the Routing Plane is distinct form the Control Plane. Thanks for the explanation (and related exposition and musings). This, in particular, clarified for me that the problem I encountered isn't the terminology (which does seem roughly congruent with how I'd seen the term used before); but, rather the diagrams in the document. Consider, for example, Figure 1: -------------------------------------------- | Orchestrator / Service Manager / OSS / NMS | -------------------------------------------- ^ | v ------------ | | ----- | PCE-based |<---| TED | | Controller | ----- | | ------------ ^ PCEP| v ---- ---- ---- ---- | NE |<------->| NE |<--->| NE |<--->| NE | ---- Control ---- ---- ---- Plane Figure 1: Architecture for Central Controller with Control Plane In my understanding (based on your definition and previous experience), everything here participates in the control plane (although I take your point that there may be a diversity of opinions about whether things like the OSS function is included). However, in this diagram (and Figure 3), there is a specific line labeled "Control Plane," from which I (apparently incorrectly) inferred that the remaining labeled lines were something else. Perhaps selecting a different label for the inter-NE communications would be clearer (or possibly adding some textual clarification that would help readers who would otherwise fall into the same confusion as I did). /a --------------FDC640FA304AF2578445A8FC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 8/31/17 03:32, Adrian Farrel wrote:
Hello Adam,


I like how clearly this document spells out the nature of the work 
that is to be performed to adapt PCEP to enable the described 
network architecture. It's not entirely clear to me what value it
has as an archival document (rather than simply being used 
internally by the working group to guide future development).
Has the working group explicitly discussed why they might want
this published as an RFC?

I'll let the WG chairs comment on what the opinion of the WG is, but I would note that the publication request came from the WG so (I assume) the WG requested publication.

Yes, but that is frequently done in a somewhat pro-forma fashion, so much so that the IESG has issued specific guidance on the topic (<https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html>). That said, you, Spencer, and Deborah have all made good points in favor of publication. I'm not trying to stand in the way; I'm just making sure the question has been considered.


      

        
This document uses the term "control plane" rather extensively
without concretely defining it. While I can infer some things about
what is meant, it appears to be intended as a very concrete and
specific term. In particular, it seems to diverge from how that term
is used in (e.g.) voice networks, to the point of meaning nearly the
opposite (that is: I've gathered that it refers to the exchange of 
routing information on the same paths as are used to exchange
traffic). If there is a formal definition of the term in some referenced
document, I would think a citation to it would be useful. If not, 
please take a stab at a formal definition of this term early in this
document.


      

    

    [snip]

    

      
Around a hundred years ago I wrote: "The Control Plane is where the signaling and control protocols operate to dynamically interact between computers." It's worth noting that some people consider the Management Plane as being part of the Control Plane, and some people think that the Routing Plane is distinct form the Control Plane.

    

    

    Thanks for the explanation (and related exposition and musings).
    This, in particular, clarified for me that the problem I encountered
    isn't the terminology (which does seem roughly congruent with how
    I'd seen the term used before); but, rather the diagrams in the
    document. Consider, for example, Figure 1:

    

    

    
                 --------------------------------------------
                | Orchestrator / Service Manager / OSS / NMS |
                 --------------------------------------------
                         ^
                         |
                         v
                     ------------
                    |            |     -----
                    | PCE-based  |<---| TED |
                    | Controller |     -----
                    |            |
                     ------------
                       ^
                   PCEP|
                       v
                      ----           ----       ----       ----
                     | NE |<------->| NE |<--->| NE |<--->| NE |
                      ----  Control  ----       ----       ----
                            Plane


     Figure 1: Architecture for Central Controller with Control Plane

    

    In my understanding (based on your definition and previous
    experience), everything here participates in the control plane
    (although I take your point that there may be a diversity of
    opinions about whether things like the OSS function is included).
    However, in this diagram (and Figure 3), there is a specific line
    labeled "Control Plane," from which I (apparently incorrectly)
    inferred that the remaining labeled lines were something else.
    Perhaps selecting a different label for the inter-NE communications
    would be clearer (or possibly adding some textual clarification that
    would help readers who would otherwise fall into the same confusion
    as I did).

    

    /a
  


--------------FDC640FA304AF2578445A8FC--


From nobody Thu Aug 31 08:57:02 2017
Return-Path: 
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4219C13236D; Thu, 31 Aug 2017 08:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f4P4OmTl6Es; Thu, 31 Aug 2017 08:56:57 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0114.outbound.protection.outlook.com [104.47.40.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E84413219E; Thu, 31 Aug 2017 08:56:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sIJP20SYYgiENaaL3b/83e/FcZtEb/3lajY4v/OS3cU=; b=bmLsrPKQ0u0dXbHr73k94zMpb6MilQOA6UTlqxeZzkQccDovLxOWh9obnz/L/LJFLGK9IfN0Kb30MxZNkqPT8HScQZclVOmyFg/DQrTbaaeRJMZWgoECqDQxjpOQ0QP9Qfuy8nR2lnYe9wDHzb1ZVaGk3k+Tf6+cmAICL0Wd5wQ=
Received: from CO2PR05MB971.namprd05.prod.outlook.com (10.141.226.17) by CO2PR05MB970.namprd05.prod.outlook.com (10.141.226.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Thu, 31 Aug 2017 15:56:55 +0000
Received: from CO2PR05MB971.namprd05.prod.outlook.com ([10.141.226.17]) by CO2PR05MB971.namprd05.prod.outlook.com ([10.141.226.17]) with mapi id 15.20.0013.012; Thu, 31 Aug 2017 15:56:54 +0000
From: Adrian Farrel 
To: Adam Roach , The IESG 
CC: "draft-ietf-teas-pce-central-control@ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" , Vishnu Pavan Beeram 
Thread-Topic: Adam Roach's No Objection on draft-ietf-teas-pce-central-control-04: (with COMMENT)
Thread-Index: AQHTIgxO4cN06Z1htkmtSNPWZEE+3aKeFBgwgACEQwCAAAaQsA==
Date: Thu, 31 Aug 2017 15:56:54 +0000
Message-ID: 
References: <150415143178.16864.7645859577213327042.idtracker@ietfa.amsl.com>  
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=afarrel@juniper.net; 
x-originating-ip: [193.110.55.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR05MB970; 6:XdT273X5f/zXLFxc+Db1ghQbECBy7eAg+VzEvs7IIpQxyymI7yD1uaT8AWOhHh/Tnl4VE9aFqLmmBSLJGvJU0FAejF/V4VvEwg+5nYk8RrMClNN5nA1n/h/V+y8VATPCgSQHasmd2Fz7m9M+Yykcx2p+/T3RAeq3kAHy0Wc7lOkEd+OFO40UWxyXSeVmwo906cNvYdco00HRjTyb5fiLKAX5cOCWBhmuLI3ALPdVTLzb38pgrBf9tcdESoa36M2Fq7TFMAnGlyZ1twCWmnFjBshjo3NdDxe/1xSSYhN2gJBotdtT0hLWQxpEA2h5Ve7XSEiF0H5a1DEqf1pJo7T3NQ==; 5:0tSDNgHqc1OJBVZA57zh60EBLgI+oPUXoBds3QxgeXo2ZN4GKEc0YqQWYkLG6FbjvXWafQcmCh226kp4XHH/sMOd8a6NiWyvOcaRalhARYLELTZFc6KoPqDfAym2tjQfvvwJL9tKVAd9BCJAEw0sdg==; 24:J+AXGbMd2CAUl+6x38AYTclgDIsLssKOvxWLyIrzGD5jqjm4UN2zsYRWmQdu3+swmA1X9Qps7sYUSkdmVKuUOyf/ch9QKB8mQj5yPgwPYFY=; 7:WghXIwpvlewgtXuU9M2/yYCI5LAO629Brw5qDGjeGxXDpWSFfEFqey/e2TCJn8R1ecdmdBa6oXGebkQ0Xz74HCIfjy66JMYq+XbQQBwOek4M9PUAenzftKtM9yfqLA+2WbQ/54DdnVSzjJ6mLYaVy4gIo915E4chkWcVwMCPQ+8YYfe1uiue/8PNF4e7ZtYW30rNfvVrjfh1mmDGWNDTGzRvsyaCNZZ5OfdFi4SXfbE=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(199003)(24454002)(189002)(51914003)(33656002)(68736007)(2950100002)(74316002)(53546010)(790700001)(229853002)(5660300001)(189998001)(8676002)(81166006)(3280700002)(81156014)(25786009)(97736004)(7736002)(86362001)(2906002)(53936002)(54356999)(50986999)(76176999)(8936002)(3660700001)(6506006)(6436002)(7696004)(6246003)(230783001)(4326008)(77096006)(101416001)(55016002)(54896002)(9686003)(6306002)(99286003)(236005)(54906002)(107886003)(2900100001)(3846002)(6116002)(102836003)(106356001)(478600001)(606006)(105586002)(14454004)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB970; H:CO2PR05MB971.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
x-ms-office365-filtering-correlation-id: ca34f5d3-b701-49af-0018-08d4f088e703
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB970; 
x-ms-traffictypediagnostic: CO2PR05MB970:
x-exchange-antispam-report-test: UriScan:(35073007944872)(138986009662008)(21748063052155); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB970; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB970; 
x-forefront-prvs: 04163EF38A
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CO2PR05MB971233D3FB350498252F9C4BB9D0CO2PR05MB971namprd_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2017 15:56:54.6940 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB970
Archived-At: 
Subject: Re: [Teas] Adam Roach's No Objection on draft-ietf-teas-pce-central-control-04: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Aug 2017 15:57:00 -0000

--_000_CO2PR05MB971233D3FB350498252F9C4BB9D0CO2PR05MB971namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWRhbSwNCg0KWW91ciBmaW5hbCBwb2ludCBpcyBhIGdvb2QgY2F0Y2ggYW5kIGlzIG15IGJhZC4N
Cg0KSW4gcGluY2hpbmcgdGhlIGZpZ3VyZSBmcm9tIFJGQyA0NjU1IEkgc2hvdWxkIGhhdmUgbGFi
ZWxlZCB0aGUgaG9yaXpvbnRhbCBsaW5lcyBzb21ldGhpbmcgbGlrZSDigJxzaWduYWxpbmcgYW5k
IHJvdXRpbmfigJ0uDQoNCkRlYm9yYWgsIGxvb2tzIGxpa2UgdGhpcyBpcyBhbm90aGVyIHVwZGF0
ZSB3ZeKAmWxsIG5lZWQgYWZ0ZXIgSUVTRyByZXZpZXcuDQoNCkENCg0KRnJvbTogQWRhbSBSb2Fj
aCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dDQpTZW50OiAzMSBBdWd1c3QgMjAxNyAxNjozMg0K
VG86IEFkcmlhbiBGYXJyZWwgPGFmYXJyZWxAanVuaXBlci5uZXQ+OyBUaGUgSUVTRyA8aWVzZ0Bp
ZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29udHJvbEBpZXRmLm9y
ZzsgdGVhcy1jaGFpcnNAaWV0Zi5vcmc7IHRlYXNAaWV0Zi5vcmc7IFZpc2hudSBQYXZhbiBCZWVy
YW0gPHZiZWVyYW1AanVuaXBlci5uZXQ+DQpTdWJqZWN0OiBSZTogQWRhbSBSb2FjaCdzIE5vIE9i
amVjdGlvbiBvbiBkcmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29udHJvbC0wNDogKHdpdGgg
Q09NTUVOVCkNCg0KT24gOC8zMS8xNyAwMzozMiwgQWRyaWFuIEZhcnJlbCB3cm90ZToNCg0KSGVs
bG8gQWRhbSwNCg0KDQoNCkkgbGlrZSBob3cgY2xlYXJseSB0aGlzIGRvY3VtZW50IHNwZWxscyBv
dXQgdGhlIG5hdHVyZSBvZiB0aGUgd29yaw0KDQp0aGF0IGlzIHRvIGJlIHBlcmZvcm1lZCB0byBh
ZGFwdCBQQ0VQIHRvIGVuYWJsZSB0aGUgZGVzY3JpYmVkDQoNCm5ldHdvcmsgYXJjaGl0ZWN0dXJl
LiBJdCdzIG5vdCBlbnRpcmVseSBjbGVhciB0byBtZSB3aGF0IHZhbHVlIGl0DQoNCmhhcyBhcyBh
biBhcmNoaXZhbCBkb2N1bWVudCAocmF0aGVyIHRoYW4gc2ltcGx5IGJlaW5nIHVzZWQNCg0KaW50
ZXJuYWxseSBieSB0aGUgd29ya2luZyBncm91cCB0byBndWlkZSBmdXR1cmUgZGV2ZWxvcG1lbnQp
Lg0KDQpIYXMgdGhlIHdvcmtpbmcgZ3JvdXAgZXhwbGljaXRseSBkaXNjdXNzZWQgd2h5IHRoZXkg
bWlnaHQgd2FudA0KDQp0aGlzIHB1Ymxpc2hlZCBhcyBhbiBSRkM/DQoNCg0KDQpJJ2xsIGxldCB0
aGUgV0cgY2hhaXJzIGNvbW1lbnQgb24gd2hhdCB0aGUgb3BpbmlvbiBvZiB0aGUgV0cgaXMsIGJ1
dCBJIHdvdWxkIG5vdGUgdGhhdCB0aGUgcHVibGljYXRpb24gcmVxdWVzdCBjYW1lIGZyb20gdGhl
IFdHIHNvIChJIGFzc3VtZSkgdGhlIFdHIHJlcXVlc3RlZCBwdWJsaWNhdGlvbi4NCg0KWWVzLCBi
dXQgdGhhdCBpcyBmcmVxdWVudGx5IGRvbmUgaW4gYSBzb21ld2hhdCBwcm8tZm9ybWEgZmFzaGlv
biwgc28gbXVjaCBzbyB0aGF0IHRoZSBJRVNHIGhhcyBpc3N1ZWQgc3BlY2lmaWMgZ3VpZGFuY2Ug
b24gdGhlIHRvcGljICg8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvc3VwcG9y
dC1kb2N1bWVudHMtaW4taWV0Zi13Z3MuaHRtbD48aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z
dGF0ZW1lbnQvc3VwcG9ydC1kb2N1bWVudHMtaW4taWV0Zi13Z3MuaHRtbD4pLiBUaGF0IHNhaWQs
IHlvdSwgU3BlbmNlciwgYW5kIERlYm9yYWggaGF2ZSBhbGwgbWFkZSBnb29kIHBvaW50cyBpbiBm
YXZvciBvZiBwdWJsaWNhdGlvbi4gSSdtIG5vdCB0cnlpbmcgdG8gc3RhbmQgaW4gdGhlIHdheTsg
SSdtIGp1c3QgbWFraW5nIHN1cmUgdGhlIHF1ZXN0aW9uIGhhcyBiZWVuIGNvbnNpZGVyZWQuDQoN
Cg0KDQoNCg0KVGhpcyBkb2N1bWVudCB1c2VzIHRoZSB0ZXJtICJjb250cm9sIHBsYW5lIiByYXRo
ZXIgZXh0ZW5zaXZlbHkNCg0Kd2l0aG91dCBjb25jcmV0ZWx5IGRlZmluaW5nIGl0LiBXaGlsZSBJ
IGNhbiBpbmZlciBzb21lIHRoaW5ncyBhYm91dA0KDQp3aGF0IGlzIG1lYW50LCBpdCBhcHBlYXJz
IHRvIGJlIGludGVuZGVkIGFzIGEgdmVyeSBjb25jcmV0ZSBhbmQNCg0Kc3BlY2lmaWMgdGVybS4g
SW4gcGFydGljdWxhciwgaXQgc2VlbXMgdG8gZGl2ZXJnZSBmcm9tIGhvdyB0aGF0IHRlcm0NCg0K
aXMgdXNlZCBpbiAoZS5nLikgdm9pY2UgbmV0d29ya3MsIHRvIHRoZSBwb2ludCBvZiBtZWFuaW5n
IG5lYXJseSB0aGUNCg0Kb3Bwb3NpdGUgKHRoYXQgaXM6IEkndmUgZ2F0aGVyZWQgdGhhdCBpdCBy
ZWZlcnMgdG8gdGhlIGV4Y2hhbmdlIG9mDQoNCnJvdXRpbmcgaW5mb3JtYXRpb24gb24gdGhlIHNh
bWUgcGF0aHMgYXMgYXJlIHVzZWQgdG8gZXhjaGFuZ2UNCg0KdHJhZmZpYykuIElmIHRoZXJlIGlz
IGEgZm9ybWFsIGRlZmluaXRpb24gb2YgdGhlIHRlcm0gaW4gc29tZSByZWZlcmVuY2VkDQoNCmRv
Y3VtZW50LCBJIHdvdWxkIHRoaW5rIGEgY2l0YXRpb24gdG8gaXQgd291bGQgYmUgdXNlZnVsLiBJ
ZiBub3QsDQoNCnBsZWFzZSB0YWtlIGEgc3RhYiBhdCBhIGZvcm1hbCBkZWZpbml0aW9uIG9mIHRo
aXMgdGVybSBlYXJseSBpbiB0aGlzDQoNCmRvY3VtZW50Lg0KW3NuaXBdDQoNCg0KDQoNCkFyb3Vu
ZCBhIGh1bmRyZWQgeWVhcnMgYWdvIEkgd3JvdGU6ICJUaGUgQ29udHJvbCBQbGFuZSBpcyB3aGVy
ZSB0aGUgc2lnbmFsaW5nIGFuZCBjb250cm9sIHByb3RvY29scyBvcGVyYXRlIHRvIGR5bmFtaWNh
bGx5IGludGVyYWN0IGJldHdlZW4gY29tcHV0ZXJzLiIgSXQncyB3b3J0aCBub3RpbmcgdGhhdCBz
b21lIHBlb3BsZSBjb25zaWRlciB0aGUgTWFuYWdlbWVudCBQbGFuZSBhcyBiZWluZyBwYXJ0IG9m
IHRoZSBDb250cm9sIFBsYW5lLCBhbmQgc29tZSBwZW9wbGUgdGhpbmsgdGhhdCB0aGUgUm91dGlu
ZyBQbGFuZSBpcyBkaXN0aW5jdCBmb3JtIHRoZSBDb250cm9sIFBsYW5lLg0KDQpUaGFua3MgZm9y
IHRoZSBleHBsYW5hdGlvbiAoYW5kIHJlbGF0ZWQgZXhwb3NpdGlvbiBhbmQgbXVzaW5ncykuIFRo
aXMsIGluIHBhcnRpY3VsYXIsIGNsYXJpZmllZCBmb3IgbWUgdGhhdCB0aGUgcHJvYmxlbSBJIGVu
Y291bnRlcmVkIGlzbid0IHRoZSB0ZXJtaW5vbG9neSAod2hpY2ggZG9lcyBzZWVtIHJvdWdobHkg
Y29uZ3J1ZW50IHdpdGggaG93IEknZCBzZWVuIHRoZSB0ZXJtIHVzZWQgYmVmb3JlKTsgYnV0LCBy
YXRoZXIgdGhlIGRpYWdyYW1zIGluIHRoZSBkb2N1bWVudC4gQ29uc2lkZXIsIGZvciBleGFtcGxl
LCBGaWd1cmUgMToNCg0KDQogICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgICAgICAgICAgICAgICB8IE9yY2hlc3RyYXRvciAv
IFNlcnZpY2UgTWFuYWdlciAvIE9TUyAvIE5NUyB8DQoNCiAgICAgICAgICAgICAgICAgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICAgICAgICAgICAg
ICAgICAgICAgIF4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAg
ICAgICAgICAgICAgIHYNCg0KICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tDQoNCiAg
ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgIC0tLS0tDQoNCiAgICAgICAgICAg
ICAgICAgICAgfCBQQ0UtYmFzZWQgIHw8LS0tfCBURUQgfA0KDQogICAgICAgICAgICAgICAgICAg
IHwgQ29udHJvbGxlciB8ICAgICAtLS0tLQ0KDQogICAgICAgICAgICAgICAgICAgIHwgICAgICAg
ICAgICB8DQoNCiAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLQ0KDQogICAgICAgICAg
ICAgICAgICAgICAgIF4NCg0KICAgICAgICAgICAgICAgICAgIFBDRVB8DQoNCiAgICAgICAgICAg
ICAgICAgICAgICAgdg0KDQogICAgICAgICAgICAgICAgICAgICAgLS0tLSAgICAgICAgICAgLS0t
LSAgICAgICAtLS0tICAgICAgIC0tLS0NCg0KICAgICAgICAgICAgICAgICAgICAgfCBORSB8PC0t
LS0tLS0+fCBORSB8PC0tLT58IE5FIHw8LS0tPnwgTkUgfA0KDQogICAgICAgICAgICAgICAgICAg
ICAgLS0tLSAgQ29udHJvbCAgLS0tLSAgICAgICAtLS0tICAgICAgIC0tLS0NCg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFBsYW5lDQoNCg0KDQoNCg0KICAgICBGaWd1cmUgMTogQXJjaGl0
ZWN0dXJlIGZvciBDZW50cmFsIENvbnRyb2xsZXIgd2l0aCBDb250cm9sIFBsYW5lDQoNCkluIG15
IHVuZGVyc3RhbmRpbmcgKGJhc2VkIG9uIHlvdXIgZGVmaW5pdGlvbiBhbmQgcHJldmlvdXMgZXhw
ZXJpZW5jZSksIGV2ZXJ5dGhpbmcgaGVyZSBwYXJ0aWNpcGF0ZXMgaW4gdGhlIGNvbnRyb2wgcGxh
bmUgKGFsdGhvdWdoIEkgdGFrZSB5b3VyIHBvaW50IHRoYXQgdGhlcmUgbWF5IGJlIGEgZGl2ZXJz
aXR5IG9mIG9waW5pb25zIGFib3V0IHdoZXRoZXIgdGhpbmdzIGxpa2UgdGhlIE9TUyBmdW5jdGlv
biBpcyBpbmNsdWRlZCkuIEhvd2V2ZXIsIGluIHRoaXMgZGlhZ3JhbSAoYW5kIEZpZ3VyZSAzKSwg
dGhlcmUgaXMgYSBzcGVjaWZpYyBsaW5lIGxhYmVsZWQgIkNvbnRyb2wgUGxhbmUsIiBmcm9tIHdo
aWNoIEkgKGFwcGFyZW50bHkgaW5jb3JyZWN0bHkpIGluZmVycmVkIHRoYXQgdGhlIHJlbWFpbmlu
ZyBsYWJlbGVkIGxpbmVzIHdlcmUgc29tZXRoaW5nIGVsc2UuIFBlcmhhcHMgc2VsZWN0aW5nIGEg
ZGlmZmVyZW50IGxhYmVsIGZvciB0aGUgaW50ZXItTkUgY29tbXVuaWNhdGlvbnMgd291bGQgYmUg
Y2xlYXJlciAob3IgcG9zc2libHkgYWRkaW5nIHNvbWUgdGV4dHVhbCBjbGFyaWZpY2F0aW9uIHRo
YXQgd291bGQgaGVscCByZWFkZXJzIHdobyB3b3VsZCBvdGhlcndpc2UgZmFsbCBpbnRvIHRoZSBz
YW1lIGNvbmZ1c2lvbiBhcyBJIGRpZCkuDQoNCi9hDQo=

--_000_CO2PR05MB971233D3FB350498252F9C4BB9D0CO2PR05MB971namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN
Cgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt
YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo
YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv
bnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw
dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWRhbSw8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPllvdXIgZmluYWwgcG9pbnQgaXMg
YSBnb29kIGNhdGNoIGFuZCBpcyBteSBiYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj5JbiBwaW5jaGluZyB0aGUgZmlndXJlIGZyb20gUkZDIDQ2NTUgSSBzaG91
bGQgaGF2ZSBsYWJlbGVkIHRoZSBob3Jpem9udGFsIGxpbmVzIHNvbWV0aGluZyBsaWtlIOKAnHNp
Z25hbGluZyBhbmQgcm91dGluZ+KAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPkRlYm9yYWgsIGxvb2tzIGxpa2UgdGhpcyBpcyBhbm90aGVyIHVwZGF0ZSB3ZeKA
mWxsIG5lZWQgYWZ0ZXIgSUVTRyByZXZpZXcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj5BPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF
MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gQWRhbSBSb2FjaCBbbWFpbHRvOmFk
YW1Abm9zdHJ1bS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMzEgQXVndXN0IDIwMTcgMTY6MzI8
YnI+DQo8Yj5Ubzo8L2I+IEFkcmlhbiBGYXJyZWwgJmx0O2FmYXJyZWxAanVuaXBlci5uZXQmZ3Q7
OyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWll
dGYtdGVhcy1wY2UtY2VudHJhbC1jb250cm9sQGlldGYub3JnOyB0ZWFzLWNoYWlyc0BpZXRmLm9y
ZzsgdGVhc0BpZXRmLm9yZzsgVmlzaG51IFBhdmFuIEJlZXJhbSAmbHQ7dmJlZXJhbUBqdW5pcGVy
Lm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEFkYW0gUm9hY2gncyBObyBPYmplY3Rp
b24gb24gZHJhZnQtaWV0Zi10ZWFzLXBjZS1jZW50cmFsLWNvbnRyb2wtMDQ6ICh3aXRoIENPTU1F
TlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIDgvMzEvMTcgMDM6MzIsIEFkcmlhbiBGYXJyZWwgd3JvdGU6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT5IZWxsbyBBZGFtLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SSBsaWtlIGhvdyBjbGVhcmx5IHRoaXMgZG9jdW1lbnQg
c3BlbGxzIG91dCB0aGUgbmF0dXJlIG9mIHRoZSB3b3JrIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PnRoYXQgaXMgdG8gYmUgcGVyZm9ybWVkIHRvIGFkYXB0IFBDRVAgdG8gZW5hYmxlIHRoZSBkZXNj
cmliZWQgPG86cD48L286cD48L3ByZT4NCjxwcmU+bmV0d29yayBhcmNoaXRlY3R1cmUuIEl0J3Mg
bm90IGVudGlyZWx5IGNsZWFyIHRvIG1lIHdoYXQgdmFsdWUgaXQ8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5oYXMgYXMgYW4gYXJjaGl2YWwgZG9jdW1lbnQgKHJhdGhlciB0aGFuIHNpbXBseSBiZWlu
ZyB1c2VkIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmludGVybmFsbHkgYnkgdGhlIHdvcmtpbmcg
Z3JvdXAgdG8gZ3VpZGUgZnV0dXJlIGRldmVsb3BtZW50KS48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5IYXMgdGhlIHdvcmtpbmcgZ3JvdXAgZXhwbGljaXRseSBkaXNjdXNzZWQgd2h5IHRoZXkgbWln
aHQgd2FudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoaXMgcHVibGlzaGVkIGFzIGFuIFJGQz88
bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5JJ2xsIGxldCB0aGUgV0cgY2hhaXJzIGNvbW1lbnQgb24gd2hhdCB0aGUgb3Bp
bmlvbiBvZiB0aGUgV0cgaXMsIGJ1dCBJIHdvdWxkIG5vdGUgdGhhdCB0aGUgcHVibGljYXRpb24g
cmVxdWVzdCBjYW1lIGZyb20gdGhlIFdHIHNvIChJIGFzc3VtZSkgdGhlIFdHIHJlcXVlc3RlZCBw
dWJsaWNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGJyPg0KWWVzLCBidXQgdGhhdCBpcyBmcmVxdWVudGx5IGRvbmUgaW4gYSBzb21l
d2hhdCBwcm8tZm9ybWEgZmFzaGlvbiwgc28gbXVjaCBzbyB0aGF0IHRoZSBJRVNHIGhhcyBpc3N1
ZWQgc3BlY2lmaWMgZ3VpZGFuY2Ugb24gdGhlIHRvcGljICg8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9zdXBwb3J0LWRvY3VtZW50cy1pbi1pZXRmLXdncy5odG1s
Ij4mbHQ7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvc3VwcG9ydC1kb2N1bWVu
dHMtaW4taWV0Zi13Z3MuaHRtbCZndDs8L2E+KS4NCiBUaGF0IHNhaWQsIHlvdSwgU3BlbmNlciwg
YW5kIERlYm9yYWggaGF2ZSBhbGwgbWFkZSBnb29kIHBvaW50cyBpbiBmYXZvciBvZiBwdWJsaWNh
dGlvbi4gSSdtIG5vdCB0cnlpbmcgdG8gc3RhbmQgaW4gdGhlIHdheTsgSSdtIGp1c3QgbWFraW5n
IHN1cmUgdGhlIHF1ZXN0aW9uIGhhcyBiZWVuIGNvbnNpZGVyZWQuPGJyPg0KPGJyPg0KPGJyPg0K
PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5U
aGlzIGRvY3VtZW50IHVzZXMgdGhlIHRlcm0gJnF1b3Q7Y29udHJvbCBwbGFuZSZxdW90OyByYXRo
ZXIgZXh0ZW5zaXZlbHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53aXRob3V0IGNvbmNyZXRlbHkg
ZGVmaW5pbmcgaXQuIFdoaWxlIEkgY2FuIGluZmVyIHNvbWUgdGhpbmdzIGFib3V0PG86cD48L286
cD48L3ByZT4NCjxwcmU+d2hhdCBpcyBtZWFudCwgaXQgYXBwZWFycyB0byBiZSBpbnRlbmRlZCBh
cyBhIHZlcnkgY29uY3JldGUgYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+c3BlY2lmaWMgdGVy
bS4gSW4gcGFydGljdWxhciwgaXQgc2VlbXMgdG8gZGl2ZXJnZSBmcm9tIGhvdyB0aGF0IHRlcm08
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pcyB1c2VkIGluIChlLmcuKSB2b2ljZSBuZXR3b3Jrcywg
dG8gdGhlIHBvaW50IG9mIG1lYW5pbmcgbmVhcmx5IHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
Pm9wcG9zaXRlICh0aGF0IGlzOiBJJ3ZlIGdhdGhlcmVkIHRoYXQgaXQgcmVmZXJzIHRvIHRoZSBl
eGNoYW5nZSBvZiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yb3V0aW5nIGluZm9ybWF0aW9uIG9u
IHRoZSBzYW1lIHBhdGhzIGFzIGFyZSB1c2VkIHRvIGV4Y2hhbmdlPG86cD48L286cD48L3ByZT4N
CjxwcmU+dHJhZmZpYykuIElmIHRoZXJlIGlzIGEgZm9ybWFsIGRlZmluaXRpb24gb2YgdGhlIHRl
cm0gaW4gc29tZSByZWZlcmVuY2VkPG86cD48L286cD48L3ByZT4NCjxwcmU+ZG9jdW1lbnQsIEkg
d291bGQgdGhpbmsgYSBjaXRhdGlvbiB0byBpdCB3b3VsZCBiZSB1c2VmdWwuIElmIG5vdCwgPG86
cD48L286cD48L3ByZT4NCjxwcmU+cGxlYXNlIHRha2UgYSBzdGFiIGF0IGEgZm9ybWFsIGRlZmlu
aXRpb24gb2YgdGhpcyB0ZXJtIGVhcmx5IGluIHRoaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5k
b2N1bWVudC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+W3NuaXBdPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QXJvdW5kIGEgaHVuZHJlZCB5ZWFy
cyBhZ28gSSB3cm90ZTogJnF1b3Q7VGhlIENvbnRyb2wgUGxhbmUgaXMgd2hlcmUgdGhlIHNpZ25h
bGluZyBhbmQgY29udHJvbCBwcm90b2NvbHMgb3BlcmF0ZSB0byBkeW5hbWljYWxseSBpbnRlcmFj
dCBiZXR3ZWVuIGNvbXB1dGVycy4mcXVvdDsgSXQncyB3b3J0aCBub3RpbmcgdGhhdCBzb21lIHBl
b3BsZSBjb25zaWRlciB0aGUgTWFuYWdlbWVudCBQbGFuZSBhcyBiZWluZyBwYXJ0IG9mIHRoZSBD
b250cm9sIFBsYW5lLCBhbmQgc29tZSBwZW9wbGUgdGhpbmsgdGhhdCB0aGUgUm91dGluZyBQbGFu
ZSBpcyBkaXN0aW5jdCBmb3JtIHRoZSBDb250cm9sIFBsYW5lLjxvOnA+PC9vOnA+PC9wcmU+DQo8
L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox
Mi4wcHQiPjxicj4NClRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9uIChhbmQgcmVsYXRlZCBleHBv
c2l0aW9uIGFuZCBtdXNpbmdzKS4gVGhpcywgaW4gcGFydGljdWxhciwgY2xhcmlmaWVkIGZvciBt
ZSB0aGF0IHRoZSBwcm9ibGVtIEkgZW5jb3VudGVyZWQgaXNuJ3QgdGhlIHRlcm1pbm9sb2d5ICh3
aGljaCBkb2VzIHNlZW0gcm91Z2hseSBjb25ncnVlbnQgd2l0aCBob3cgSSdkIHNlZW4gdGhlIHRl
cm0gdXNlZCBiZWZvcmUpOyBidXQsIHJhdGhlciB0aGUgZGlhZ3JhbXMNCiBpbiB0aGUgZG9jdW1l
bnQuIENvbnNpZGVyLCBmb3IgZXhhbXBsZSwgRmlndXJlIDE6PGJyPg0KPGJyPg0KPG86cD48L286
cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE9yY2hlc3RyYXRvciAv
IFNlcnZpY2UgTWFuYWdlciAvIE9TUyAvIE5NUyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB2PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0t
LS0tLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBQQ0UtYmFzZWQmbmJz
cDsgfCZsdDstLS18IFRFRCB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgQ29udHJvbGxlciB8
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLS0tLS0tLS0tLS08bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBQQ0VQfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2PG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLSZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IC0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBORSB8Jmx0Oy0tLS0t
LS0mZ3Q7fCBORSB8Jmx0Oy0tLSZndDt8IE5FIHwmbHQ7LS0tJmd0O3wgTkUgfDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tJm5ic3A7IENvbnRyb2wmbmJzcDsgLS0tLSZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGxhbmU8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDE6IEFyY2hpdGVj
dHVyZSBmb3IgQ2VudHJhbCBDb250cm9sbGVyIHdpdGggQ29udHJvbCBQbGFuZTxvOnA+PC9vOnA+
PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJbiBteSB1bmRlcnN0YW5kaW5nIChi
YXNlZCBvbiB5b3VyIGRlZmluaXRpb24gYW5kIHByZXZpb3VzIGV4cGVyaWVuY2UpLCBldmVyeXRo
aW5nIGhlcmUgcGFydGljaXBhdGVzIGluIHRoZSBjb250cm9sIHBsYW5lIChhbHRob3VnaCBJIHRh
a2UgeW91ciBwb2ludCB0aGF0IHRoZXJlIG1heSBiZSBhIGRpdmVyc2l0eSBvZiBvcGluaW9ucyBh
Ym91dCB3aGV0aGVyIHRoaW5ncyBsaWtlIHRoZSBPU1MgZnVuY3Rpb24gaXMgaW5jbHVkZWQpLiBI
b3dldmVyLA0KIGluIHRoaXMgZGlhZ3JhbSAoYW5kIEZpZ3VyZSAzKSwgdGhlcmUgaXMgYSBzcGVj
aWZpYyBsaW5lIGxhYmVsZWQgJnF1b3Q7Q29udHJvbCBQbGFuZSwmcXVvdDsgZnJvbSB3aGljaCBJ
IChhcHBhcmVudGx5IGluY29ycmVjdGx5KSBpbmZlcnJlZCB0aGF0IHRoZSByZW1haW5pbmcgbGFi
ZWxlZCBsaW5lcyB3ZXJlIHNvbWV0aGluZyBlbHNlLiBQZXJoYXBzIHNlbGVjdGluZyBhIGRpZmZl
cmVudCBsYWJlbCBmb3IgdGhlIGludGVyLU5FIGNvbW11bmljYXRpb25zIHdvdWxkDQogYmUgY2xl
YXJlciAob3IgcG9zc2libHkgYWRkaW5nIHNvbWUgdGV4dHVhbCBjbGFyaWZpY2F0aW9uIHRoYXQg
d291bGQgaGVscCByZWFkZXJzIHdobyB3b3VsZCBvdGhlcndpc2UgZmFsbCBpbnRvIHRoZSBzYW1l
IGNvbmZ1c2lvbiBhcyBJIGRpZCkuPGJyPg0KPGJyPg0KL2EgPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_CO2PR05MB971233D3FB350498252F9C4BB9D0CO2PR05MB971namprd_--