Re: [Idr] AD Review of draft-ietf-idr-te-pm-bgp-14
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 29 November 2018 17:58 UTC
Return-Path: <ginsberg@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799FB130E02; Thu, 29 Nov 2018 09:58:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.959
X-Spam-Level:
X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggB3D_Eue3eN; Thu, 29 Nov 2018 09:58:41 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B091271FF; Thu, 29 Nov 2018 09:58:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59574; q=dns/txt; s=iport; t=1543514320; x=1544723920; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sFptsZBbCGftTbd4uLiiM68IHTr/jXKykqMOcN0Jp+M=; b=meSduLrgQbv+/8h81cwLvozJ0cFHU/N2JUtG770V3dZ90bKf7LjWtBsA Hf8Xm/sOsC69SdgABPUuciPCAQV5M4fpCOOi5koKnDyO+pxx4L18PbiZX NCeMhrkjs8jbQTnG/7V/+3Z6EKBLqe4ZieYSzeEQXSsgDpCKsO1FH+hto I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAADhJwBc/5ldJa1kGgEBAQEBAgEBAQEHAgEBAQGBUQUBAQEBCwGBDUguZoECJwqDb4gYjAiCDXyIFI40FIFmCwEBI4RJAheDGyI0CQ0BAwEBAgEBAm0cDIU8AQEBBCMKTBACAQgOAwQBASEBCQICAh8RHQgCBAENBQiDGoEdTAMVD6cDgS+IBA2CFwWMFheBQD+BEAGCXTWCV4FyTw+CXoJXAokZEoVjGIYkiisuCQKKKYNbgyQggVqFEIoyiHiFa4Z6gkoCERSBJx84gVVwFTuCbIschT9BMY0igR8BAQ
X-IronPort-AV: E=Sophos;i="5.56,295,1539648000"; d="scan'208,217";a="205600483"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2018 17:58:39 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id wATHwdkT029012 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Nov 2018 17:58:39 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 29 Nov 2018 11:58:38 -0600
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Thu, 29 Nov 2018 11:58:38 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-idr-te-pm-bgp@ietf.org" <draft-ietf-idr-te-pm-bgp@ietf.org>
CC: Susan Hares <shares@ndzh.com>, "idr@ietf. org" <idr@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Thread-Topic: AD Review of draft-ietf-idr-te-pm-bgp-14
Thread-Index: AQHUh12QnjtbZxhbEU+o9qZQpz0vTqVnCk5w
Date: Thu, 29 Nov 2018 17:58:38 +0000
Message-ID: <e0219b4ef0cc4321822ad092201192af@XCH-ALN-001.cisco.com>
References: <CAMMESsyXWjVrCMG83HUUmMrSNzUvPvdRE6PSa7OAmOJgNtzMpg@mail.gmail.com>
In-Reply-To: <CAMMESsyXWjVrCMG83HUUmMrSNzUvPvdRE6PSa7OAmOJgNtzMpg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.67.88]
Content-Type: multipart/alternative; boundary="_000_e0219b4ef0cc4321822ad092201192afXCHALN001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZeLhBeJe9EfWrRnk4AeT2FN41Ww>
Subject: Re: [Idr] AD Review of draft-ietf-idr-te-pm-bgp-14
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Nov 2018 17:58:44 -0000
Alvaro – Thanx for the review. I am fine with all of your comments – but I do have one concern. You suggest replacing the reference to RFC7810 with a reference to draft-ietf-lsr-isis-rfc7810bis. If we do that then the publication of this document will be blocked on the publication of draft-ietf-lsr-isis-rfc7810bis. But the changes being made in the bis draft do not affect the content of this document in any way. So it makes more sense to me to continue to reference RFC 7810. I’ll go with whatever you decide, but wanted to raise this point before making the suggested change. ??? Les From: Alvaro Retana <aretana.ietf@gmail.com> Sent: Wednesday, November 28, 2018 1:01 PM To: draft-ietf-idr-te-pm-bgp@ietf.org Cc: Susan Hares <shares@ndzh.com>; idr@ietf. org <idr@ietf.org>; idr-chairs@ietf.org Subject: AD Review of draft-ietf-idr-te-pm-bgp-14 Dear authors: I just finished reading this document. Please see the comments in-line below. I found only one significant issue with the definition of Available Bandwidth (see my comment in §3.6). This issue, along with my other comments (mostly nits), should be easy to address. I am then starting the IETF Last Call. Thanks! Alvaro. [Note: the line numbers come from idnits.] ... 17 Abstract 19 This document defines new BGP-LS TLVs in order to carry the IGP 20 Traffic Engineering Extensions defined in IS-IS and OSPF protocols. [nit] s/defined in IS-IS and OSPF protocols/defined in the IS-IS and OSPF protocols 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 26 "OPTIONAL" in this document are to be interpreted as described in BCP 27 14 [RFC2119] [RFC8174] when, and only when, they appear in all 28 capitals, as shown here. [major] No Normative language is used -- which is not a bad thing. Please remove the boilerplate text and the appropriate references. ... 90 2. Link Attribute TLVs for TE Metric Extensions 92 The following new Link Attribute TLVs are defined: 94 TLV Name 95 ------------------------------------------ 96 Unidirectional Link Delay 98 Min/Max Unidirectional Link Delay 100 Unidirectional Delay Variation 102 Unidirectional Link Loss 104 Unidirectional Residual Bandwidth 106 Unidirectional Available Bandwidth 108 Unidirectional Bandwidth Utilization [nit] This is weird seemingly-stub section. Consider renaming §3 "Link Attribute TLVs for TE Metric Extensions", moving the contents there and turning the list above into a table including the new TLV types... 110 3. TLV Details 112 3.1. Unidirectional Link Delay TLV 114 This TLV advertises the average link delay between two directly 115 connected IGP link-state neighbors. The semantic of the TLV is 116 described in [RFC7810] and [RFC7471]. [nit] s/semantic/semantics [minor nit] In rfc7810, the Type and Length fields are 1-byte each...so in reality rfc7810/rfc7471 describe the semantics of the Value field (not the whole TLV). Maybe some short text in §3 about the TLV format following the specification in rfc7752 would help. ... 220 3.6. Unidirectional Available Bandwidth TLV 222 This sub-TLV advertises the available bandwidth between two directly 223 connected IGP link-state neighbors. The semantic of the TLV is 224 described in [RFC7810] and [RFC7471]. 226 0 1 2 3 227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type | Length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Available Bandwidth | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [major] AFAICT, Available Bandwidth is the only definition that is different between rfc7810/draft-ietf-lsr-isis-rfc7810bis and rfc7471. The difference comes from the correction made to address this report [1]. Instead of trying to fix the definition here, I think that a similar report should be filed against rfc7471. Please submit it and I will approve. [1] https://www.rfc-editor.org/errata/eid5486 ... 284 5. IANA Considerations 286 This document requests assigning code-points from the registry "BGP- 287 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 288 TLVs" for the new Link Attribute TLVs defined in the table below: 290 TLV code-point Value 291 -------------------------------------------------------- 292 1114 Unidirectional Link Delay 294 1115 Min/Max Unidirectional Link Delay 296 1116 Unidirectional Delay Variation 298 1117 Unidirectional Link Loss 300 1118 Unidirectional Residual Bandwidth 302 1119 Unidirectional Available Bandwidth 304 1120 Unidirectional Bandwidth Utilization [major] This document doesn't request the assignments, but IANA has done the early allocation... Please correct. ... 325 8.1. Normative References ... 332 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 333 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 334 DOI 10.17487/RFC4271, January 2006, 335 <https://www.rfc-editor.org/info/rfc4271>. [minor] I think this can be an Informative reference: just like rfc4272 and rfc6952 are. ... 348 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 349 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 350 RFC 7810, DOI 10.17487/RFC7810, May 2016, 351 <https://www.rfc-editor.org/info/rfc7810>. [major] Please use draft-ietf-lsr-isis-rfc7810bis as the reference.
- [Idr] AD Review of draft-ietf-idr-te-pm-bgp-14 Alvaro Retana
- [Idr] Available Bandwidth erratum 5486 [was: Re: … John Scudder
- Re: [Idr] Available Bandwidth erratum 5486 [was: … John E Drake
- Re: [Idr] Available Bandwidth erratum 5486 [was: … Alvaro Retana
- Re: [Idr] Available Bandwidth erratum 5486 [was: … John Scudder
- Re: [Idr] Available Bandwidth erratum 5486 [was: … John E Drake
- Re: [Idr] Available Bandwidth erratum 5486 [was: … Alvaro Retana
- Re: [Idr] Available Bandwidth erratum 5486 [was: … Les Ginsberg (ginsberg)
- Re: [Idr] Available Bandwidth erratum 5486 [was: … Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-te-pm-bgp-14 Les Ginsberg (ginsberg)
- Re: [Idr] Available Bandwidth erratum 5486 [was: … Les Ginsberg (ginsberg)
- Re: [Idr] AD Review of draft-ietf-idr-te-pm-bgp-14 Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-te-pm-bgp-14 Les Ginsberg (ginsberg)