[Idr] AD Review of draft-ietf-idr-te-pm-bgp-14

Alvaro Retana <aretana.ietf@gmail.com> Wed, 28 November 2018 21:01 UTC

Return-Path: <aretana.ietf@gmail.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 179B2130E27; Wed, 28 Nov 2018 13:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdNkXF71bnrK; Wed, 28 Nov 2018 13:01:35 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 734FE1274D0; Wed, 28 Nov 2018 13:01:32 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id j21so23856392oii.8; Wed, 28 Nov 2018 13:01:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=PLrdRpiJRjLicG+mVjeU0o6i2QBYjacRhEJe12111LI=; b=D7bFiChf44KtHS3U5c1Jb2w3BqnNglrgDqMzaHy+jiDk7J4drJ53MKjlJwWKj+2yLN Th6gV0sEPd4wdUB4tLkkDYhrHwhjLmAe6ukahv7kyKF/IMpS38CezkpTdTLKblFci9/L uIFHzOHviAjIi6kf4oZLwaYRyx+QCqUAmq6CV3drSCh0S4DWU5VOBjSgSqyOgiSmDMGB FWE4Xs6h5H91hTT3KSPDIZC//1/BCw9Jw+RkdpNutfPk6jL86+AlBlhL2Eibq4uuyabm NkHHV1myVMX3GhlNuHeW5yS6QQknnBoM8UkDakcx9kB0XDjA8SIbkv8no5I4tkdC7kRc g6Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=PLrdRpiJRjLicG+mVjeU0o6i2QBYjacRhEJe12111LI=; b=gvV+DKvbvBfBDRifjjd7DJ6QEIY3WLGqkYEiyCVSTtL97ZkKKtOGGbCw+QzjtfSq9s NazOuEZByUKBOIns8BtAL59K7BR71EJHVSRT8oiROdzf53qU0rcdjFquf7PI7Vr976SL QQCgTuiBpZ9Wngrul4GyASk93VDlGG5r6vLRRsSDUH3iz58T1QqPdZ3FZvj3Gp1Wcb7X gBf83XgLpZRp2KBjB07rgc5/Td2bMCerkunjQ95hwZzpnYqK0FAVGn/ItkbjAQRA7mc2 QFTQo9kWjiROCSMlGXBkG+4NQpnpYYzF8G6EgYkGBzr7tmVwz+9Egv1asG2uJmIpqBHq Blew==
X-Gm-Message-State: AGRZ1gKUqOMg33ArhAjdBhNMzrFUKKnoylUe8TsJOnKHlq8YyLRk88c1 mKxNnFEhbJlOVLmANxKbO8Xv7B7UWsgrSMZKgeCyMw==
X-Google-Smtp-Source: AJdET5f9K2mBQrd4fPqZYV5ukgJaDrTomkDhWa2QW6cw7/4TmqZrKDzr9LGthUqRCNZQiXAYOvXOjI4ElllyHUG0/tE=
X-Received: by 2002:aca:a881:: with SMTP id r123mr22356068oie.207.1543438890857; Wed, 28 Nov 2018 13:01:30 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 28 Nov 2018 13:01:29 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Airmail (528)
MIME-Version: 1.0
Date: Wed, 28 Nov 2018 13:01:29 -0800
Message-ID: <CAMMESsyXWjVrCMG83HUUmMrSNzUvPvdRE6PSa7OAmOJgNtzMpg@mail.gmail.com>
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
Content-Type: multipart/alternative; boundary="000000000000d27979057bbfdece"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/uMucYwPkjIBPM0ksK0dPhL9O9IU>
Subject: [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: Wed, 28 Nov 2018 21:01:38 -0000

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.