Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)
"Peter Yee" <peter@akayla.com> Wed, 04 May 2016 23:55 UTC
Return-Path: <peter@akayla.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 BE9F612D18C; Wed, 4 May 2016 16:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 gSMQZOxJh6Ah; Wed, 4 May 2016 16:55:24 -0700 (PDT)
Received: from p3plsmtpa08-07.prod.phx3.secureserver.net (p3plsmtpa08-07.prod.phx3.secureserver.net [173.201.193.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CF612D917; Wed, 4 May 2016 16:55:23 -0700 (PDT)
Received: from spectre ([173.8.184.78]) by p3plsmtpa08-07.prod.phx3.secureserver.net with id qPvM1s00D1huGat01PvN7X; Wed, 04 May 2016 16:55:23 -0700
From: Peter Yee <peter@akayla.com>
To: 'Alia Atlas' <akatlas@gmail.com>, 'Jari Arkko' <jari.arkko@piuha.net>
References: <20160504211229.8272.67553.idtracker@ietfa.amsl.com> <CAG4d1re1uNPV=HnpFTToG27kr_OoYKmhzunDWYBMSnLetmkaCg@mail.gmail.com>
In-Reply-To: <CAG4d1re1uNPV=HnpFTToG27kr_OoYKmhzunDWYBMSnLetmkaCg@mail.gmail.com>
Date: Wed, 04 May 2016 16:55:23 -0700
Message-ID: <00d001d1a660$6d4a1d60$47de5820$@akayla.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D1_01D1A625.C0EDB660"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIPAoiVJhhMMqgmREQQ72foLaU9vAEMq2zSnyZRKjA=
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/0FR0s7ZeoYW6HzZfdQVvzHFBX0U>
Cc: draft-ietf-isis-node-admin-tag@ietf.org, isis-wg@ietf.org, 'Christian Hopps' <chopps@chopps.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 23:55:27 -0000
Alia, See my comments below prefixed with PEY>. Thanks. -Peter From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, May 04, 2016 3:46 PM To: Jari Arkko Cc: The IESG; draft-ietf-isis-node-admin-tag@ietf.org; Peter Yee; Christian Hopps; isis-chairs@ietf.org; isis-wg@ietf.org Subject: Re: Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS) 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. PEY> But I believe we’ve also agreed that there can be multiple Node Administrative Tag sub-TLVs, so I’m not sure what the 250 byte limit gives us here other than to make a single sub-TLV fit within a single Router CAPABILITY TLV. Section 4.3 (paragraph 1) indicates that multiple sub-TLVs may be carried in multiple Router CAPABILITY TLVs, so we already have the ability to exceed the 250 byte boundary for a set of tags. As for the stability of the set of tags, I don’t think the sentence following “small and stable” wholly addresses that topic. It does give a useful example of what not to do with the tags, but doesn’t really tie that to a concept of stability unless there’s some definition of how often IS-IS may change the network topology or how frequent route reachability. Is there a threshold? (But, see my next reply below before bothering to comment.) 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." PEY> Actually, my concern was never over the ability to convey other sub-TLVs in the presence of a large Node Administrative Tag sub-TLV. It was only with the statement that about the tag set being small and stable. Nothing else in the document seems to care about how many tags there are or how often they change, so I’d prefer to remove that statement since it has a MUST without a definition. Perhaps start the relevant paragraph at “implementations” in the 2nd sentence. That provides the desired guidance without giving an untestable imperative. PEY> And I’m not a routing expert by any stretch of the imagination, so if the text makes sense in the broader IS-IS or general routing world, by all means discount my comment. I just don’t like MUSTs where I can’t determine whether I’ve violated the statement. 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.
- [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis… Jari Arkko
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Alia Atlas
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Peter Yee
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Alia Atlas
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Jari Arkko
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Alia Atlas
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Peter Yee
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Pushpasis Sarkar
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… bruno.decraene
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Pushpasis Sarkar
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Hannes Gredler
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… bruno.decraene
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Tony Przygienda
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Pushpasis Sarkar
- Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-… Jari Arkko