Re: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11

Alvaro Retana <> Thu, 06 September 2018 16:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFDE6130ED0; Thu, 6 Sep 2018 09:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vaJ41Q0Y0og0; Thu, 6 Sep 2018 09:47:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E37A3130EC0; Thu, 6 Sep 2018 09:47:45 -0700 (PDT)
Received: by with SMTP id c190-v6so21782944oig.6; Thu, 06 Sep 2018 09:47:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=kB7+LSaENPwCwJOph40f1FVgIqlqMd79aGvUkcekIKA=; b=ezxp6/f8n0j6COpuNE2jDVoMdqpFjPHYOcpQ+fC8+s0Sh9d0CiWVGrPM9Xoj//asIT 2WxVcisBmDwEF8ucXIt+OH/jnC3cazDhB8XYmV3TJcnNAHMWwVtLHP4ObTDvcj5+iJRV mqGt4l8EnGEaVhdMpeN1FLyh0JwtjghF653jx8+fhq2t2rNlbBSHkBZORajvNvWh6ahH AhejRK1Jfa4SFrkLVTtb/Gpp/TdcVdtGgslOn+flq2xVX3SNB9RrZPVxMN2TnofAt6Ee TeD8WM/TQrPm7vMTtoyAXcTCkKHau7QKwapdi/Pq00KSBCEQO1VZSD1ySrIqERlht18j OPwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=kB7+LSaENPwCwJOph40f1FVgIqlqMd79aGvUkcekIKA=; b=qcXjoGQPljznITfuORxDfiUpyevkEwWoUJmo1QGNEImFdz98D92XJO4KobqbEN39Cl bbMUQjf+7vPPnpUAlscekt5xt0XDuDj0Dvv53n+tpa7DixeOfgRnYc2/uYpDJDx1DIuP B2IYsXMhwkq5DChhYlVSnzmT2kBGovlUShEa9CV+8DVv9h0GQzURoNrT2nECRD49ZJqW Ffu0tNE9HFzI+RslK04tEp1zR7Bznzjgf4KP2N5OBb0BtN9agbzwUGv839ibEoqsHuhh hvMqd43q9hrKaO52qKd/cJkCD8TAymraKJBwseZPvL2FD5rLslN2q8oUPtoDaXkGOtww jn2w==
X-Gm-Message-State: APzg51D/C+hwskRr4RvVrFG9brB+3TGBBmbrT2Q7ozI/g2/zrdoBlpV+ yUFSQDe6tmzCrIjIsQ/2dRMZ26PmSIxrDh+X6LM=
X-Google-Smtp-Source: ANB0VdYIcL8kU1C5D0Rp7XYvqQaL53KYJs+un/RA6EdK5/6yWM+WOQcKJByOg9sbzO34EzR1JfynvVAJoiPWiJuP4EY=
X-Received: by 2002:aca:af11:: with SMTP id y17-v6mr3534763oie.274.1536252465138; Thu, 06 Sep 2018 09:47:45 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 6 Sep 2018 18:47:44 +0200
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
X-Mailer: Airmail (506)
MIME-Version: 1.0
Date: Thu, 6 Sep 2018 18:47:43 +0200
Message-ID: <>
To: "Les Ginsberg (ginsberg)" <>, "" <>
Cc: Christian Hopps <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000785176057536a653"
Archived-At: <>
Subject: Re: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Sep 2018 16:47:49 -0000

On August 31, 2018 at 5:13:20 PM, Les Ginsberg (ginsberg) ( wrote:



I am not an author of this draft – but there are a couple of points that I
want to respond to in my role as Designated Expert for the IS-IS IANA
Codepoint Registries.


From: Lsr <>; On Behalf Of Alvaro Retana
Sent: Friday, August 31, 2018 12:27 PM
Cc:; Christian Hopps <>;;
Subject: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11


Note that I read -11, but -12 was published in the interim -- so I'm
putting this comment up here.  The only change in -12 is the addition (in
the IANA Considerations section) of "a new registry for sub-TLVs of the
Reverse Metric TLV".  Why do we need this new registry?  The description
(in §2) of the use of this sub-TLV already references rfc5305 (where a TE
Default Metric sub-TLV is already defined), so it seemed somewhat natural
to me to simply reuse that sub-TLV here.  From the discussion on the list,
I understand the intent to "future proof", even if no other applications
come to mind.  If that is the path we want to go, then we'll need a
complete description of the new sub-TLV as well. [Some of my comments
bellow assume the existing sub-TLV from rfc5305.]

[Les:] The sub-TLV used matches the content of
 sub-TLV 18.

However, the definition in this registry cannot be used to define the
sub-TLV when sent in the Reverse Metric TLV unless we were willing to say
that the above registry also applies to the Reverse-Metric TLV. As
Designated Expert I would strongly object to such a suggestion as it is
clear that no other sub-TLV in this registry is applicable to the Reverse
Metric TLV.

That explanation works for me.


178       The Reverse Metric TLV is optional.  The Reverse Metric TLV may be

179       present in any IS-IS Hello PDU.  A sender MUST only transmit a

180       Reverse Metric TLV in a IS-IS Hello PDU.  If a received IS-IS

181       PDU contains more than one Reverse Metric TLV, an implementation

182       SHOULD ignore all the Reverse Metric TLVs and treat it as an error

183       condition.

[nit] The first two sentences sound redundant to me.

[major] The text above is not specific about which PDUs can include the
Reverse Metric TLV.  The text does say that it is optional and that it may
be in an IIH once...but it doesn't say anything about other PDUs.  The IANA
Considerations section contains the attributes to be included in the
registry, but those are not Normative.

[Les:] I strongly disagree. The permitted PDUs columns in the IANA registry
are intended to be normative. And the normative behavior (derived from ISO
10589 specification) is:

“TLVs received in a non-permitted PDU MUST be ignored.”

First of all, the IANA registries are not Normative, regardless of the
intention.  IANA basically coordinates the assignment of protocol
parameters [rfc2860] [rfc8126].  Note that guidance from IANA itself about
what should not be in IANA Considerations (and therefore not in the
registries) includes "Descriptions of how registered values should/should
not be used”. [1]

My point with this document is that in the section that describe the use of
the new TLV (§2, in this case) is not specific about which PDUs can contain
the TLV.  The text above just says "TLV may be present in any IS-IS Hello
PDU”.  I’m specifically looking for a sentence that says (something to the
effect of): “This TLV is only permitted in an IIH.”   Then the behavior
from 10589 kicks in because we clearly know which are the non-permitted


(There is one exception to that related to LSP purges – but that is
explicitly stated in )

You and I have discussed this privately. If you feel that this behavior is
insufficiently specified then let’s please fix it by adding normative
language to

The registry is authoritative about the assignments, but it is not
Normative as to the behavior of (in this case) the TLVs that use those

Requiring such specification in individual RFCs would mean that we would
have to generate bis versions of any existing RFC that defines a TLV

Requiring an RFC to document the specific behavior of an extension is not a
new requirement.

If we deem it necessary, I volunteer to do what is necessary to get the
registry updated appropriately.

Instead of trying to describe behavior in the registry, or generating bis
versions, an easier move might be to Update the existing RFCs with a single
document.  To be clear, none of that is a requirement to move this document
forward…which is my immediate concern.