Re: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11
Alvaro Retana <aretana.ietf@gmail.com> Thu, 06 September 2018 16:47 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDE6130ED0; Thu, 6 Sep 2018 09:47:48 -0700 (PDT)
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 vaJ41Q0Y0og0; Thu, 6 Sep 2018 09:47:46 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 E37A3130EC0; Thu, 6 Sep 2018 09:47:45 -0700 (PDT)
Received: by mail-oi0-x232.google.com 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; d=gmail.com; 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; d=1e100.net; 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 gmailapi.google.com with HTTPREST; Thu, 6 Sep 2018 18:47:44 +0200
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <b56d6aeca2c543f48e09d254a72079ab@XCH-ALN-001.cisco.com>
References: <CAMMESswPKPEGsr6zM4wD7oWgdVUcDF-RHeBEu_vfaxZWjJEh_w@mail.gmail.com> <b56d6aeca2c543f48e09d254a72079ab@XCH-ALN-001.cisco.com>
X-Mailer: Airmail (506)
MIME-Version: 1.0
Date: Thu, 06 Sep 2018 18:47:43 +0200
Message-ID: <CAMMESsw9unaRt75xOY=vHUggRNfDE9Jo4ZPHLp16P5XNakMQaw@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "draft-ietf-isis-reverse-metric@ietf.org" <draft-ietf-isis-reverse-metric@ietf.org>
Cc: Christian Hopps <chopps@chopps.org>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000785176057536a653"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7xM51nU30FAJTdjmvB2bUYobfWY>
Subject: Re: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=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) ( ginsberg@cisco.com) wrote: Les: Hi! 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 <lsr-bounces@ietf.org> On Behalf Of Alvaro Retana Sent: Friday, August 31, 2018 12:27 PM To: draft-ietf-isis-reverse-metric@ietf.org Cc: lsr-chairs@ietf.org; Christian Hopps <chopps@chopps.org>; lsr@ietf.org 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 https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 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 single 180 Reverse Metric TLV in a IS-IS Hello PDU. If a received IS-IS Hello 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 PDUs. [1] https://www.iana.org/help/protocol-registration (There is one exception to that related to LSP purges – but that is explicitly stated in https://tools.ietf.org/html/rfc6233 ) 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 https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml . 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 assignments. Requiring such specification in individual RFCs would mean that we would have to generate bis versions of any existing RFC that defines a TLV codepoint. 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. Thanks! Alvaro.
- [Lsr] AD Review of draft-ietf-isis-reverse-metric… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-isis-reverse-me… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-isis-reverse-me… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-isis-reverse-me… Naiming Shen (naiming)
- Re: [Lsr] AD Review of draft-ietf-isis-reverse-me… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-isis-reverse-me… Naiming Shen (naiming)
- Re: [Lsr] AD Review of draft-ietf-isis-reverse-me… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-isis-reverse-me… Acee Lindem (acee)
- Re: [Lsr] AD Review of draft-ietf-isis-reverse-me… Uma Chunduri