From nobody Tue May 5 02:43:25 2020 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7C43A15F8; Tue, 5 May 2020 02:43:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Dhruv Dhody via Datatracker To: Cc: lsr@ietf.org, last-call@ietf.org, draft-ietf-isis-mpls-elc.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158867180371.13174.5911030866330688420@ietfa.amsl.com> Reply-To: Dhruv Dhody Date: Tue, 05 May 2020 02:43:23 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-isis-mpls-elc-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 09:43:24 -0000 Reviewer: Dhruv Dhody Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-isis-mpls-elc-12 Reviewer: Dhruv Dhody Review Date: 2020-05-05 IETF LC End Date: 2020-05-05 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Disclaimer: I reviewed an earlier version (-08) as part of the early directorate review, which could be located at - https://datatracker.ietf.org/doc/review-ietf-isis-mpls-elc-08-rtgdir-early-dhody-2019-09-12/ I have reviewed this and the OSPF I-D together and you will find similar comments for both I-Ds. You could discuss them in one place. Major Issues: None Minor Issues: (1) Introduction Recently, mechanisms have been defined to signal labels via link- state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667]. Is there a better way to introduce IS-IS extension for SR (than saying that it is just an example to signal labels)? (2) Section 3 Query: The text says that the ABR "MUST" preserve the ELC setting where as the ASBR "SHOULD" preserve it. What is the reason for using SHOULD in case of ASBR? Maybe we can spell out in which case ASBR might not preserve the ELC setting. (3) Section 4 The absence of ERLD-MSD advertisements indicates only that the advertising node does not support advertisement of this capability. Do you mean to differentiate between support for the capability itself v/s support for 'advertisement' only. But RFC 8662 says that ERLD value is advertised only when following conditions are met: * MUST be entropy label capable and, as a consequence, MUST apply the data-plane procedures defined in [RFC6790]. * MUST be able to read an ELI/EL, which is located within its ERLD value. * MUST take into account an EL within the first ERLD labels in its load-balancing function. Thus, I am not sure about this sentence. Maybe you mean to say that the absence only indicates that the ERLD-MSD value of the node is unknown (and it might still be capable of handling ELI/EL)? I see similar language in RFC8491 but I think we could be clearer in this I-D for ERLD. (4) Section 4 What would be the behavior if an IS-IS router receives an ERLD of the node but no ELC set for the corresponding prefix? That would be an error as per RFC 8662, we should specify how one handles it within IS-IS. If it is to just ignore the ERLD, we should explicitly say that. (5) Section 4 We need to clearly state that this new MSD Type is carried in Node MSD sub-TLV as described in [RFC8491]. And then I guess we don't really need figure 2? The format is as per RFC 8491! Nits: (1) Abstract - use term LSP instead of tunnel for consistency OLD: An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that tunnel. NEW: An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. END (2) Expand BGP-LS on first use! Thanks! Dhruv From nobody Tue May 5 02:45:02 2020 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2653A1608; Tue, 5 May 2020 02:44:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Dhruv Dhody via Datatracker To: Cc: draft-ietf-ospf-mpls-elc.all@ietf.org, lsr@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158867189453.14412.14632358918213286203@ietfa.amsl.com> Reply-To: Dhruv Dhody Date: Tue, 05 May 2020 02:44:54 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-ospf-mpls-elc-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 09:44:55 -0000 Reviewer: Dhruv Dhody Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ospf-mpls-elc-13 Reviewer: Dhruv Dhody Review Date: 2020-05-05 IETF LC End Date: 2020-05-05 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Disclaimer: I reviewed an earlier version (-09) as part of the early directorate review, which could be located at - https://datatracker.ietf.org/doc/review-ietf-ospf-mpls-elc-09-rtgdir-early-dhody-2019-09-12/ I have reviewed this and the IS-IS I-D together and you will find similar comments for both I-Ds. You could discuss them in one place. Major Issues: None Minor Issues: (1) Introduction Recently, mechanisms have been defined to signal labels via link- state Interior Gateway Protocols (IGP) such as OSPFv2 [RFC8665] and OSPFv3 [RFC8666]. Is there a better way to introduce OSPF extension for SR (than saying that it is just an example to signal labels)? (2) Section 3 Query: The text says that the ABR "MUST" preserve the ELC setting where as the ASBR "SHOULD" preserve it. What is the reason for using SHOULD in case of ASBR? Maybe we can spell out in which case ASBR might not preserve the ELC setting. (3) Section 4 The absence of ERLD-MSD advertisements indicates only that the advertising node does not support advertisement of this capability. Do you mean to differentiate between support for the capability itself v/s support for 'advertisement' only. But RFC 8662 says that ERLD value is advertised only when following conditions are met: * MUST be entropy label capable and, as a consequence, MUST apply the data-plane procedures defined in [RFC6790]. * MUST be able to read an ELI/EL, which is located within its ERLD value. * MUST take into account an EL within the first ERLD labels in its load-balancing function. Thus, I am not sure about this sentence. Maybe you mean to say that the absence only indicates that the ERLD-MSD value of the node is unknown (and it might still be capable of handling ELI/EL)? (4) Section 4 What would be the behavior if an OSPF router receives a ERLD of the node but no ELC set for the corresponding prefix? That would be an error as per RFC 8662, we should specify how one handles it within OSPF. If it is to just ignore the ERLD, we should explicitly say that. Nits: (1) Change OSPF Working group to LSR Working group in the metadata (first line of the I-D) (2) Abstract - use term LSP instead of tunnel for consistency OLD: An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that tunnel. NEW: An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. END (3) Section 4 s/Node MSD sub-TLV/Node MSD TLV/ (4) Expand BGP-LS on first use. Thanks! Dhruv From nobody Wed May 6 04:40:33 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBF53A08B5; Wed, 6 May 2020 04:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 MxFeaN1eEF_x; Wed, 6 May 2020 04:40:23 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BECEF3A0864; Wed, 6 May 2020 04:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5342; q=dns/txt; s=iport; t=1588765223; x=1589974823; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=7EWEw4dPco2atjWauSW5Kg+bdPmxj7ZQxnAG7P9wvWI=; b=PmODbNqywqFEGEQU/+6Ie9zfSdpO4FdDQoP4zOOjtJ8RsKHd+WxVn6DH y0xTdtnLKYyLAkND2SZ/wASkALslGXJK1py4PBaHWoGU3rjwkbuYeesA6 xM7+rTBA2rX4xmBXIIigeMdHnXWR3fs7l9ZfIVYRRX3+jFqjLtV+iC1Wg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AABWobJe/xbLJq1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFHgxhVIBIqBIQfiQGHYS2Zd4FnCwEBAQ4?= =?us-ascii?q?lCgQBAYREAoIlOBMCAwEBCwEBBQEBAQIBBQRthVYMhXEBAQEBAgEjDwEFQRA?= =?us-ascii?q?LFAQCAhEVAgJXBgEMCAEBgyIBglwgD7MDdoEyhD0CAQsCQAFCg0WBQIEOKoU?= =?us-ascii?q?sDoVrgTmBQT+BEAEngmk+glwLAgMBgRqBBoJTgmAEokuQBoJSgnCFKI94Bh2?= =?us-ascii?q?CW4EMh1WEVCeMaZAXiVSTcIFpIoFWMxoIGxWDJQhHGA2ZSIVEPwMyNQIGAQc?= =?us-ascii?q?BAQMJkkYBAQ?= X-IronPort-AV: E=Sophos;i="5.73,358,1583193600"; d="scan'208";a="25937824" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2020 11:40:20 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 046BeJws013796; Wed, 6 May 2020 11:40:20 GMT To: Dhruv Dhody , rtg-dir@ietf.org Cc: draft-ietf-ospf-mpls-elc.all@ietf.org, lsr@ietf.org, last-call@ietf.org References: <158867189453.14412.14632358918213286203@ietfa.amsl.com> From: Peter Psenak Message-ID: <8dd49248-84bd-a546-8fee-767ab75a182a@cisco.com> Date: Wed, 6 May 2020 13:40:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <158867189453.14412.14632358918213286203@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-ospf-mpls-elc-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 11:40:26 -0000 Hi Dhruv, thanks, for your comments, please see inline: On 05/05/2020 11:44, Dhruv Dhody via Datatracker wrote: > Reviewer: Dhruv Dhody > Review result: Has Issues > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing ADs. > For more information about the Routing Directorate, please see > ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > > Document: draft-ietf-ospf-mpls-elc-13 > Reviewer: Dhruv Dhody > Review Date: 2020-05-05 > IETF LC End Date: 2020-05-05 > Intended Status: Proposed Standard > > Summary: > I have some minor concerns about this document that I think should be resolved > before publication. > > Comments: > > Disclaimer: I reviewed an earlier version (-09) as part of the early > directorate review, which could be located at - > https://datatracker.ietf.org/doc/review-ietf-ospf-mpls-elc-09-rtgdir-early-dhody-2019-09-12/ > > I have reviewed this and the IS-IS I-D together and you will find similar > comments for both I-Ds. You could discuss them in one place. > > Major Issues: > None > > Minor Issues: > (1) Introduction > > Recently, mechanisms have been defined to signal labels via link- > state Interior Gateway Protocols (IGP) such as OSPFv2 [RFC8665] and > OSPFv3 [RFC8666]. > > Is there a better way to introduce OSPF extension for SR (than saying that > it is just an example to signal labels)? What about: Segment Routing with the MPLS Data Plane relies on Interior Gateway Protocols (IGP) such as OSPFv2 [RFC8665] and OSPFv3 [RFC8666] to signal labels. > > (2) Section 3 > > Query: The text says that the ABR "MUST" preserve the ELC setting where as > the ASBR "SHOULD" preserve it. What is the reason for using SHOULD in case > of ASBR? Maybe we can spell out in which case ASBR might not preserve the > ELC setting. redistribution is a local matter on the box and is not standardized, so it's quite hard to mandate a specific behavior. That's why SHOULD. > > (3) Section 4 > > The absence of ERLD-MSD advertisements indicates only that the > advertising node does not support advertisement of this capability. > > Do you mean to differentiate between support for the capability itself v/s > support for 'advertisement' only. But RFC 8662 says that ERLD value is > advertised only when following conditions are met: What is meant is that even though all the below conditions are set, if the node does not support the advertisement, one can not conclude what its ERLD is. If the node supports the advertisement of the ERLD, but the below conditions are not met, the node should not advertise the ELC capability in a first place. > > * MUST be entropy label capable and, as a consequence, MUST apply > the data-plane procedures defined in [RFC6790]. > > * MUST be able to read an ELI/EL, which is located within its ERLD > value. > > * MUST take into account an EL within the first ERLD labels in its > load-balancing function. > > Thus, I am not sure about this sentence. Maybe you mean to say that the > absence only indicates that the ERLD-MSD value of the node is unknown (and > it might still be capable of handling ELI/EL)? > > (4) Section 4 > > What would be the behavior if an OSPF router receives a ERLD of the node > but no ELC set for the corresponding prefix? That would be an error as per > RFC 8662, we should specify how one handles it within OSPF. If it is to > just ignore the ERLD, we should explicitly say that. the behavior is specified in the RFC 8662. OSPF is just a messenger, not the consumer of this information. > > Nits: > (1) Change OSPF Working group to LSR Working group in the metadata (first line > of the I-D) fixed. > > (2) Abstract - use term LSP instead of tunnel for consistency > > OLD: > An ingress Label > Switching Router (LSR) cannot insert ELs for packets going into a > given Label Switched Path (LSP) unless an egress LSR has indicated > via signaling that it has the capability to process ELs, referred to > as the Entropy Label Capability (ELC), on that tunnel. > NEW: > An ingress Label > Switching Router (LSR) cannot insert ELs for packets going into a > given Label Switched Path (LSP) unless an egress LSR has indicated > via signaling that it has the capability to process ELs, referred to > as the Entropy Label Capability (ELC), on that LSP. > END fixed. > > (3) Section 4 s/Node MSD sub-TLV/Node MSD TLV/ fixed. > > (4) Expand BGP-LS on first use. done. thanks, Peter > > Thanks! > Dhruv > > > > > From nobody Wed May 6 04:40:45 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911CA3A099E; Wed, 6 May 2020 04:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 AL4K6-9mGpEm; Wed, 6 May 2020 04:40:29 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5473A0973; Wed, 6 May 2020 04:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5464; q=dns/txt; s=iport; t=1588765229; x=1589974829; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=55G0C78m0/MC23kYu4gWWyjTguVV1rp3MhT+NXffQ1M=; b=FW9ZjmtdEGeLtPpLz9gDtGh8WXrHHPOGztgnJOV2aUTuiE3bn1Rd1Eg7 8jmsMgaN931Hv/hM39k1/9BnXiPkCmeLzHDN4I4Hq+N4UbPYCVnpdk3SY /KntSD1gVD8Ua7bvpGvnLVl41VNEoR6ES9hxr2JOo+COr9pixZKw6AtF2 M=; X-IPAS-Result: =?us-ascii?q?A0B3AADFobJe/xbLJq1mGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFHgxhVIBIqBIQfiQGHYQglmXeBZwsBAQEOJQoEAQGERAKCJ?= =?us-ascii?q?TgTAgMBAQEDAgMBAQEBBQEBAQIBBQRthVYMhXEBAQEBAgEjDwEFLxIQCxQEA?= =?us-ascii?q?gIRFQICVwYBDAgBAYMiAYJcIA+zA3aBMoQ9AgELAkABQoNFgUCBDiqFLA6Fa?= =?us-ascii?q?4E5gUE/gRABJwyCXT6CXAsCAwGBGoEGglOCYASiS5AGglKCcIUoj3gGHYJbg?= =?us-ascii?q?QyHVYRUJ4xpkBeJVJNwgWkigVYzGggbFYMlCEcYDZlIhUQ/AzI1AgYBBwEBA?= =?us-ascii?q?wmSRgEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.73,358,1583193600"; d="scan'208";a="23606378" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2020 11:40:20 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 046BeJOV026397; Wed, 6 May 2020 11:40:19 GMT To: Dhruv Dhody , rtg-dir@ietf.org Cc: lsr@ietf.org, last-call@ietf.org, draft-ietf-isis-mpls-elc.all@ietf.org References: <158867180371.13174.5911030866330688420@ietfa.amsl.com> From: Peter Psenak Message-ID: Date: Wed, 6 May 2020 13:40:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <158867180371.13174.5911030866330688420@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-isis-mpls-elc-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 11:40:35 -0000 Hi Dhruv, thanks, for your comments, please see inline: On 05/05/2020 11:43, Dhruv Dhody via Datatracker wrote: > Reviewer: Dhruv Dhody > Review result: Has Issues > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing ADs. > For more information about the Routing Directorate, please see > ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > > Document: draft-ietf-isis-mpls-elc-12 > Reviewer: Dhruv Dhody > Review Date: 2020-05-05 > IETF LC End Date: 2020-05-05 > Intended Status: Proposed Standard > > Summary: > I have some minor concerns about this document that I think should be resolved > before publication. > > Comments: > Disclaimer: I reviewed an earlier version (-08) as part of the early > directorate review, which could be located at - > https://datatracker.ietf.org/doc/review-ietf-isis-mpls-elc-08-rtgdir-early-dhody-2019-09-12/ > > I have reviewed this and the OSPF I-D together and you will find similar > comments for both I-Ds. You could discuss them in one place. > > Major Issues: > None > > Minor Issues: > > (1) Introduction > > Recently, mechanisms have been defined to signal labels via link- > state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667]. > > Is there a better way to introduce IS-IS extension for SR (than saying that > it is just an example to signal labels)? What about: Segment Routing with the MPLS Data Plane relies on Interior Gateway Protocols (IGP) such as IS-IS [RFC8667] to signal labels. > > (2) Section 3 > > Query: The text says that the ABR "MUST" preserve the ELC setting where as > the ASBR "SHOULD" preserve it. What is the reason for using SHOULD in case > of ASBR? Maybe we can spell out in which case ASBR might not preserve the > ELC setting. redistribution is a local matter on the box and is not standardized, so it's quite hard to mandate a specific behavior. That's why SHOULD. > > (3) Section 4 > > The absence of ERLD-MSD advertisements indicates only that the > advertising node does not support advertisement of this capability. > > Do you mean to differentiate between support for the capability itself v/s > support for 'advertisement' only. But RFC 8662 says that ERLD value is > advertised only when following conditions are met: What is meant is that even though all the below conditions are set, if the node does not support the advertisement, one can not conclude what its ERLD is. If the node supports the advertisement of the ERLD, but the below conditions are not met, the node should not advertise the ELC capability in a first place. > > * MUST be entropy label capable and, as a consequence, MUST apply > the data-plane procedures defined in [RFC6790]. > > * MUST be able to read an ELI/EL, which is located within its ERLD > value. > > * MUST take into account an EL within the first ERLD labels in its > load-balancing function. > > Thus, I am not sure about this sentence. Maybe you mean to say that the > absence only indicates that the ERLD-MSD value of the node is unknown (and > it might still be capable of handling ELI/EL)? > > I see similar language in RFC8491 but I think we could be clearer in this > I-D for ERLD. > > (4) Section 4 > > What would be the behavior if an IS-IS router receives an ERLD of the node > but no ELC set for the corresponding prefix? That would be an error as per > RFC 8662, we should specify how one handles it within IS-IS. If it is to > just ignore the ERLD, we should explicitly say that. the behavior is specified in the RFC 8662. ISIS is just a messenger, not the consumer of this information. > > (5) Section 4 > > We need to clearly state that this new MSD Type is carried in Node MSD > sub-TLV as described in [RFC8491]. And then I guess we don't really need > figure 2? The format is as per RFC 8491! done. > > Nits: > > (1) Abstract - use term LSP instead of tunnel for consistency > > OLD: > An ingress Label > Switching Router (LSR) cannot insert ELs for packets going into a > given Label Switched Path (LSP) unless an egress LSR has indicated > via signaling that it has the capability to process ELs, referred to > as the Entropy Label Capability (ELC), on that tunnel. > NEW: > An ingress Label > Switching Router (LSR) cannot insert ELs for packets going into a > given Label Switched Path (LSP) unless an egress LSR has indicated > via signaling that it has the capability to process ELs, referred to > as the Entropy Label Capability (ELC), on that LSP. > END > fixed > (2) Expand BGP-LS on first use! fixed. thanks, Peter > > Thanks! > Dhruv > > > > From nobody Wed May 6 08:15:21 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A815B3A0743 for ; Wed, 6 May 2020 08:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=b8+mACaS; dkim=pass (1024-bit key) header.d=juniper.net header.b=M9WvY4bS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXrOGIMk8Q0G for ; Wed, 6 May 2020 08:15:14 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505613A080E for ; Wed, 6 May 2020 08:14:55 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 046FDKsv018990 for ; Wed, 6 May 2020 08:14:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=C2WgZDqNplkKrv+4QOEgDZk4fSSQZWMfaf75B5dnNIU=; b=b8+mACaSuDrPvHkqu0/8GsSN0q6ubn/eQa3kuImDDo0iValW4aFt9Efpuk7x2gRV80D4 KfQRMNzO6fa1mG7GYaJTSvflYRgbauoF0D1shdzhhWGiHLHBsYDiZFbrUUWGsIJ1/NSi Qdy1uIUNk+AqJkZrbMzKQf1zJmblIAsnE1Q9iYFi5JcIGQ2DjKLJNq3Lsy/lqffgkIfj Q4qWrIK8BUXd5THozRtCwPjErXrLSH+VtoJE3eNYbxtl+6i2ynnsBxF4s2+I3Q7oazEp ljqNl3fhOz6U4GZM4nqmWqWo/1oX4Tds5yvs2ehPnx9HoIwSjQ4cFAcH+cl2klxIpGCJ mw== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by mx0a-00273201.pphosted.com with ESMTP id 30uxk204nx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 06 May 2020 08:14:54 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RDC6/Wjvf4Yy81Z8c9QsMcZd3uBzbEPUesKG6P5udiAiFeKXH82j7wfsw2pDFvooJRhVmXN7YQZyh/1XtRxY7m6eL/bcThD731K4mTin5Ca1WnLbfozYO7lxquHg9qsEjPv5BAPN4KF+3Z2ibZli2Jz2Fy0ijBGkE8trUdKw8zsoV1lBAdwZPJfwOF/6UTgTP7zbcjdGYH8rE+F+A6UCIhNdwaDNtnX3WSOfVQzGLI0zboi8XnOvlEft7fj0lwWkHfQOMe606b68sjpMAntMMe/GmiImZI1OiJnfzT/q6IIuqUgal9icRcyYP3fcWD0NRkqaa3mQSwztgZQN4X9Nig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C2WgZDqNplkKrv+4QOEgDZk4fSSQZWMfaf75B5dnNIU=; b=fzxrnAho0Sy/kR0KHdqD73eSfcdwGDGoKrbOwgIXzmkz0Aqcttc0Pu6a//vGRMTr+Q9y+L1uW0XMgWuNfCOzEjuELXxWWen+ng7r8QhQeg3ZofkKkVwznqYyj6O2F6XJ3HTURdX/DJO9/gRnABnKCt3ELuLYLKSDSflvtFMLcM6PGE6Awj9IcZzyom06pE/VzQhNpQOuaO7jFuxHVtyaR+VOWV23x1IL4A/DsoQ9kNXjGTlHIfBsPBMqcCym0WM3HMQNOwg7SxTgIjwMbejdnjIBF7qJ1Pd3XbWabKXoiz2HTHoGP3jueE5pdUS6aXdLql+JlKi7HKIQacNm8NhxiA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C2WgZDqNplkKrv+4QOEgDZk4fSSQZWMfaf75B5dnNIU=; b=M9WvY4bS4Ay5tZdRLwwZMf5IGETdCMwgsijOyR6r8B7bc54z1mZnGwVJafDWUcvoynkv+GzxMTqwSzen5/wqNYAmYBr40Po2VwvcrF/f3wBVBglp5u0R1P0iA0tjq1qHCg73TBBR8cAtDCIT8Kp6R+cSsA2gX+pdYyrYhF8RkbM= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB4969.namprd05.prod.outlook.com (2603:10b6:5:7c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.11; Wed, 6 May 2020 15:14:52 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.2979.028; Wed, 6 May 2020 15:14:52 +0000 From: Ron Bonica To: "rtg-dir@ietf.org" Thread-Topic: OPSDIR Review of draft-ietf-idr-bgp-ls-segment-routing-msd Thread-Index: AdYUAJ1FbMfKh2WrSpSoTjnEiNWoawPuHG4A Date: Wed, 6 May 2020 15:14:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-04-16T15:28:49.5039601Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=ce017d57-656d-42f2-880a-4f309837a7c0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f53ca8b8-257d-4167-332e-08d7f1d03a42 x-ms-traffictypediagnostic: DM6PR05MB4969: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: STl3OfOhpsMCUnmSHE9npWeDShvXuV9X0jl/asyzddi8bhU2Oo9yV51vUvFmLV+vGSynseTmBJTBy40QhQcAIlLWcERoDQ5CxAL8PLyiyONbVy623MBN9yUKwYCx1CkYTH8wneDcH/ccc4u1ThS717AZ11SMhciLPZk3u0rud+t43LP+ncH9l5xrYAYyfD3VtuEqESgQ6oFAKjjSrcFkcLYS/S4Sp1O3g6tebG2n8V5xN6IGYost7xOxHNWcJR4AbvV4nKZkqPC8cS7qOCyRWVCO+p+tm5yYYs5IV2j7/LT+MU9gQy3ysXd8O/XcYXn8EfVhHeHWpI6NvHbaQ0ejoyyREUHLZxiu5yDecn9cJHyNkgIPLvvuxUV1isN+2agfvA+6sCCobK9/V+0MAf+fw4R3yQ537TIvUU3oHdM0SEWMhsCljmW7MpqwGP/w52BwU1V3nWWzd47SJdVgGRiC8m8P1YNoaTml/ok6MRiEhO47PbH2DiZEvjUcYPV00RJNGlEy6MFw6CMPm+1Xh5CnsA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(376002)(366004)(396003)(136003)(33430700001)(66946007)(76116006)(8936002)(8676002)(55016002)(7696005)(4744005)(9686003)(71200400001)(186003)(66476007)(33440700001)(478600001)(2906002)(52536014)(26005)(6916009)(86362001)(5660300002)(64756008)(66556008)(53546011)(316002)(66446008)(33656002)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 4iik/qykiS/Xj6MPl49/Hc7ww6di2DjcvI5LF9LL/dNDiELyj4hAox6l1RBaRjkVb4lsmicFTSYgJ+d725huSzfR0bzMcMceVmdRWvr63Fdd7IJBudZihVNaljD6tGTd7Wda4j2llq5LhrdEy3sA+5+Ed+yzuaU2HF6dqfUQrLdvwl7mrzUSeubYlEP5rxvtwO8KMQW5mZ4SfgHYS3ikcrQnzj/tZfKYagTgfIgDcqb2K+djy1mvn+LOiJTjQdaIUb84nkZeJj+apTiVctoAwm1Cr2RZXFvTZJpilJYbNKQ2TKz9rVx4B0GmkJbFjyQ9XbbDTPt5joGCoajwRi5FOc73BzuLf8vsPQWP9JiBdEOu74hYWFCFK5h7oeZhyXnelx1IZQ67+lHjPbKCsloQ0IvRPd7r44MzfIzWvkBpLN4a3Y00EfuVfqFmxTh6l3z1oMwpXK+9NYpWeb7qRomcnSQYWDEoy61+HPlLDThqsQ/S/bHfmkrnJZAi+jrvq1T+XJqYeV2VnrYgGgEj347f0AQ1/eciHV63RUxoqcglsN7aATySqc/1j8F1V+RT9o+hYyaxRtI918XricPegkL3DWNnep1tIt9RWeHqe97vo6OIMihOgjpQbzXCgB3hDctf/hgfPOwETVchm4xPhny6AqRnB/fKemvCXK0aYyLf57SKLrGt2Pvjp1gS9APGF/J2u2VmUPlxkuitDmnnukHkZprJJKqulPu5i54y4fMJbQF89eRzBg6rQJqEpwVdkZCfuU/nvBIVfppbksToY5jtSj8BjTs7tCbowUFySX9WwF4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB6348DD369EB8B502CD29B9DBAEA40DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: f53ca8b8-257d-4167-332e-08d7f1d03a42 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 15:14:52.7264 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jvYsBLJ0FY37+KSxW1FsrrjQ2xXzTQmeHV5yV9RepogoKVp4KhP9V1eEvRZX52OGWNtorYEGMCAgkj+sO8FV4w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4969 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-05-06_08:2020-05-05, 2020-05-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 phishscore=0 clxscore=1011 malwarescore=0 spamscore=0 impostorscore=0 bulkscore=0 adultscore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005060123 Archived-At: Subject: [RTG-DIR] FW: OPSDIR Review of draft-ietf-idr-bgp-ls-segment-routing-msd X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 15:15:17 -0000 --_000_DM6PR05MB6348DD369EB8B502CD29B9DBAEA40DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juniper Business Use Only From: Ron Bonica Sent: Thursday, April 16, 2020 11:29 AM To: ops-dir@ietf.org; draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.or= g Subject: OPSDIR Review of draft-ietf-idr-bgp-ls-segment-routing-msd Folks, I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These= comments were written with the intent of improving the operational aspects= of the IETF drafts. Comments that are not addressed in last call may be in= cluded in AD reviews during the IESG review. Document editors and WG chair= s should treat these comments just like any other last call comments. Summary: Ready for publication Fully cooked. I would vote YES. Major issues: None Minor issues: None Nits: None Juniper Business Use Only Juniper Business Use Only --_000_DM6PR05MB6348DD369EB8B502CD29B9DBAEA40DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

 

