Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Alia Atlas <akatlas@gmail.com> Wed, 04 May 2016 22:46 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448D712D197; Wed, 4 May 2016 15:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Level:
X-Spam-Status: No, score=-102.699 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_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 hcqFqe3KQAal; Wed, 4 May 2016 15:46:02 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 DDBB212D583; Wed, 4 May 2016 15:46:01 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id x201so83647184oif.3; Wed, 04 May 2016 15:46:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rOjIoI+CRI5jtBQpEnrN/McsHeJnBBKQESakPRpoL1Y=; b=kT3Ws+jj/XsPELvDKNUt8zR3/qXexFo76FVqda/oFVgeEzWPCwtf8RsU29ckj5c1mu JRmGW3Adf8LDQ5BLNEfSrwXDpcftbg7tywtWKhNe20+8rEB6UQCiT1waU/5Xj2MqP8fR xb1Y1d5v0O3X3KnGMD8sqpxoRcNBzD975/0jDEQxl6oinGF+LM6G18ZAG9bh8P0ETlLA Pb2KRIk1eGdch53SI+D6RY7OkLlx5IPXxsL6QMCVI1Q4fc32/Uo+WM7BZLVeIOuJHGxz gjrGQ8cezjXmQpgiO1WeGcwBD8VrQ3QI89vBTnafUjQgpbyjlfxNUUFWpwbknVvEOxxi nwbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rOjIoI+CRI5jtBQpEnrN/McsHeJnBBKQESakPRpoL1Y=; b=a6TIfRmvDn/6Cgp0BduIAppH7tEqe1pmCf1r8QEJ1qF/4N13x2M1VAV9ds1YxeE0rc FcSRbz8z7c5ejT1uMIxoL4f3UmfoYZDVJi6n8stpfJeHzyhhIpYNXy4JR/zO/BYMJi81 35qFciNhGk93G27koXcUcQUn4hCQulgua54YPsYEiR/99MRbvGi5OIfSqRB9qt8enSj3 TJdoTp91V/xD6dZ1N6S71MFGRAhbMAD2kgTkNCUhwnEbok9dM/LLYeAtWqhslO9MzIVd xd9iet5uTWMFnwW/xy/OXds/k2qS/+Qjv65Xcr1QrBLKZ8tU/ylZ5K7zYfuFAIvhlwA2 dWMw==
X-Gm-Message-State: AOPr4FVT6Haaxy2vKKLhKLoW3E4rmkpguUfL7cOuKlbmcULhLvi0g0fF3mro3N9OqjePeYTdt9/Vj51HDya1/g==
MIME-Version: 1.0
X-Received: by 10.157.20.149 with SMTP id d21mr5334031ote.143.1462401959800; Wed, 04 May 2016 15:45:59 -0700 (PDT)
Received: by 10.60.115.168 with HTTP; Wed, 4 May 2016 15:45:59 -0700 (PDT)
In-Reply-To: <20160504211229.8272.67553.idtracker@ietfa.amsl.com>
References: <20160504211229.8272.67553.idtracker@ietfa.amsl.com>
Date: Wed, 04 May 2016 18:45:59 -0400
Message-ID: <CAG4d1re1uNPV=HnpFTToG27kr_OoYKmhzunDWYBMSnLetmkaCg@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Jari Arkko <jari.arkko@piuha.net>
Content-Type: multipart/alternative; boundary="001a113e22ac553fc905320bfd9f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/139-XpOF0NL42KLl16xrgP2gj5o>
Cc: Peter Yee <peter@akayla.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>, Christian Hopps <chopps@chopps.org>, draft-ietf-isis-node-admin-tag@ietf.org, The IESG <iesg@ietf.org>, isis-chairs@ietf.org
Subject: Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2016 22:46:05 -0000

Jari,

I think I need to push back a bit on this one.

I will note that the OSPF version of this same extension (RFC 7777)  uses
exactly
this same text " Being part of the RI LSA, the Node Admin Tag TLV must be
reasonably
   small and stable.  In particular, implementations supporting node
   administrative tags MUST NOT be used to convey attributes of the
   routing topology or associate tags with changes in the network
   topology (both within and outside the OSPF domain) or reachability of
   routes."
Of course, different reviewers find different concerns and that's quite
reasonable.

The sentences following "small and stable" certainly provide guidance on
what is definitely not considered stable "In particular, but not
   limited to, implementations supporting the node administrative tags
   MUST NOT associate advertised tags to changes in the network topology
   (both within and outside the IS-IS domain) or the reachability of
   routes."

Since the total length of sub-TLVs is constrained to no more than 250 bytes
(as specified in RFC 4971 - a normative reference),I think it's clear that
that the
data must be small.  While one can argue about how much of that space
should
be consumed by Node Administrative tags, that does end up being a local
domain decision.

I did see back and forth in the discussion between Peter and Pushpasis about
how specific to be in terms of what number to specify.  Are you looking for
clarification such as:

 "There are only 250 bytes [RFC4971-bis] available for sub-TLVs in the
Router
Capability TLV; the maximum number of different Administrative Tags
advertised
should be limited to permit other necessary sub-TLVs to be advertised.  The
decision on how many Administrative Tags are acceptable is a decision for
the
deploying network."

Regards,
Alia

On Wed, May 4, 2016 at 5:12 PM, Jari Arkko <jari.arkko@piuha.net> wrote:

> Jari Arkko has entered the following ballot position for
> draft-ietf-isis-node-admin-tag-10: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-isis-node-admin-tag/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Peter Yee's Gen-ART review raised this issue which I agree with. Can this
> be defined in a more clear fashion? Or is there already a definition
> somewhere else that I had not seen?
>
> Page 5, section 4.2, 2nd paragraph, 1st sentence: The sentence states:
> "Being part of the Router CAPABILITY TLV, the node administrative tag
> sub-TLV MUST be reasonably small and stable."  If you're going to make
> this
> a MUST, you've got to at least give a definition of "reasonably small"
> and
> perhaps even "stable" in the context of this specification.  As it
> stands,
> there's no test for whether the MUST is enforceable or understandable
> between parties.
>
>
>
>
>