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: =?us-ascii?q?A0AEAADhJwBc/5ldJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDUguZoECJwqDb4gYjAiCDXyIFI40FIFmCwE?= =?us-ascii?q?BI4RJAheDGyI0CQ0BAwEBAgEBAm0cDIU8AQEBBCMKTBACAQgOAwQBASEBCQI?= =?us-ascii?q?CAh8RHQgCBAENBQiDGoEdTAMVD6cDgS+IBA2CFwWMFheBQD+BEAGCXTWCV4F?= =?us-ascii?q?yTw+CXoJXAokZEoVjGIYkiisuCQKKKYNbgyQggVqFEIoyiHiFa4Z6gkoCERS?= =?us-ascii?q?BJx84gVVwFTuCbIschT9BMY0igR8BAQ?=
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>om>; idr@ietf. org <idr@ietf.org>rg>; 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.