Juniper Business Use Only

From: Ron Bonica
Sent: Thursday, April 16, 2020 11:29 AM
To: ops-dir@ietf.org; draft-ietf-idr-bgp-ls-segment-routing-msd.all@= ietf.org
Subject: OPSDIR Review of draft-ietf-idr-bgp-ls-segment-routing-msd<= o:p>

 

Folks,

 

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

 

Summary: Ready for publication

 

Fully cooked. I would vote YES.

 

Major issues:

 

None

 

Minor issues:

 

None

 

Nits:

 

None

 

 

 

Juniper Business Use Only


Juniper Business Use Only

--_000_DM6PR05MB6348DD369EB8B502CD29B9DBAEA40DM6PR05MB6348namp_-- From nobody Wed May 6 08:41:01 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF5D3A0B4B; Wed, 6 May 2020 08:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_wHcSRqBzyN; Wed, 6 May 2020 08:40:50 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 6F5653A0B3B; Wed, 6 May 2020 08:40:45 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id f3so2676840ioj.1; Wed, 06 May 2020 08:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3DtQEX+Fh0wrj3QLdJZ9bsSSEbycZ666Rk6GDXm54Uk=; b=ESH84hkcc8lmabKB/Yu6C2NSp3vgvrZV1huqHNXwW68xvk+YLvr5eko2qj3oQoNyso 2BXF/KRLhMiu+YNdnP0FSxub1A130cB/w/6eX8rohl8llnEG3AE9VzycQxDXe7mFAHtB 4SDOZYLs4GCThDqr8HaD5c03pLP9uBWq43ZQm+vjsqgfcTSEUCR6YkJr7dhl93YnnMf5 rMYYjTvyIRAQgB8U7x4g2tFWHxoYJJafkzKc+pFBuwPJvrKQZYAVKHSho6XZGo1ewpAc +YFqLvSmRWBoUbg93eKDcAuWU1NB035DFM6eGgj/bPddHqlLqa+z6aYD1YNWwMCxPIuk KbkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3DtQEX+Fh0wrj3QLdJZ9bsSSEbycZ666Rk6GDXm54Uk=; b=P2VEglTBojYgAMBpT/BcmYh7RKTHhwBouyIT8llWpUw5I4elSguzbNx24NnkQ2BjNs g3QCkwFvxZjW0V7TIuVbgLoMPgM0pErzhOmg/2VOQzoHcresd2s3QU8FBVnAcOxK4npD Bqp6EZQoUE8otJQh/M22J1RUh1WEHn0v9FsgxW919WxtQdtvuGuDP1TYvXV58h4hUfeD ocP+xUWMsEzmhcQT1DiRV50UtLQEl30pgW4E5VVGGt1a1uQntZUcxGHYRL90DJ2T6Lsu NTCUfoZGFx3Sx7AwgaggGcT9KAOChouWrbmf0HN1i1BVWSvMBmhhdVXgACcE4lSaC0aQ a9Iw== X-Gm-Message-State: AGi0PuZ2aOvwW4Dn0FHvEeiBKj6kGalVVBkkizk+iuJqi01Km0lY3Yy0 lklMUBJLjseREexRIRowYrl9A41E6hDOUa00HqVmbO6fBUo= X-Google-Smtp-Source: APiQypLjWXYGNYD7bPLlXrZ79imwPzVAdbciRrp2naphC8GoVLkfwmePc103G93Gwwk0cmLYySGdPmsATpzb9dkoexc= X-Received: by 2002:a02:8785:: with SMTP id t5mr8741030jai.15.1588779644535; Wed, 06 May 2020 08:40:44 -0700 (PDT) MIME-Version: 1.0 References: <158867189453.14412.14632358918213286203@ietfa.amsl.com> <8dd49248-84bd-a546-8fee-767ab75a182a@cisco.com> In-Reply-To: <8dd49248-84bd-a546-8fee-767ab75a182a@cisco.com> From: Dhruv Dhody Date: Wed, 6 May 2020 21:10:08 +0530 Message-ID: To: Peter Psenak Cc: rtg-dir@ietf.org, draft-ietf-ospf-mpls-elc.all@ietf.org, lsr@ietf.org, last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-ospf-mpls-elc-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 15:40:52 -0000 Hi Peter, Thanks for your reply, snipping to points that need further discussion... > What about: > > Segment Routing with the MPLS Data Plane relies on Interior Gateway > Protocols (IGP) such as OSPFv2 [RFC8665] and OSPFv3 [RFC8666] to signal > labels. > Much better. > > (3) Section 4 > > > > The absence of ERLD-MSD advertisements indicates only that the > > advertising node does not support advertisement of this capability. > > > > Do you mean to differentiate between support for the capability itself v/s > > support for 'advertisement' only. But RFC 8662 says that ERLD value is > > advertised only when following conditions are met: > > What is meant is that even though all the below conditions are set, if > the node does not support the advertisement, one can not conclude what > its ERLD is. > > If the node supports the advertisement of the ERLD, but the below > conditions are not met, the node should not advertise the ELC capability > in a first place. > There are two things here - (a) the actual load balancing capability of a node (b) the capability to advertise the ELC/ERLD. Usually capability and the advertisement of the capability go together. In this case we want to be explicit that the absence of ERLD-MSD indicates just (b) and not (a). You do use the word "only", so may its all fine! I will leave it to you/shepherd. > > > > * MUST be entropy label capable and, as a consequence, MUST apply > > the data-plane procedures defined in [RFC6790]. > > > > * MUST be able to read an ELI/EL, which is located within its ERLD > > value. > > > > * MUST take into account an EL within the first ERLD labels in its > > load-balancing function. > > > > Thus, I am not sure about this sentence. Maybe you mean to say that the > > absence only indicates that the ERLD-MSD value of the node is unknown (and > > it might still be capable of handling ELI/EL)? > > > > (4) Section 4 > > > > What would be the behavior if an OSPF router receives a ERLD of the node > > but no ELC set for the corresponding prefix? That would be an error as per > > RFC 8662, we should specify how one handles it within OSPF. If it is to > > just ignore the ERLD, we should explicitly say that. > > the behavior is specified in the RFC 8662. OSPF is just a messenger, > not the consumer of this information. > Is there some text in RFC 8662 the clarify what one does on the receiving side? I found only the sending conditions in section 4. How does a receiving node behaves when he receives conflicting information, which one does he trust (no ELC present or ERLD=10). We could have interop issues here if you leave it open. Thanks! Dhruv PS. Since the comments are the same for the IS-IS I-D, no need duplicate them. From nobody Wed May 6 09:00:12 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFF23A0B67; Wed, 6 May 2020 09:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 c_ZfvOdmUscT; Wed, 6 May 2020 08:59:59 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D5C3A08CB; Wed, 6 May 2020 08:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3600; q=dns/txt; s=iport; t=1588780799; x=1589990399; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=JqSc6XF7pFZlXXgurIO2E9w4ghmaPk+vME7dscpoFAc=; b=kWsjI0FcvwkBJQYza1TI7/TA65vWwnc54zP9q2td+9gmv2WAsHQQOKQx o6Px+10/KmgnBKgpqMN6aRueHBjgL+WncxhTrAdDIPaeRc78b15Us5n6B rxQq5ufCdAKcOpWZwsqfteFO9H6Hy9UbNsw93nQ8qiW/zLqydGQ8WQzur E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAACb3rJe/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTYEAQELAYNsIBKETYkBh2AtmXeBZwsBAQEOLwQBAYREAoI?= =?us-ascii?q?lNwYOAgMBAQsBAQUBAQECAQUEbYVihXEBAQEBAgEjFUEQCxgCAhEVAgJXBg0?= =?us-ascii?q?IAQGDIoJdILNQdoEyhVCDPoFAgQ4qAYxdgUE/gRABJ4JpPoQHH2eCU4JgBJk?= =?us-ascii?q?KmUeCUoJwlSAGHYJbiGGEVCeMaa1bgWgjgVYzGggbFYMlTxgNnww/A2cCBgg?= =?us-ascii?q?BAQMJkAKCRAEB?= X-IronPort-AV: E=Sophos;i="5.73,359,1583193600"; d="scan'208";a="25882149" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2020 15:59:56 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 046Fxsgv001506; Wed, 6 May 2020 15:59:55 GMT To: Dhruv Dhody Cc: rtg-dir@ietf.org, draft-ietf-ospf-mpls-elc.all@ietf.org, lsr@ietf.org, last-call@ietf.org References: <158867189453.14412.14632358918213286203@ietfa.amsl.com> <8dd49248-84bd-a546-8fee-767ab75a182a@cisco.com> From: Peter Psenak Message-ID: Date: Wed, 6 May 2020 17:59:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-ospf-mpls-elc-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 16:00:02 -0000 Hi Dhruv, please see inline: On 06/05/2020 17:40, Dhruv Dhody wrote: > Hi Peter, > > Thanks for your reply, snipping to points that need further discussion... > >> What about: >> >> Segment Routing with the MPLS Data Plane relies on Interior Gateway >> Protocols (IGP) such as OSPFv2 [RFC8665] and OSPFv3 [RFC8666] to signal >> labels. >> > > Much better. > > >>> (3) Section 4 >>> >>> The absence of ERLD-MSD advertisements indicates only that the >>> advertising node does not support advertisement of this capability. >>> >>> Do you mean to differentiate between support for the capability itself v/s >>> support for 'advertisement' only. But RFC 8662 says that ERLD value is >>> advertised only when following conditions are met: >> >> What is meant is that even though all the below conditions are set, if >> the node does not support the advertisement, one can not conclude what >> its ERLD is. >> >> If the node supports the advertisement of the ERLD, but the below >> conditions are not met, the node should not advertise the ELC capability >> in a first place. >> > > There are two things here - (a) the actual load balancing capability > of a node (b) the capability to advertise the ELC/ERLD. Usually > capability and the advertisement of the capability go together. In > this case we want to be explicit that the absence of ERLD-MSD > indicates just (b) and not (a). > > You do use the word "only", so may its all fine! I will leave it to > you/shepherd. yes, the absence of ERLD-MSD advertisements only indicates that a node does not support advertisement of (b). It can not be interpreted that (b) is not supported. Old nodes that do not advertise ERLD-MSD can not be assumed not to support non-zero ERLD. The "only" is there to express the above. > >>> >>> * MUST be entropy label capable and, as a consequence, MUST apply >>> the data-plane procedures defined in [RFC6790]. >>> >>> * MUST be able to read an ELI/EL, which is located within its ERLD >>> value. >>> >>> * MUST take into account an EL within the first ERLD labels in its >>> load-balancing function. >>> >>> Thus, I am not sure about this sentence. Maybe you mean to say that the >>> absence only indicates that the ERLD-MSD value of the node is unknown (and >>> it might still be capable of handling ELI/EL)? >>> >>> (4) Section 4 >>> >>> What would be the behavior if an OSPF router receives a ERLD of the node >>> but no ELC set for the corresponding prefix? That would be an error as per >>> RFC 8662, we should specify how one handles it within OSPF. If it is to >>> just ignore the ERLD, we should explicitly say that. >> >> the behavior is specified in the RFC 8662. OSPF is just a messenger, >> not the consumer of this information. >> > > Is there some text in RFC 8662 the clarify what one does on the > receiving side? I found only the sending conditions in section 4. How > does a receiving node behaves when he receives conflicting > information, which one does he trust (no ELC present or ERLD=10). We > could have interop issues here if you leave it open. well, if the node does not support ELC, then ERLD value is irrelevant. It's like having a speed limit for a road with no entry. But that is something that does not belong to protocol drafts. thanks, Peter > > Thanks! > Dhruv > > PS. Since the comments are the same for the IS-IS I-D, no need duplicate them. > > From nobody Wed May 6 10:07:08 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CDF3A0827; Wed, 6 May 2020 10:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=O4+/b8el; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=t5W+L10R Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLBsFqv29w2Y; Wed, 6 May 2020 10:06:59 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F60A3A0851; Wed, 6 May 2020 10:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5694; q=dns/txt; s=iport; t=1588784815; x=1589994415; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oLMWnCMiyl1mm12BuwsIQ5/pZIv8ecaPlW8wKDSn9/o=; b=O4+/b8elNXijU6zOdxogVgUKRS2OnhHIU+X9aGv84GYLhcMtGKvcX9F2 UGI2ZejxK3kLj1mDuUEqu8XzX/ArOWwMkTmaejOyMPXxbM+U52Od2k0Sj qQKowTQDWjM1h1Z6SnWU+qSY6GhBiAk/Fmz+Ex2bkfMOKV48z6G90jztz o=; IronPort-PHdr: =?us-ascii?q?9a23=3AmPnpkxd1fXhVYcRwjngz4dRclGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfQ6ulPjKzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutbFzJqXr05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAABL7rJe/5BdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIE1AwEBAQELAYFTUQWBRi8qCoQZg0YDjSA?= =?us-ascii?q?lmDWBLhSBEANUCwEBAQwBAS0CBAEBhEQCF4FqJDYHDgIDAQELAQEFAQEBAgE?= =?us-ascii?q?FBG2FVgyFcQEBAQECARIREQwBATcBDwIBCBgCAhEVAgICMBUQAgQBDQUigwS?= =?us-ascii?q?CTAMOIAGpOgKBOYhhdoEygwABAQWFFBiCDgmBDioBgmKJYRqCAIEQAScMEIJ?= =?us-ascii?q?NPoQHHygXKIJTM4ItkUmhDAqCSJgWHYJbiGGEe4xpkBedHAIEAgQFAg4BAQW?= =?us-ascii?q?BWAEygVZwFWUBgj5QGA2QQoNyilZ0NwIGAQcBAQMJfI8GgTQBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,360,1583193600"; d="scan'208";a="764951450" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2020 17:06:33 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 046H6XUO002898 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2020 17:06:33 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 12:06:33 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 12:06:32 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 6 May 2020 12:06:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kysww00QayASvmAGc2TC2pQkAV6vAAP29/hAFm/iSef7JqkHk+w2ErhfKZ+3TXHQipviNSKYlWMS0dcz2c+uDQlaelaT53n01QKargvfWSEoKvBgWgt1VvEWXhok64l/9sTCWXaRMbewReeY/eN/JirEefXtEmBDI4ffWlAYQNfZNqAVsC2xQnQa7tvJZEohrwnjFsBBy1isEB/9YLEYfYxTJPVzMwrAB0X0CorC/si58yHlt6wcmXjnmVyaqucfXVB8fg+LI2N45xnNkndvzPfBQsPnlGiMaj6w6ERGFHx8f7N0WiDERJ4CBk53uYpuXW4S/32GJxP45Ksn/dQmZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oLMWnCMiyl1mm12BuwsIQ5/pZIv8ecaPlW8wKDSn9/o=; b=QJZ0ARi3kC1bKF/x+s8p3fkHexW+OTyQjV100fCoO1sETx6j2WUsqvbP8pgq+D6rFQ2S4xtZQ3ke1PaSOlnmWIsMq+FP81yEhoyuuJ+5TsNWNNb58w9DKT4YN3vaXwO0jk5UwNWq5TRG4fBcbjxJNwBqMIvLLNW6o2VO1OZqV7FYJppZFXOyRC0JMPqgAW5TnNrMhXQaXZcV/JRR0vfTfDtlb3dQ7uQDEZZH/iPiwJdX5dSGjT5/06O0Pt0Nt/r5fZkTowbV1uWxdzD5gwmdkxJp97y9i0gKwmB87YE90t7xBai+R8Rf2M734xyLRDJLqMuLaAeUuDCvhjt0FklV9Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oLMWnCMiyl1mm12BuwsIQ5/pZIv8ecaPlW8wKDSn9/o=; b=t5W+L10RTBPdniwAPMdYcHZhYXiKKrNPDUCfVOES8DtEs+fgtHP+huUj7VvtYUJRJmFj3GTz6SSPxOdnQbTzK3X7HLcQpvJnUpPyeKqoRUUH2e3mYdS9d6fs4njABP8xSY56SmLWxRbDweMb8xGUuBoWLVxEYP9/1NPclj3UNig= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB2869.namprd11.prod.outlook.com (2603:10b6:a02:c0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Wed, 6 May 2020 17:06:31 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::4950:e26c:503f:768e]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::4950:e26c:503f:768e%6]) with mapi id 15.20.2958.029; Wed, 6 May 2020 17:06:31 +0000 From: "Acee Lindem (acee)" To: "Peter Psenak (ppsenak)" , Dhruv Dhody CC: "rtg-dir@ietf.org" , "draft-ietf-ospf-mpls-elc.all@ietf.org" , "lsr@ietf.org" , "last-call@ietf.org" Thread-Topic: Rtgdir last call review of draft-ietf-ospf-mpls-elc-13 Thread-Index: AQHWI7zJp1lIg/K4HkKAIOX4h/7ar6ibN0uA///Pi4A= Date: Wed, 6 May 2020 17:06:31 +0000 Message-ID: <101B38AE-6A11-4412-8E2D-B7C1DBE23855@cisco.com> References: <158867189453.14412.14632358918213286203@ietfa.amsl.com> <8dd49248-84bd-a546-8fee-767ab75a182a@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 358ec5f3-c2eb-4b31-cdff-08d7f1dfd312 x-ms-traffictypediagnostic: BYAPR11MB2869: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +MQF0Lb2V/Y0oEWH/7DrOgbWF2FNj+P23ekb87Q45/vUlWGFE2oBw51nUc0SpkyuEYHicSYOEnC93kR7sZ4SxjiE6QHaH/lyErDBDdaW41et2T6sac3B0H+We0MYKP6LldZDF5dvOhD/Xx7/ttHMLamX3jGiHO838tNaJfP8wzlSkKFPxyi0AmsQB2T47qMDbKipElZrZ0jDwCH0xjDyuDwiXoxq/No6M2XmLQ42P8AANKn3aku5GvliGkFFWEmtbVpYTUfu4q18zLLIi4hFfTU548QukuWI1foPyENgiM/EU+pIXfZ6Mg1O3YbyOnBOe1e3H6ZOFf1dKfIqmtTEzSev6XE5a2A4USnr4iBwIV+5Fq8cQMcpRgkxiM2SM5Wk2lpZLzcDCIJEH6PLziLqd04PPqNNj67zM597WPb7LpD7wTlRRZVTuyT/RJY3Y0KGs2T07ECgGA3fGt6UI4lb7Bt5Hd00eX39XlbWVLVhvMYMaURcvbQF4Bgirv5aUHxouiluAwvsoiVaHdLtsd5/jg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(376002)(346002)(39860400002)(366004)(33430700001)(86362001)(110136005)(2616005)(66574014)(71200400001)(316002)(54906003)(6486002)(33440700001)(53546011)(6506007)(186003)(8676002)(8936002)(26005)(478600001)(33656002)(64756008)(36756003)(66476007)(6512007)(66946007)(2906002)(4326008)(66446008)(5660300002)(76116006)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ZzXXqQqO9qVdRQSxdGMXAX+2tmUzaC/CS0EPdbqEH9+Cal8bF3VM91ONI+lsdH2WKKgmaPOuC4vIKAJqfm6Zbm1bz2lIt1WJbuUCuBPK6dnXWv0hohmtScsWV/ws0hE+wLZPqV8zEqRTKX5m4rdSQwy2S8D0EzxHwnZiFn4bZu6VEy/T9MJZH9JVR78tRmcYJUIo5YflBW1LS/ciS9p3bJMBEAO61IRoZcrNvl5KXtvPgqgzK9SeYLMKFwYfKZWGKX/I0bhqqlXLUb/WGFbEzTGuVQ+tx9Emf7fqgYWydOcqxZy4JZfqXfUMiWdtv1o7KueEBDam4FnXLY5GHgPkIeUgVH98ZB5jKEemHcWur/DpsM4gjYkFUuBCeBDQuT59C4GQZ0p1ReP1Dn4Wytag9OXnOmFQHojmnOYTP87HheXkZ4+WXpnKAzGzLDyrmirg7oHZZ0n8czP080063VaCeHH0D0EBFT/SxMhvQCCaSh652Q82JiiD/c88XT6kpyBLvsDB+QOFEQGKxnVhmqeQv6A/SmGzBbH8d6dPD9mdYkC3FdvC0RB0F3bifPVUOkC3Guc9hEa1f8eYlzJl0D0K0H3Eoi7fBcrQNd7rgW6X+RJBPYPtYNCJdjkjSxyCk5CJJJKFtuL2EuZL6F/XoNpgQYVBl0dJncAOWmKSFQeQk798Ns8HJ0sn0/+jCqz7D8qxlTTK73K+6iWJ5u61myovw6yJyp8upUT/3TTVHqM2RjLTyL1pnpskGREbnfV5OX2OtCGRVoGZroy+tE3s97ylZixnsSXqpFsMtO/V+WquHP4= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 358ec5f3-c2eb-4b31-cdff-08d7f1dfd312 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 17:06:31.5621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: f+y4bTOfhJqzzbdPXkFc7fZC1sLLEKlkAIs2TDLIEK32McFwjsZ+nQbEOgLmTdzN X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2869 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-ospf-mpls-elc-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 17:07:05 -0000 SGkgUGV0ZXIsIERocnV2LA0KDQrvu79PbiA1LzYvMjAsIDEyOjAwIFBNLCAiUGV0ZXIgUHNlbmFr IiA8cHBzZW5ha0BjaXNjby5jb20+IHdyb3RlOg0KDQogICAgSGkgRGhydXYsDQoNCiAgICBwbGVh c2Ugc2VlIGlubGluZToNCg0KICAgIE9uIDA2LzA1LzIwMjAgMTc6NDAsIERocnV2IERob2R5IHdy b3RlOg0KICAgID4gSGkgUGV0ZXIsDQogICAgPiANCiAgICA+IFRoYW5rcyBmb3IgeW91ciByZXBs eSwgc25pcHBpbmcgdG8gcG9pbnRzIHRoYXQgbmVlZCBmdXJ0aGVyIGRpc2N1c3Npb24uLi4NCiAg ICA+IA0KICAgID4+IFdoYXQgYWJvdXQ6DQogICAgPj4NCiAgICA+PiBTZWdtZW50IFJvdXRpbmcg d2l0aCB0aGUgTVBMUyBEYXRhIFBsYW5lIHJlbGllcyBvbiBJbnRlcmlvciBHYXRld2F5DQogICAg Pj4gUHJvdG9jb2xzIChJR1ApIHN1Y2ggYXMgT1NQRnYyIFtSRkM4NjY1XSBhbmQgT1NQRnYzIFtS RkM4NjY2XSB0byBzaWduYWwNCiAgICA+PiBsYWJlbHMuDQogICAgPj4NCiAgICA+IA0KICAgID4g TXVjaCBiZXR0ZXIuDQogICAgPiANCiAgICA+IA0KICAgID4+PiAoMykgU2VjdGlvbiA0DQogICAg Pj4+DQogICAgPj4+ICAgICAgVGhlIGFic2VuY2Ugb2YgRVJMRC1NU0QgYWR2ZXJ0aXNlbWVudHMg aW5kaWNhdGVzIG9ubHkgdGhhdCB0aGUNCiAgICA+Pj4gICAgICBhZHZlcnRpc2luZyBub2RlIGRv ZXMgbm90IHN1cHBvcnQgYWR2ZXJ0aXNlbWVudCBvZiB0aGlzIGNhcGFiaWxpdHkuDQogICAgPj4+ DQogICAgPj4+ICAgICAgRG8geW91IG1lYW4gdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHN1cHBv cnQgZm9yIHRoZSBjYXBhYmlsaXR5IGl0c2VsZiB2L3MNCiAgICA+Pj4gICAgICBzdXBwb3J0IGZv ciAnYWR2ZXJ0aXNlbWVudCcgb25seS4gQnV0IFJGQyA4NjYyIHNheXMgdGhhdCBFUkxEIHZhbHVl IGlzDQogICAgPj4+ICAgICAgYWR2ZXJ0aXNlZCBvbmx5IHdoZW4gZm9sbG93aW5nIGNvbmRpdGlv bnMgYXJlIG1ldDoNCiAgICA+Pg0KICAgID4+IFdoYXQgaXMgbWVhbnQgaXMgdGhhdCBldmVuIHRo b3VnaCBhbGwgdGhlIGJlbG93IGNvbmRpdGlvbnMgYXJlIHNldCwgaWYNCiAgICA+PiB0aGUgbm9k ZSBkb2VzIG5vdCBzdXBwb3J0IHRoZSBhZHZlcnRpc2VtZW50LCBvbmUgY2FuIG5vdCBjb25jbHVk ZSB3aGF0DQogICAgPj4gaXRzIEVSTEQgaXMuDQogICAgPj4NCiAgICA+PiBJZiB0aGUgbm9kZSBz dXBwb3J0cyB0aGUgYWR2ZXJ0aXNlbWVudCBvZiB0aGUgRVJMRCwgYnV0IHRoZSBiZWxvdw0KICAg ID4+IGNvbmRpdGlvbnMgYXJlIG5vdCBtZXQsIHRoZSBub2RlIHNob3VsZCBub3QgYWR2ZXJ0aXNl IHRoZSBFTEMgY2FwYWJpbGl0eQ0KICAgID4+IGluIGEgZmlyc3QgcGxhY2UuDQogICAgPj4NCiAg ICA+IA0KICAgID4gVGhlcmUgYXJlIHR3byB0aGluZ3MgaGVyZSAtIChhKSB0aGUgYWN0dWFsIGxv YWQgYmFsYW5jaW5nIGNhcGFiaWxpdHkNCiAgICA+IG9mIGEgbm9kZSAoYikgdGhlIGNhcGFiaWxp dHkgdG8gYWR2ZXJ0aXNlIHRoZSBFTEMvRVJMRC4gVXN1YWxseQ0KICAgID4gY2FwYWJpbGl0eSBh bmQgdGhlIGFkdmVydGlzZW1lbnQgb2YgdGhlIGNhcGFiaWxpdHkgZ28gdG9nZXRoZXIuIEluDQog ICAgPiB0aGlzIGNhc2Ugd2Ugd2FudCB0byBiZSBleHBsaWNpdCB0aGF0IHRoZSBhYnNlbmNlIG9m IEVSTEQtTVNEDQogICAgPiBpbmRpY2F0ZXMganVzdCAoYikgYW5kIG5vdCAoYSkuDQogICAgPiAN CiAgICA+IFlvdSBkbyB1c2UgdGhlIHdvcmQgIm9ubHkiLCBzbyBtYXkgaXRzIGFsbCBmaW5lISBJ IHdpbGwgbGVhdmUgaXQgdG8NCiAgICA+IHlvdS9zaGVwaGVyZC4NCg0KICAgIHllcywgdGhlIGFi c2VuY2Ugb2YgRVJMRC1NU0QgYWR2ZXJ0aXNlbWVudHMgb25seSBpbmRpY2F0ZXMgdGhhdCBhIG5v ZGUgDQogICAgZG9lcyBub3Qgc3VwcG9ydCBhZHZlcnRpc2VtZW50IG9mIChiKS4NCg0KICAgIEl0 IGNhbiBub3QgYmUgaW50ZXJwcmV0ZWQgdGhhdCAoYikgaXMgbm90IHN1cHBvcnRlZC4gIE9sZCBu b2RlcyB0aGF0IGRvIA0KICAgIG5vdCBhZHZlcnRpc2UgRVJMRC1NU0QgY2FuIG5vdCBiZSBhc3N1 bWVkIG5vdCB0byBzdXBwb3J0IG5vbi16ZXJvIEVSTEQuDQoNCiAgICBUaGUgIm9ubHkiIGlzIHRo ZXJlIHRvIGV4cHJlc3MgdGhlIGFib3ZlLg0KDQpBcyBkb2N1bWVudCBzaGVwaGVyZCwgSSB0aGlu ayB0aGlzIGFsaWducyB3aXRoIG90aGVyIE9TUEYgZnVuY3Rpb25hbCBjYXBhYmlsaXRpZXMuDQoN ClRoYW5rcywNCkFjZWUNCg0KICAgID4gDQogICAgPj4+DQogICAgPj4+ICAgICAgKiAgTVVTVCBi ZSBlbnRyb3B5IGxhYmVsIGNhcGFibGUgYW5kLCBhcyBhIGNvbnNlcXVlbmNlLCBNVVNUIGFwcGx5 DQogICAgPj4+ICAgICAgICAgdGhlIGRhdGEtcGxhbmUgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFtS RkM2NzkwXS4NCiAgICA+Pj4NCiAgICA+Pj4gICAgICAqICBNVVNUIGJlIGFibGUgdG8gcmVhZCBh biBFTEkvRUwsIHdoaWNoIGlzIGxvY2F0ZWQgd2l0aGluIGl0cyBFUkxEDQogICAgPj4+ICAgICAg ICAgdmFsdWUuDQogICAgPj4+DQogICAgPj4+ICAgICAgKiAgTVVTVCB0YWtlIGludG8gYWNjb3Vu dCBhbiBFTCB3aXRoaW4gdGhlIGZpcnN0IEVSTEQgbGFiZWxzIGluIGl0cw0KICAgID4+PiAgICAg ICAgIGxvYWQtYmFsYW5jaW5nIGZ1bmN0aW9uLg0KICAgID4+Pg0KICAgID4+PiAgICAgIFRodXMs IEkgYW0gbm90IHN1cmUgYWJvdXQgdGhpcyBzZW50ZW5jZS4gTWF5YmUgeW91IG1lYW4gdG8gc2F5 IHRoYXQgdGhlDQogICAgPj4+ICAgICAgYWJzZW5jZSBvbmx5IGluZGljYXRlcyB0aGF0IHRoZSBF UkxELU1TRCB2YWx1ZSBvZiB0aGUgbm9kZSBpcyB1bmtub3duIChhbmQNCiAgICA+Pj4gICAgICBp dCBtaWdodCBzdGlsbCBiZSBjYXBhYmxlIG9mIGhhbmRsaW5nIEVMSS9FTCk/DQogICAgPj4+DQog ICAgPj4+ICg0KSBTZWN0aW9uIDQNCiAgICA+Pj4NCiAgICA+Pj4gICAgICAgV2hhdCB3b3VsZCBi ZSB0aGUgYmVoYXZpb3IgaWYgYW4gT1NQRiByb3V0ZXIgcmVjZWl2ZXMgYSBFUkxEIG9mIHRoZSBu b2RlDQogICAgPj4+ICAgICAgIGJ1dCBubyBFTEMgc2V0IGZvciB0aGUgY29ycmVzcG9uZGluZyBw cmVmaXg/IFRoYXQgd291bGQgYmUgYW4gZXJyb3IgYXMgcGVyDQogICAgPj4+ICAgICAgIFJGQyA4 NjYyLCB3ZSBzaG91bGQgc3BlY2lmeSBob3cgb25lIGhhbmRsZXMgaXQgd2l0aGluIE9TUEYuIElm IGl0IGlzIHRvDQogICAgPj4+ICAgICAgIGp1c3QgaWdub3JlIHRoZSBFUkxELCB3ZSBzaG91bGQg ZXhwbGljaXRseSBzYXkgdGhhdC4NCiAgICA+Pg0KICAgID4+IHRoZSBiZWhhdmlvciBpcyBzcGVj aWZpZWQgaW4gdGhlIFJGQyA4NjYyLiAgT1NQRiBpcyBqdXN0IGEgbWVzc2VuZ2VyLA0KICAgID4+ IG5vdCB0aGUgY29uc3VtZXIgb2YgdGhpcyBpbmZvcm1hdGlvbi4NCiAgICA+Pg0KICAgID4gDQog ICAgPiBJcyB0aGVyZSBzb21lIHRleHQgaW4gUkZDIDg2NjIgdGhlIGNsYXJpZnkgd2hhdCBvbmUg ZG9lcyBvbiB0aGUNCiAgICA+IHJlY2VpdmluZyBzaWRlPyBJIGZvdW5kIG9ubHkgdGhlIHNlbmRp bmcgY29uZGl0aW9ucyBpbiBzZWN0aW9uIDQuIEhvdw0KICAgID4gZG9lcyBhIHJlY2VpdmluZyBu b2RlIGJlaGF2ZXMgd2hlbiBoZSByZWNlaXZlcyBjb25mbGljdGluZw0KICAgID4gaW5mb3JtYXRp b24sIHdoaWNoIG9uZSBkb2VzIGhlIHRydXN0IChubyBFTEMgcHJlc2VudCBvciBFUkxEPTEwKS4g V2UNCiAgICA+IGNvdWxkIGhhdmUgaW50ZXJvcCBpc3N1ZXMgaGVyZSBpZiB5b3UgbGVhdmUgaXQg b3Blbi4NCg0KICAgIHdlbGwsIGlmIHRoZSBub2RlIGRvZXMgbm90IHN1cHBvcnQgRUxDLCB0aGVu IEVSTEQgdmFsdWUgaXMgaXJyZWxldmFudC4gDQogICAgSXQncyBsaWtlIGhhdmluZyBhIHNwZWVk IGxpbWl0IGZvciBhIHJvYWQgd2l0aCBubyBlbnRyeS4NCg0KICAgIEJ1dCB0aGF0IGlzIHNvbWV0 aGluZyB0aGF0IGRvZXMgbm90IGJlbG9uZyB0byBwcm90b2NvbCBkcmFmdHMuDQoNCiAgICB0aGFu a3MsDQogICAgUGV0ZXINCg0KDQogICAgPiANCiAgICA+IFRoYW5rcyENCiAgICA+IERocnV2DQog ICAgPiANCiAgICA+IFBTLiBTaW5jZSB0aGUgY29tbWVudHMgYXJlIHRoZSBzYW1lIGZvciB0aGUg SVMtSVMgSS1ELCBubyBuZWVkIGR1cGxpY2F0ZSB0aGVtLg0KICAgID4gDQogICAgPiANCg0KDQo= From nobody Fri May 29 06:40:04 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E153A0890; Fri, 29 May 2020 06:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtZ7h5bQRFdI; Fri, 29 May 2020 06:39:56 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 4D5213A08E0; Fri, 29 May 2020 06:39:50 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04TDdlwc015231; Fri, 29 May 2020 14:39:47 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B81682203D; Fri, 29 May 2020 14:39:47 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id A2B5F2203A; Fri, 29 May 2020 14:39:47 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.26.18]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04TDdjvj007060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 May 2020 14:39:46 +0100 Reply-To: From: "Adrian Farrel" To: "'Ravi Singh'" Cc: , , , References: In-Reply-To: Date: Fri, 29 May 2020 14:39:44 +0100 Organization: Old Dog Consulting Message-ID: <0a4d01d635be$9e7fead0$db7fc070$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJN+mPvT/S0d6n8s20SG6yVaurrtAIWjz82p76ws2A= Content-Language: en-gb X-Originating-IP: 84.93.26.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25450.000 X-TM-AS-Result: No--23.916-10.0-31-10 X-imss-scan-details: No--23.916-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25450.000 X-TMASE-Result: 10--23.916300-10.000000 X-TMASE-MatchedRID: 8HTFlOrbAtGWfDtBOz4q23FPUrVDm6jtekMgTOQbVFunRvssirgAK4HS 4pClWCHaqTwejd89lyUbct6MEzra/k2QemvwGK9xXK5keCa+bmgiJN3aXuV/oeCAU8+z4gBp/YE WsVmY7ljCAN9p1+Py/GNQNBwI/n1biEkdc/08TTtfYa9W9OjitfL75LLJV7i34PdcWsl+C/MLSp fHJmkMSPfwUF8qFUNkxEQg7sZ4fWRcqVSRZoerC1HmrymVJ0uQGf83J4WEtBrfUZT83lbkEF3tA 9cAnnWiQI1Rqag4eBe4MX00XBi8DTbG3Iwaob+3U+OjsPhIWDi0em6xcBVoDG0emrRhsFGLItL8 M7QRoxebdWCZpxm2yA0+1+6s0LvECFXSZY9QCJ7+QWP7vm29DEYj0zDHPzJpAv57j5eT9BbD9iR j9LIMxoutFpuqtFV1UBcRhWv4R8v7zwy3HB5+4lLFinzH90WnAf1C358hdK/6eV5+LAaaX3oxrY h0t9W0YTwhgP3ff8BnsfH7gHyyBa91xPCrfpdCi+quUbDYb+QCC8zqHvcG2lprdarlcWiXfQ28T 7selJzT0Tn7UCcn8NnzQr3PhcFzcVmC618GpbYHK0IhbYfex+PkHDKOeJ04O7BMOlfyKLRJcBXv KYkUg0Yk0bRdGD3CfeQ+GGxn9tp1D+JCCIGrIy289eFksaeRG08M2I9s0LoOUs4CTUgKy9OsOe6 5m68WuuPQ0YIe33nJ2QyrYOuZrxUNZg0yiKBRoprTEHvewAArU8f3oY88YJaSFUyM7s8kSgJUJz MDnBnJMHGad1girx3J+ShEXveNoxHeC5nrmwWeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1bxAi7jPoeEQftwZ3X11IV0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bess-nsh-bgp-control-plane-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 13:39:59 -0000 Hi Ravi, Thanks for a thorough and useful review. Responses in line=E2=80=A6 > Summary: > I have some minor concerns about this document that I think should be = resolved before publication. Doing so in -14 > Minor issues: > > Section2: During an initial reading, the terminology comes across as = overly repetitive > and a bit pedantic=E2=80=A6.which takes away from the readability a = bit when one is reading > the sections in the order listed. Content of RFC7665/8300 are also = contributors to this. > Eg: "In fact, each SI is mapped to one or more SFs that are = implemented by one or > more Service Function Instances (SFIs) that support those specified = SFs. " : almost > sounds like legalese when someone who has not grasped the complete = picture of > the draft. > > Wrote up the above as I was reading that section for the first time. > However, after finishing the review=E2=80=A6started to appreciate = this. We've changed this to... Within the context of a specific SFP, an SI references a set of one or = more SFs. Each of those SFs may be supported by one or more Service Function Instances = (SFIs). ...although we are slightly worried that we may have lost some = precision. > In having read the sections in order, I think the readability would = have been=20 > greatly enhanced if I had read section 8 first, else once just gets = lost in all the details. > It would be worthwhile suggesting in the text that once the reader has = read through > section 2, it would help to read section 8 before reviewing the = intervening sections. > > [JD] Fine w/ me=20 =20 We have put in the forward pointer. > 2. Section 3.2.1: page 16: > "[RFC7606] > revises BGP error handling specifically for the for UPDATE message," >=20 > -> > "[RFC7606] > revises BGP error handling specifically for the UPDATE = message,=E2=80=9D Ack > 3. Page 17: > a. Was the intention for treating error 4 any different from errors, = [1,2,6,7]? > If not, why the need to call out 4 separately? 4 should be treated the same as 1, 2, 6, and 7=20 Fixed > b. "Unknown SFIR-RD found in a Hop TLV." : > The format of the Hop TLV in section 3.2.1.2 contains no reference to = an > RD. So, was the intention instead to refer to the SFIR-RD list of one = of the > SFT TLVs inside the Hop TLV? 8 should be =E2=80=9CUnknown SFIR-RD found in an SFT TLV=E2=80=9D=20 > 4. > Section 3.2.1.2: "At least one sub-TLV MUST be present. " > Where are these sub-TLVs defined? > In this regard, > a. Section 3.2.1.3 says "The SFT TLV MAY be included in the list of = sub-TLVs > of the Hop TLV.": > b. Section 3.2.1.4 says "The MPLS Swapping/Stacking TLV (Type value = 4) is a=20 > zero length sub-TLV that is OPTIONAL in the Hop TLV " > > In the absence of specific mention of details of sub-TLVs in section = 3.2.1.2, > is a reader to assume that SFT TLVs & the MPLS swap/stack TVLs are the > only possible subTLVs under a hop-TLV (as intended in this revision of = the > ID)? > This aspect becomes clear later, when one gets to reading the = description > of the subsequently mentioned TLVs. Might be worth alluding to this in = 3.2.1.2. 3.2.1.2 now reads "At least one sub-TLV MUST be present. This document defines the SFT = Sub-TLV (see Section 3.2.1.3) and the MPLS Swapping/Stacking Sub-TLV = (see Section 3.2.1.4): other sub-TLVs may be defined in future." > 5. >"In the normal case the SPI remains unchanged and the SI will have been = > decremented to indicate the next SF along the path.": will SI really = be > decremented instead of just setting it to the appropriate value? As = per > this draft, set to an appropriate lower value=E2=80=A6 Contemplated changing this to... =E2=80=9Cand the SI set to the value for the next hop in the = SFP=E2=80=9D. However, in discussion way back, the SFC WG was pretty adamant about = using the term "decremented" and we would like to remain consistent with = their usage. > 6. > What exactly does the following mean? "Also, as described in = [RFC8300], > an SFF receiving an SI that is unknown in the context of the SPI can = reduce > the value to the next meaningful SI value in the SFP indicated by the = SPI. > If no such value exists or if the SFF does not support this function, = the SFF > drops the packet and should log the event: such logs are also subject = to > rate limits." s/this function/reducing the SI/ > 7.=20 > Figure 1: showing the SFIs hosted on SFF2 and SFF3 in the same > conceptual block (just because they share the same type) is a bit > confusing when the diagram is showing a logical view of the physical > layout of the elements of the solution. We re-read the associated text and thought it was clear.=20 The blocking is not "just because they share the same type" but is = indicative of them sharing the same type. > 8. > Section 3.1:the following is an ambiguous sentence & I suggest > rewording to clarify: > "Note that it is assumed that each SFF has one or more globally > unique SFC Context Labels and that the context label space and > the SPI address space are disjoint."=20 > This sounds like that the "context label space" and the "SPI > address space" are disjoint w.r.t. each other. What appears to > be intended is that the SFC context labels and SPI-address-space > should be disjoint across the different SFFs. > However, is it not sufficient to just have the SFC-context label > spaces be disjoint across SFFs? Within a given VPN, the set of SPIs is unique as is the set of SFC = Context Labels. When an SFF receives a packet it needs to know whether = the topmost label is an SPI value or an SFC context label. Hence the = two sets of labels need to be disjoint.=20 We have include a little extra clarity as the result of an IESG comment = to arrive at... Note that it is assumed that each SFF has one or more globally unique = SFC Context Labels and that the context label space and the SPI address = space are disjoint (i.e., a label value cannot be used both to indicate = an SFC context and an SPI, and it can be determined from knowledge of = the label spaces whether a label indicates an SFC context or an SPI). > 9. > Section 3.2: Why is "If two SFPRs are originated from different = Controllers > they MUST have different RDs" needed when "All SFPs MUST be associated > with different RDs." is already stated? It may be too subtle, but, there is a difference between SFPR and SFP in = the quoted text. Consider two controllers that both want to announce the = same SFP. However, even discarding this subtlety, the worst is that there is an = over-statement of the rule. > 10. > Section 3.2.1: "The Extended Length bit is set according to the length = of > the SFP attribute as defined in [RFC4271].": minor quibble: but this=20 > sentence needs rewording for correctness of intended meaning. Oh well, maybe. Or maybe not =F0=9F=98=8A How about,=20 "The Extended Length bit is set if the length of the SFP attribute is = encoded in one octet (set to 0) or two octets (set to 1) as described in = [RFC4271]." > 11. > Pg26: Typo in "This makes the bevahior " Ack > 12. > Section 5: pg 29: suggest rewording "Thus, at any point in time when > an SFF selects its next hop, it chooses from the intersection of the = set > of next hop RDs contained in the SFPR and the RDs contained in its = local > set of SFIRs." to > "Thus, at any point in time when an SFF selects its next hop, it = chooses > from the intersection of the set of next hop RDs contained in the SFPR = > and the RDs contained in the SFPR's local set of SFIRs." It is the set of SFIRs local to the SFF the we care about. We can make = that clearer. > 13. > Section 5 pg 29: Not clear "Similarly, when this condition obtains" > what is intended here? You weren't the first person to query our (correct) use of "obtains". We have s/obtains the originator of the SFPR /applies on the controller = that originated the SFPR,/ > 14. > Section 6: typo in "If the SPI indicates anther path," Ack > 15. > Section 6.1: SI (As defined in SFIR format in section 3.1) is a 1 = octet > quantity. So, want to make the SI field 1 byte long and the reserved > field 4 bytes long? Yes, that was a legacy thing that got missed. Thanks. Fixed. > 16. > Section 6.1: "Note that Special Purpose SFTs MUST NOT be advertised > in SFIRs.": what is the intended behavior if these were so advertised? Added =E2=80=9CIf such an SFIR is received it SHOULD be = ignored.=E2=80=9D > 17. > Section 7.4: "that can be used to disposition those packets" and "it=20 > MUST NOT be used for dispositioning the packets of the specified" > feels a little strange: perhaps the RFC-editor will have more to say > about this, if this really is strange The term =E2=80=98disposition=E2=80=99 was introduced in the EVPN RFCs. = It=E2=80=99s used as a single term to describe a multiplicity of possible actions. If the RPC barfs we'll conjure a new word. > 18. > Section 7.6: "with that SFP=E2=80=99 last hop." -> "with that = SFP=E2=80=99s last hop." Ack > 19. > Section 8.4: "path selecting between all SFF2 that support an SF of > type 43 and SFF3 that supports" could use some rewording. s/2/s/ > 20. > Section 8.7: "[SI =3D 245, SFT =3D 42, RD =3D 192.0.2.3:7]" could be = made > more in line with the encoding, by showing it as [SFT =3D 42,=20 > RD =3D 192.0.2.3:7] with the SI=3D245 being nested under [SI=3D245, = =E2=80=A6] > on the lines of as is done in section 8.4. Yes > 21. > > Section 8.9.2: what is gained by having a given SFI be identified = using > multiple different SI s? > Eg: > [SI =3D 255, SFT =3D 41, RD =3D 192.0.2.1:11], > And > [SI =3D 253, SFT =3D 41, RD =3D 192.0.2.1:11] > > The above 2 representations are for the same SFI: i.e. SFT & RD are = the > same. So, why represent them using different SI s? > This ties to the question about: why worry about the numeric ordering > of the SI values in a given SFP? I looked through 8.9.2 carefully. Within any one SFP, I don't see the = same SFI identified more than once. In different SFPs, the change in SI for the same SFI reflects a = different ordering. You need that different ordering for the reverse direction SFPs. Best, Adrian From nobody Fri May 29 09:18:12 2020 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B683A0D82; Fri, 29 May 2020 09:18:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Daniele Ceccarelli via Datatracker To: Cc: last-call@ietf.org, lsr@ietf.org, draft-ietf-ospf-te-link-attr-reuse.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159076909169.565.534138764890157419@ietfa.amsl.com> Reply-To: Daniele Ceccarelli Date: Fri, 29 May 2020 09:18:11 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-ospf-te-link-attr-reuse-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 16:18:12 -0000 Reviewer: Daniele Ceccarelli Review result: Has Nits Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ospf-te-link-attr-reuse-12 Reviewer: Daniele Ceccarelli Review Date: 2020-05-29 IETF LC End Date: date-if-known Intended Status: Standard Track Summary: The readibility of the draft has been significantly improved since my last review (v07), mostly the abstract and the introduction, which now cleary state what is the scope of the draft. I also appreciated the introduction of section 3 where a description of the existing solution is described. Minor issues: - Section 4.1 - Advantages with respect to RSVP-TE are described while the text speaks about advantages with respect to RSVP-TE and GMPLS, probably it could be changed into: advantages with respect to RSVP-TE when used in packet networks and in GMPLS, something like this. - Section 5 - Why for the UDABM it doens't say the value MUST be 0,4,8 but rather says "the legal values are" ? Is 8 octets future-proof enough? or conversely, if only 3 values are defined why do we need 8 octects as option? - Section 8 - I really find it hard to understand this small section. Typos: - Unidirectional Link Dela [RFC7471] From nobody Fri May 29 10:17:51 2020 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C033A0E5A; Fri, 29 May 2020 10:17:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Bruno Decraene via Datatracker To: Cc: last-call@ietf.org, draft-ietf-isis-te-app.all@ietf.org, lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159077265555.16212.13520780610035572236@ietfa.amsl.com> Reply-To: Bruno Decraene Date: Fri, 29 May 2020 10:17:35 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-isis-te-app-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 17:17:43 -0000 Reviewer: Bruno Decraene Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-isis-te-app-13 Reviewer: Bruno Decraene Review Date: 2020-05-29 IETF LC End Date: 2020-05-29 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Draft is clear. Minor Issues: §4.1 *2 (for SABM & UDABM fields) OLD: The length SHOULD be the minimum required to send all bits which are set. I'd propose NEW: The length SHOULD be the minimum required to send all the meaningful bits which are set. Motivation; the 'bits which are sent' are the bits in the SABM field. (they do include non-meaningful and padding bits) ---- OLD: Undefined bits MUST be transmitted as 0 NEW: Undefined transmitted bits MUST be cleared (0) Motivation: currently the number of undefined bits is 8*8-3. They SHOULD not be transmitted (beyond the first ones fitting in the first N required octet). The sentence "Undefined bits MUST be transmitted as 0" could be read as all defined bits MUST be transmitted (as 0). --- User Defined Application Identifier Bits have no name. I'd propose to call them UDABM[0], UDABM[1]... This may avoid that different implementation use different names and, more problematic, that some implementations starting with 1 (the first, the second) while while some other implementations starts as 0, creating interop issues (SABM[1] on node A is SABM[0] on node B) --- §4.2 "In cases where conflicting values for the same application/attribute/link are advertised all the conflicting values MUST be ignored." I'd propose to add "for this application" (IOW, those values are still applicable for all other applications) --- §6.2 I'd argue that the first part of section 3.2 is a specification of the behavior and hence should be moved to section 4.1, rather than placed in the section "deployment consideration" which eventually will not be read by someone implementing the specification. Especially since the text in section 4.1 implies a different behavior: "Bits that are NOT transmitted MUST be treated as if they are set to 0 on receipt." --- §5 "In the case of SRTE, advertisement of application specific link attributes does NOT indicate enablement of SRTE." What does "enablement of SRTE" means? Do you have a pointer to a document/text? I'm not sure I would keep that paragraph on SR-TE enablement. --- §6.1 "Under the conditions defined above, implementations which support the extensions defined in this document have the choice of using legacy advertisements or application specific advertisements in support of SRTE and/or LFA. This will require implementations to provide controls specifying which type of advertisements are to be sent/ processed on receive for these applications." I think that "have the choice" is not prescriptive enough given the deployment issues described in section 6.3 I'd rather say that implementations MUST support the use of both advertisements (legacy and application specific advertisement) and MUST provide controls specifying which type of advertisements are to be processed on receive for these applications. From nobody Fri May 29 15:08:48 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC2F3A10E3; Fri, 29 May 2020 15:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YPOe48oa; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WyJK0Sx4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lHKMShoJTrA; Fri, 29 May 2020 15:08:37 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9768E3A10DE; Fri, 29 May 2020 15:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10896; q=dns/txt; s=iport; t=1590790117; x=1591999717; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JO4mJqZE19nQvjxWgiar9bPah0z4TCizes/V9OkgaFQ=; b=YPOe48oaGqeh3mdHHUFQ/BFL33KshE3yV2PU7P1KubrgWgBcOyg97oaO 12gpFKNX8S6kNTNds7oknifN2uSL6P8y7mdWRe2WFFi52F+bus/GV5PE0 mawedHO5rbggtjqM8W30EjUbww1m6UytmQ+z3GifwQh8sf9Wj4c52xNvj o=; IronPort-PHdr: =?us-ascii?q?9a23=3AC5yOnRG03KIbBpwbYVdUn51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QGbWp/S7f1JzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX5fVTUrXD05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAAB1htFe/4wNJK1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIE5AgEBAQELAYFPUgdvWC8shCWDRgONQJh?= =?us-ascii?q?JglIDVQsBAQEMAQEjCgIEAQGERAIXggsCJDcGDgIDAQELAQEFAQEBAgEGBG2?= =?us-ascii?q?FWQyFcgEBAQECARIREQwBATAHAQQHBAIBCBEDAQEBAwImAgICMBUICAIEAQ0?= =?us-ascii?q?FCBqDBYJLAw4gAQ6mDQKBOYhhdoEygwEBAQWFCxiCDgmBDioBgmOCSQ+HCRq?= =?us-ascii?q?BQT+BEAFDgk0+glwLAoFnFQ+CbjOCLY5Agy+GTJoNfwqCVIgxi1+EeYJmgRS?= =?us-ascii?q?HcoUNjRuQXYlzj2qEEwIEAgQFAg4BAQWBaSOBVnAVgyQJRxcCDZBAg3KFFIV?= =?us-ascii?q?CdAI1AgYBBwEBAwl8jFsBAQ?= X-IronPort-AV: E=Sophos;i="5.73,450,1583193600"; d="scan'208";a="774327077" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 May 2020 22:08:36 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 04TM8aKE016944 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 May 2020 22:08:36 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 29 May 2020 17:08:36 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 29 May 2020 18:08:34 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 29 May 2020 17:08:34 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SGjpYUIE8Td9iEPx+q+YthhE6yUVGVwyB+Acp0LIEMZqQ2slLB22IyjBYkBxbvkcUxiZb61rFMjDbGeBqEd1yB+e6Kdm3y7cCr1y9bk05mGCCBFCHMLe0mHF5R1G+1ZYEVYQzIyPjdV5kB1hQj6zK/nxOrjD9asPeQNV6W6kkLdg7SsAoBDZEExqRsakNMQwrvzwtH/2ylOvX6YDf0wP9ulSt+j4fXHVrK2Eo9NzR1ceoaIuZU6sTJWwSZLaTA2lKilqspQxNy8ANMgoZ/PCvp16Q69UVl8MDJsvJsdcGZJGaoUdNSGQc1RCrFziu1wh87eQG4lTmWpZzNsHMjfePQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JO4mJqZE19nQvjxWgiar9bPah0z4TCizes/V9OkgaFQ=; b=bM7KpKi0nIcy0RtSWiFxH/tHF8+BEwiAAFo0DUkRhXUlfCOprlmUvvcSeqvh22kLV0OKeb+s3l4gTOlHbZtP+LUTF5L/9i7fgxq7rv1+JbKUKLiw0MB708YIXPCPyob5tCI9kJylwBtHW1nBosIv3NJj3OaZhgT6niX4pAT3VOcbNJ+Mnd7GgXPLjXNkJLRdrzku50QynX12Y9iZpS51STL1nYE4nU9kmxKTBZnAa/IkbzBsQfGNH63o+N4cLQ97EDMhRorWMhWjlY1uRkzDf5dQariWitPwRfjZSVHVoiBkZsISjz/rq8GR747aB6kqYeNkV+daUbnpsksAlak2yQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JO4mJqZE19nQvjxWgiar9bPah0z4TCizes/V9OkgaFQ=; b=WyJK0Sx4HVzmA65yv3iNf5hieHhQqAtIQ07L9z/yrym15jobSkLHewEblvXSkeGUpL7fgNzJvTbpGGgaYJYBjSwDnfVbOnPcH/iNIx2WkKOjCsfXJq2pDHfytNK5sRvuDoKumfHfWAdJ5f0qeYOFjF13/DFgS3S0dX8+GX6NdfY= Received: from MW3PR11MB4619.namprd11.prod.outlook.com (2603:10b6:303:5b::15) by MW3PR11MB4537.namprd11.prod.outlook.com (2603:10b6:303:5d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17; Fri, 29 May 2020 22:08:33 +0000 Received: from MW3PR11MB4619.namprd11.prod.outlook.com ([fe80::c4d2:505c:a6bf:21a6]) by MW3PR11MB4619.namprd11.prod.outlook.com ([fe80::c4d2:505c:a6bf:21a6%7]) with mapi id 15.20.3045.018; Fri, 29 May 2020 22:08:33 +0000 From: "Les Ginsberg (ginsberg)" To: Bruno Decraene , "rtg-dir@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-isis-te-app.all@ietf.org" , "lsr@ietf.org" Thread-Topic: Rtgdir last call review of draft-ietf-isis-te-app-13 Thread-Index: AQHWNd0WaS4VumZOYEK75VTP+jj6Sqi/ifXQ Date: Fri, 29 May 2020 22:08:33 +0000 Message-ID: References: <159077265555.16212.13520780610035572236@ietfa.amsl.com> In-Reply-To: <159077265555.16212.13520780610035572236@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2602:306:36ca:6640:11de:d064:36a4:d951] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b3bbca42-3f41-4f80-c348-08d8041cd422 x-ms-traffictypediagnostic: MW3PR11MB4537: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04180B6720 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4u8EQt3qLGnPrAy0O3muqG1spzt5Nt1/sShOGFKaFXTHa9cg7dqbvyPk1TavRPhlytLYR5/0oLf5Bx03BPEeN62GazvWpRVAfrL4zFbn+paRHPhG4QwoGzguiJdGzjfKkkpsBhZ+gCgmflATToieFdi/tfThZjX4aypzd0Xax1TCqc7tuZAnEjC6RhN8qlM4psJZy2m1isX5pM0gP7sf6Zg/ulVuhRvXMbidUQjPpA19E3xqGc8NGTmVx3o0uD2ttoySS2Z3oHj5GvtgC8JhSSmYO+zC/9Wm/cZiGrEnVv3axg+ANBE7EuXyzsq1XtQiLfkuc6u+qHT21BJRHOlw2ELLZ4osrYI6jFr+T96gOVeAfwaXuesD08xl/7uSW50OXs73Awxvis+9QpYh90q/fg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4619.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(346002)(396003)(376002)(136003)(54906003)(66946007)(316002)(7696005)(6506007)(186003)(71200400001)(5660300002)(53546011)(33656002)(110136005)(8676002)(8936002)(2906002)(4326008)(52536014)(478600001)(66446008)(66556008)(66476007)(64756008)(76116006)(86362001)(83380400001)(55016002)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: h2hmV6sR2f2zKlEiiOCZAlHdxEAjroRfC95y6Nte+nail6dwZoPmwz0edqL4zR2Qee8rHKbQ5jvuLgSsIpgrwVML88/QiGC0Pp1nmPl6bPHZZ/ehKmicHU1JWZbdK2Bp+X49P22VJK5J59XgYh5nvU8s/cqHzq+PeTrD2ASY/+L27ZvQGiYwHZ/0BUwihU+x6B7aARB8h7a74tJ3P7jUa22AIC/u3Ua60axXD0memOh8jEONs3q99FuGHbtHSIHXn6lG2GdxOKJTVmtbskSzadSV+uXJiQw6pnY/ZwdHn9Wc7eoInTQWanYk3P/SV4MpEFK9t+5JHTo1gf5BB82CElFk92Z1uNkyO1J8ATsQ2DUY/qlFo1dDmsdJ2V+GRCZBSWRqoWU9wznHvKljpSHbQlib7ZYMUIWEQ0NI3NQpXF0W0lFul8cA4N8xSiui5o9a1FvQk3atR7XHuFSS8B/Ktt+eHlJLXHqwl9yCQlxn/FQ8C5fLVvXwwg4t6vQ+3VjROiwLV1HMorz/bMGiNF0pi0FUHriQTn+gljgyu6PJUA4dSy7Rx8PMLLeBRxozhFMh x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b3bbca42-3f41-4f80-c348-08d8041cd422 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2020 22:08:33.5796 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fUMaUTNToa2aatwiVN+Q3vx5A17wSkjZsanAnChsYrdXI0CXD3S8bQg7dYssP77azP7lj7obMAn3aEbdRnDSMA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4537 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-isis-te-app-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 22:08:40 -0000 QnJ1bm8gLQ0KDQpUaGFueCBmb3IgeW91ciAoYXMgYWx3YXlzKSBtZXRpY3Vsb3VzIHJldmlldy4N ClJlc3BvbnNlcyBpbmxpbmUuDQpPbmNlIHdlIGhhdmUgcmVhY2hlZCBhZ3JlZW1lbnQgSSB3aWxs IHNlbmQgb3V0IGFuIHVwZGF0ZWQgdmVyc2lvbi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBCcnVubyBEZWNyYWVuZSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0 Zi5vcmc+DQo+IFNlbnQ6IEZyaWRheSwgTWF5IDI5LCAyMDIwIDEwOjE4IEFNDQo+IFRvOiBydGct ZGlyQGlldGYub3JnDQo+IENjOiBsYXN0LWNhbGxAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaXNpcy10 ZS1hcHAuYWxsQGlldGYub3JnOyBsc3JAaWV0Zi5vcmcNCj4gU3ViamVjdDogUnRnZGlyIGxhc3Qg Y2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pc2lzLXRlLWFwcC0xMw0KPiANCj4gUmV2aWV3ZXI6 IEJydW5vIERlY3JhZW5lDQo+IFJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCj4gDQo+ICBIZWxs bywNCj4gDQo+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUNCj4gUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVr cyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcw0KPiB0 aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21l dGltZXMgb24gc3BlY2lhbA0KPiByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlz IHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZw0KPiBBRHMuDQo+IEZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo+ IOKAi2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXIN Cj4gDQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIFJvdXRpbmcgQURzLCBpdA0KPiB3b3VsZA0KPiBiZSBoZWxwZnVsIGlmIHlvdSBjb3Vs ZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxsDQo+IGNv bW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91 Z2ggZGlzY3Vzc2lvbiBvcg0KPiBieQ0KPiB1cGRhdGluZyB0aGUgZHJhZnQuDQo+IA0KPiBEb2N1 bWVudDogZHJhZnQtaWV0Zi1pc2lzLXRlLWFwcC0xMw0KPiBSZXZpZXdlcjogQnJ1bm8gRGVjcmFl bmUNCj4gUmV2aWV3IERhdGU6IDIwMjAtMDUtMjkNCj4gSUVURiBMQyBFbmQgRGF0ZTogMjAyMC0w NS0yOQ0KPiBJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KPiANCj4gU3VtbWFyeToN Cj4gICAgIEkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhh dCBJIHRoaW5rIHNob3VsZCBiZQ0KPiAgICAgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0K PiANCj4gQ29tbWVudHM6DQo+ICAgRHJhZnQgaXMgY2xlYXIuDQo+IA0KPiBNaW5vciBJc3N1ZXM6 DQo+IA0KPiDCpzQuMQ0KPiAqMiAoZm9yIFNBQk0gJiBVREFCTSBmaWVsZHMpDQo+IE9MRDogVGhl IGxlbmd0aCBTSE9VTEQgYmUgdGhlIG1pbmltdW0gcmVxdWlyZWQgdG8gc2VuZCBhbGwgYml0cyB3 aGljaCBhcmUNCj4gc2V0Lg0KPiBJJ2QgcHJvcG9zZQ0KPiBORVc6IFRoZSBsZW5ndGggU0hPVUxE IGJlIHRoZSBtaW5pbXVtIHJlcXVpcmVkIHRvIHNlbmQgYWxsIHRoZQ0KPiBtZWFuaW5nZnVsIGJp dHMNCj4gd2hpY2ggYXJlIHNldC4NCj4gDQo+IE1vdGl2YXRpb247IHRoZSAnYml0cyB3aGljaCBh cmUgc2VudCcgYXJlIHRoZSBiaXRzIGluIHRoZSBTQUJNIGZpZWxkLiAodGhleSBkbw0KPiBpbmNs dWRlIG5vbi1tZWFuaW5nZnVsIGFuZCBwYWRkaW5nIGJpdHMpDQo+IA0KDQpbTGVzOl0gVGhlIGRl ZmluaXRpb24gb2Ygd2hhdCBpcyAibWVhbmluZ2Z1bCIgYW5kIHdoYXQgaXMgInBhZGRpbmciICB0 byBtZSBpcyBhbWJpZ3VvdXMuDQpNZWFuaW5nZnVsIGNvdWxkIGJlIG9ubHkgdGhvc2UgYml0cyB3 aGljaCBhcmUgY3VycmVudGx5IGRlZmluZWQgaW4gdGhlIHJlZ2lzdHJ5IChzcGVha2luZyBvZiBT QUJNIGhlcmUpLiBCdXQgaWYgdGhlcmUgYXJlIDEwIGJpdHMgZGVmaW5lZCBpbiB0aGUgcmVnaXN0 cnkgYW5kIEkgb25seSBpbnRlbmQgdG8gc2V0IEJpdCA1LCBJIGRvIG5vdCBuZWVkIHRvIHNlbmQg YWxsIDEwIGJpdHMgLSBJIG9ubHkgbmVlZCB0byBzZW5kIG9uZSBvY3RldCAtIGJlY2F1c2Ugd2Ug c3RhdGU6DQoNCiJCaXRzIHRoYXQgYXJlIE5PVCB0cmFuc21pdHRlZCBNVVNUIGJlIHRyZWF0ZWQg YXMgaWYgdGhleQ0KICAgYXJlIHNldCB0byAwIG9uIHJlY2VpcHQuICAiDQoNCkFsc28sIGFuIGlt cGxlbWVudGF0aW9uIHdyaXR0ZW4gd2hlbiB0aGVyZSB3ZXJlIG9ubHkgNCBiaXRzIGRlZmluZWQg aW4gdGhlIHJlZ2lzdHJ5IG1pZ2h0IHRoaW5rIHRoYXQgIm1lYW5pbmdmdWwiIGlzIGRpZmZlcmVu dCB0aGFuIGFuIGltcGxlbWVudGF0aW9uIHdyaXR0ZW4gd2hlbiBtb3JlIHRoYW4gOCBiaXRzIHdl cmUgZGVmaW5lZCBpbiB0aGUgcmVnaXN0cnkuIFlldCB0aGV5IGNhbiBzdGlsbCBpbnRlcm9wZXJh dGUuDQoNCkkgYmVsaWV2ZSB0aGUgY3VycmVudCBsYW5ndWFnZSBpcyBiZXN0Lg0KDQo+IC0tLS0N Cj4gDQo+IE9MRDogVW5kZWZpbmVkIGJpdHMgTVVTVCBiZSB0cmFuc21pdHRlZCBhcyAwDQo+IE5F VzogVW5kZWZpbmVkIHRyYW5zbWl0dGVkIGJpdHMgTVVTVCBiZSBjbGVhcmVkICgwKQ0KPiANCj4g TW90aXZhdGlvbjogY3VycmVudGx5IHRoZSBudW1iZXIgb2YgdW5kZWZpbmVkIGJpdHMgaXMgOCo4 LTMuIFRoZXkgU0hPVUxEDQo+IG5vdCBiZQ0KPiB0cmFuc21pdHRlZCAoYmV5b25kIHRoZSBmaXJz dCBvbmVzIGZpdHRpbmcgaW4gdGhlIGZpcnN0IE4gcmVxdWlyZWQgb2N0ZXQpLiBUaGUNCj4gc2Vu dGVuY2UgIlVuZGVmaW5lZCBiaXRzIE1VU1QgYmUgdHJhbnNtaXR0ZWQgYXMgMCIgY291bGQgYmUg cmVhZCBhcyBhbGwNCj4gZGVmaW5lZA0KPiBiaXRzIE1VU1QgYmUgdHJhbnNtaXR0ZWQgKGFzIDAp Lg0KPiAtLS0NCltMZXM6XSBJIGRvIG5vdCBzZWUgaG93IHRoYXQgY291bGQgYmUgYSB2YWxpZCBp bnRlcnByZXRhdGlvbiBnaXZlbiB0aGF0IHdlIHN0YXRlOg0KDQoiIFRoZSBsZW5ndGggU0hPVUxE ICBiZSB0aGUgbWluaW11bSByZXF1aXJlZCB0byBzZW5kIGFsbCBiaXRzIHdoaWNoIGFyZSBzZXQu Ig0KDQpBbmQgKHJlcGVhdGluZykNCg0KIkJpdHMgdGhhdCBhcmUgTk9UIHRyYW5zbWl0dGVkIE1V U1QgYmUgdHJlYXRlZCBhcyBpZiB0aGV5DQogICBhcmUgc2V0IHRvIDAgb24gcmVjZWlwdC4gICIN Cg0KQW5kIGFnYWluLCB5b3UgYXNzdW1lIHRoYXQgImRlZmluZWQgYml0cyIgaXMgdGhlIHNhbWUg Zm9yIGFsbCBpbXBsZW1lbnRhdGlvbnMgLSB3aGljaCBpc24ndCBndWFyYW50ZWVkIGFzIEkgZGlz Y3Vzc2VkIGFib3ZlLg0KDQoNCj4gVXNlciBEZWZpbmVkIEFwcGxpY2F0aW9uIElkZW50aWZpZXIg Qml0cyBoYXZlIG5vIG5hbWUuIEknZCBwcm9wb3NlIHRvIGNhbGwNCj4gdGhlbQ0KPiBVREFCTVsw XSwgVURBQk1bMV0uLi4gVGhpcyBtYXkgYXZvaWQgdGhhdCBkaWZmZXJlbnQgaW1wbGVtZW50YXRp b24gdXNlDQo+IGRpZmZlcmVudCBuYW1lcyBhbmQsIG1vcmUgcHJvYmxlbWF0aWMsIHRoYXQgc29t ZSBpbXBsZW1lbnRhdGlvbnMgc3RhcnRpbmcNCj4gd2l0aA0KPiAxICh0aGUgZmlyc3QsIHRoZSBz ZWNvbmQpIHdoaWxlIHdoaWxlIHNvbWUgb3RoZXIgaW1wbGVtZW50YXRpb25zIHN0YXJ0cyBhcyAw LA0KPiBjcmVhdGluZyBpbnRlcm9wIGlzc3VlcyAoU0FCTVsxXSBvbiBub2RlIEEgaXMgU0FCTVsw XSBvbiBub2RlIEIpDQo+IC0tLQ0KDQpbTGVzOl0gV2hhdCBpbXBsZW1lbnRhdGlvbnMgbWF5IG5h bWUgYml0cyB0aGV5IGFzc2lnbiBmcm9tIHRoZSBVc2VyIHNwYWNlIGlzIG91dCBvZiBzY29wZSBv ZiB0aGlzIGRvY3VtZW50Lg0KSWYgSSB3ZXJlIGltcGxlbWVudGluZyBhIG5vbi1zdGFuZGFyZCBV c2VyIEFwcCBJIGxpa2VseSB3b3VsZCBnaXZlIGl0IGEgbWVhbmluZ2Z1bCBuYW1lIGJvdGggaW4g bXkgY29kZSBhbmQgaW4gYW55IGRvY3VtZW50YXRpb24gSSBwcm9kdWNlLg0KDQpBcyBmYXIgYXMg aW50ZXJvcGVyYWJpbGl0eSwgaWYgeW91IHdhbnQgbXVsdGlwbGUgdmVuZG9ycyB0byBpbnRlcm9w ZXJhdGUgdGhlbiB5b3UgbmVlZCBhIHN0YW5kYXJkIGFwcGxpY2F0aW9uLiBVc2VyIGRlZmluZWQg YXBwbGljYXRpb25zIGRvIG5vdCBwcm92aWRlIGFueSBndWFyYW50ZWUgb2YgaW50ZXJvcGVyYWJp bGl0eS4NCg0KV2UgZG8gc3RhdGUgdGhhdCANCg0KIkl0IGlzIHJlY29tbWVuZGVkIHRoYXQgW3Vz ZXIgZGVmaW5lZF0gYml0cyBhcmUgdXNlZCBzdGFydGluZyB3aXRoIEJpdCAwLi4uIg0KDQpidXQg YXMgVXNlciBEZWZpbmVkIEFwcGxpY2F0aW9ucyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhl IGRvY3VtZW50IHRoZXkgbWlnaHQgY2hvb3NlIHRvIGRvIG90aGVyd2lzZS4NCg0KDQo+IMKnNC4y DQo+IA0KPiAiSW4gY2FzZXMgd2hlcmUgY29uZmxpY3RpbmcgdmFsdWVzIGZvciB0aGUgc2FtZSBh cHBsaWNhdGlvbi9hdHRyaWJ1dGUvbGluayBhcmUNCj4gYWR2ZXJ0aXNlZCBhbGwgdGhlIGNvbmZs aWN0aW5nIHZhbHVlcyBNVVNUIGJlIGlnbm9yZWQuIiBJJ2QgcHJvcG9zZSB0byBhZGQNCj4gImZv cg0KPiB0aGlzIGFwcGxpY2F0aW9uIiAoSU9XLCB0aG9zZSB2YWx1ZXMgYXJlIHN0aWxsIGFwcGxp Y2FibGUgZm9yIGFsbCBvdGhlcg0KPiBhcHBsaWNhdGlvbnMpDQo+IC0tLQ0KDQpbTGVzOl0gSG93 IGFib3V0IGFkZGluZyAiZm9yIHRoZSBzcGVjaWZpZWQgYXBwbGljYXRpb24iID8NCg0KDQoNCj4g wqc2LjINCj4gSSdkIGFyZ3VlIHRoYXQgdGhlIGZpcnN0IHBhcnQgb2Ygc2VjdGlvbiAzLjIgaXMg YSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBiZWhhdmlvcg0KPiBhbmQgaGVuY2Ugc2hvdWxkIGJlIG1v dmVkIHRvIHNlY3Rpb24gNC4xLCByYXRoZXIgdGhhbiBwbGFjZWQgaW4gdGhlIHNlY3Rpb24NCj4g ImRlcGxveW1lbnQgY29uc2lkZXJhdGlvbiIgd2hpY2ggZXZlbnR1YWxseSB3aWxsIG5vdCBiZSBy ZWFkIGJ5IHNvbWVvbmUNCj4gaW1wbGVtZW50aW5nIHRoZSBzcGVjaWZpY2F0aW9uLiBFc3BlY2lh bGx5IHNpbmNlIHRoZSB0ZXh0IGluIHNlY3Rpb24gNC4xDQo+IGltcGxpZXMgYSBkaWZmZXJlbnQg YmVoYXZpb3I6ICJCaXRzIHRoYXQgYXJlIE5PVCB0cmFuc21pdHRlZCBNVVNUIGJlIHRyZWF0ZWQN Cj4gYXMNCj4gaWYgdGhleSBhcmUgc2V0IHRvIDAgb24gcmVjZWlwdC4iDQo+IC0tLQ0KDQpbTGVz Ol0gSSB0aGluayB5b3UgbWVhbnQgdG8gc2F5IHRoZSAiZmlyc3QgcGFydCBvZiBzZWN0aW9uIDYu MiI/PyBDb3JyZWN0Pw0KDQpJZiBzbywgSSBhZ3JlZSAtIGFuZCB3aWxsIG1vdmUgdGhhdCB0ZXh0 IC0gdGhvdWdoIEkgd291bGQgcHJlZmVyIHRvIHB1dCBpdCBpbnRvIFNlY3Rpb24gNC4yLg0KU2Vj dGlvbiA0LjEgaXMgZGVzY3JpYmluZyB0aGUgZW5jb2Rpbmcgb2YgdGhlIGJpdCBtYXNrLiBTZWN0 aW9uIDQuMiBkZXNjcmliZXMgdGhlIEFTTEEgc3ViLVRMViBhbmQgaG93IHRvIGludGVycHJldCBp dC4NCkZvciBleGFtcGxlLCB0aGF0IGlzIHdoZXJlIEwtYml0IGlzIGRpc2N1c3NlZC4NClNvdW5k IGdvb2QgdG8geW91Pw0KDQo+IMKnNQ0KPiAiSW4gdGhlIGNhc2Ugb2YgU1JURSwgYWR2ZXJ0aXNl bWVudCBvZiBhcHBsaWNhdGlvbiBzcGVjaWZpYyBsaW5rIGF0dHJpYnV0ZXMNCj4gZG9lcyBOT1Qg aW5kaWNhdGUgZW5hYmxlbWVudCBvZiBTUlRFLiIgV2hhdCBkb2VzICJlbmFibGVtZW50IG9mIFNS VEUiDQo+IG1lYW5zPyBEbw0KPiB5b3UgaGF2ZSBhIHBvaW50ZXIgdG8gYSBkb2N1bWVudC90ZXh0 Pw0KPiANCj4gSSdtIG5vdCBzdXJlIEkgd291bGQga2VlcCB0aGF0IHBhcmFncmFwaCBvbiBTUi1U RSBlbmFibGVtZW50Lg0KPiAtLS0NCg0KW0xlczpdIFRoZSBwYXJhZ3JhcGggaXMgcmVxdWlyZWQg YmVjYXVzZSB3ZSBzdGF0ZSANCg0KInRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhcHBsaWNhdGlv biBzcGVjaWZpYyBsaW5rIGF0dHJpYnV0ZQ0KICAgYWR2ZXJ0aXNlbWVudHMgYW5kIGVuYWJsZW1l bnQgZm9yIHRoYXQgYXBwbGljYXRpb24iDQoNCmlzIHJlcXVpcmVkIGZvciBhbGwgbmV3IGFwcGxp Y2F0aW9ucy4NCkluIHRoaXMgZG9jdW1lbnQgd2UgYXJlIHByb3ZpZGluZyB0aGF0IGRlZmluaXRp b24gZm9yIHRoZSB0aHJlZSBleGlzdGluZyBhcHBsaWNhdGlvbnMuDQoNClRoZSBwYXJhZ3JhcGgg ZG9lcyBzdGF0ZToNCg0KIlNSVEUgaXMgaW1wbGljaXRseSBlbmFibGVkIG9uIGFsbCBsaW5rcw0K ICAgd2hpY2ggYXJlIHBhcnQgb2YgdGhlIFNlZ21lbnQgUm91dGluZyBlbmFibGVkIHRvcG9sb2d5 IGluZGVwZW5kZW50IG9mDQogICB0aGUgZXhpc3RlbmNlIG9mIGxpbmsgYXR0cmlidXRlIGFkdmVy dGlzZW1lbnRzLiINCg0KSSB3aWxsIG1vZGlmeSB0aGUgZmlyc3Qgc2VudGVuY2UgdG8gc2F5Og0K DQoiSW4gdGhlIGNhc2Ugb2YgU1JURSwgYWR2ZXJ0aXNlbWVudCBvZiBhcHBsaWNhdGlvbiBzcGVj aWZpYyBsaW5rDQogICBhdHRyaWJ1dGVzIGRvZXMgTk9UIGluZGljYXRlIGVuYWJsZW1lbnQgb2Yg U1JURSAgb24gdGhhdCBsaW5rLiINCg0KKCJvbiB0aGF0IGxpbmsiIGlzIGFkZGVkKQ0KDQpEb2Vz IHRoaXMgd29yayBmb3IgeW91Pw0KDQoNCj4gwqc2LjENCj4gIlVuZGVyIHRoZSBjb25kaXRpb25z IGRlZmluZWQgYWJvdmUsIGltcGxlbWVudGF0aW9ucyB3aGljaCBzdXBwb3J0IHRoZQ0KPiAgICBl eHRlbnNpb25zIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBoYXZlIHRoZSBjaG9pY2Ugb2YgdXNp bmcgbGVnYWN5DQo+ICAgIGFkdmVydGlzZW1lbnRzIG9yIGFwcGxpY2F0aW9uIHNwZWNpZmljIGFk dmVydGlzZW1lbnRzIGluIHN1cHBvcnQgb2YNCj4gICAgU1JURSBhbmQvb3IgTEZBLiAgVGhpcyB3 aWxsIHJlcXVpcmUgaW1wbGVtZW50YXRpb25zIHRvIHByb3ZpZGUNCj4gICAgY29udHJvbHMgc3Bl Y2lmeWluZyB3aGljaCB0eXBlIG9mIGFkdmVydGlzZW1lbnRzIGFyZSB0byBiZSBzZW50Lw0KPiAg ICBwcm9jZXNzZWQgb24gcmVjZWl2ZSBmb3IgdGhlc2UgYXBwbGljYXRpb25zLiINCj4gDQo+IEkg dGhpbmsgdGhhdCAiaGF2ZSB0aGUgY2hvaWNlIiBpcyBub3QgcHJlc2NyaXB0aXZlIGVub3VnaCBn aXZlbiB0aGUNCj4gZGVwbG95bWVudA0KPiBpc3N1ZXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gNi4z IEknZCByYXRoZXIgc2F5IHRoYXQgaW1wbGVtZW50YXRpb25zIE1VU1QNCj4gc3VwcG9ydCB0aGUg dXNlIG9mIGJvdGggYWR2ZXJ0aXNlbWVudHMgKGxlZ2FjeSBhbmQgYXBwbGljYXRpb24gc3BlY2lm aWMNCj4gYWR2ZXJ0aXNlbWVudCkgYW5kIE1VU1QgcHJvdmlkZSBjb250cm9scyBzcGVjaWZ5aW5n IHdoaWNoIHR5cGUgb2YNCj4gYWR2ZXJ0aXNlbWVudHMgYXJlIHRvIGJlIHByb2Nlc3NlZCBvbiBy ZWNlaXZlIGZvciB0aGVzZSBhcHBsaWNhdGlvbnMuDQo+IA0KDQpbTGVzOl0gV2Uga25vdyB0aGF0 IGV4aXN0aW5nIGRlcGxveW1lbnRzIChwcmUtdGhpcyBkcmFmdCkgdXNlIGxlZ2FjeSBmb3IgU1JU RS9MRkEuDQpJbiB0aGUgZnV0dXJlLCBpbXBsZW1lbnRhdGlvbnMgY291bGQgY2hvb3NlIHRvIG1p Z3JhdGUgdG8gdXNpbmcgdGhlIG5ldyBBU0xBIGFkdmVydGlzZW1lbnRzIGZvciBTUlRFL0xGQS4g V2hldGhlciB0aGV5IHdpbGwgZG8gc28gb3Igbm90IGlzIGEgYnVzaW5lc3MgZGVjaXNpb24uDQpX ZSBkbyBub3Qgd2FudCB0byBkZWNsYXJlIGltcGxlbWVudGF0aW9ucyBhcyBub24tY29uZm9ybWFu dCBpZiB0aGV5IGRvIG5vdCBtaWdyYXRlLg0KDQogICBMZXMNCg0K