Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 05 May 2016 00:45 UTC
Return-Path: <ginsberg@cisco.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 1FC1812D963; Wed, 4 May 2016 17:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level:
X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 KK86bsVgFtLG; Wed, 4 May 2016 17:45:36 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B93812D877; Wed, 4 May 2016 17:45:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35358; q=dns/txt; s=iport; t=1462409136; x=1463618736; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Y1tdxd1MIDN8n8YXHrXW/ACzmR/we4TfMGD+Pubs2E4=; b=bfhivtEKCs599HcWkW7lbwnUrV/zAMWu3ybjHe5J1H/M43412qgLQcR9 GjYun5vecIlAryEW0K9PfWBbCVCbKj2twTQWBm8Gyr0EtGGmzbk/sup/y u2uz+no9ldpzlMjZvDBsRmN5usRqIsqvs30BEqQzFQo7rxJfg1WbeEHKb Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AaAgDhlipX/5tdJa1egmxMU30GrgOJU4IPAQ2BdiKFbgIcgR04FAEBAQEBAQFlJ4RBAQEBBCMKTBACAQgOAwQBASEHAwICAh8RFAkIAgQKBAUIiA0DEg6tMIwlDYQ5AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIIRMgkOBTgoBBgFSgkqCWQWHeIsshEQxAYV7hiWBcIFvhE2IXodTh2ABHgEBQoICAxsWgTVsAYcbAQgXH38BAQE
X-IronPort-AV: E=Sophos;i="5.24,579,1454976000"; d="scan'208,217";a="269821555"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 May 2016 00:45:35 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u450jZb7016759 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 May 2016 00:45:35 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 19:45:34 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Wed, 4 May 2016 19:45:34 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Alia Atlas <akatlas@gmail.com>
Thread-Topic: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)
Thread-Index: AQHRpkmw5Pluqt5k70GYTWPyRTx7ep+ptLKA//+8JwCAAF6/gP//rWKQ
Date: Thu, 05 May 2016 00:45:34 +0000
Message-ID: <658ac2cbc94c4f6b8ccc13770eeebb39@XCH-ALN-001.cisco.com>
References: <20160504211229.8272.67553.idtracker@ietfa.amsl.com> <CAG4d1re1uNPV=HnpFTToG27kr_OoYKmhzunDWYBMSnLetmkaCg@mail.gmail.com> <3a2f71ba6861400c8e556231e5e2f11d@XCH-ALN-001.cisco.com> <CAG4d1rcroAaupCzp0p9HfnP=wqf=tap-wLxZkqB0xVmauHQZZg@mail.gmail.com>
In-Reply-To: <CAG4d1rcroAaupCzp0p9HfnP=wqf=tap-wLxZkqB0xVmauHQZZg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.110.137]
Content-Type: multipart/alternative; boundary="_000_658ac2cbc94c4f6b8ccc13770eeebb39XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/Kz0RtGzPTz4mC2VkbXgV1iKiFL0>
Cc: "draft-ietf-isis-node-admin-tag@ietf.org" <draft-ietf-isis-node-admin-tag@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, Christian Hopps <chopps@chopps.org>, Peter Yee <peter@akayla.com>, The IESG <iesg@ietf.org>, "isis-chairs@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: Thu, 05 May 2016 00:45:40 -0000
Alia – How about replacing the second paragraph of Section 4.2 with: “Node administrative tags are expected to be associated with a stable attribute. In particular, node administrative tags MUST NOT be associated with something whose state can oscillate frequently e.g., the reachability to a specific destination. While no specific limit on the number of node administrative tags which may be advertised is defined, it is expected that only a modest number of tags will be required in any deployment.” Les From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, May 04, 2016 5:22 PM To: Les Ginsberg (ginsberg) Cc: Jari Arkko; Peter Yee; isis-wg@ietf.org; Christian Hopps; draft-ietf-isis-node-admin-tag@ietf.org; The IESG; isis-chairs@ietf.org Subject: Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS) Les & Peter, True, one can have multiple Router Capability TLVs. I do think that stable is a MUST. I don't see a need for further clarification, but am happy to see other text. As for small, I don't think that specifying an arbitrary number is needed. At the same time, by specifying "small", it's there's no expectation that this is a good way of transfering a database via IS-IS. As I said, this is the same text as in the OSPF RFC and I do see it as both useful and close to sufficient. Do you have more clear words to suggest? Thanks, Alia On Wed, May 4, 2016 at 8:04 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote: Alia – Sorry, have to jump in on this one. The fact that IS-IS TLVs/sub-TLVs have an eight bit length only means that in a single TLV/sub-TLV the size is limited. This does NOT mean that multiple TLVs/sub-TLVs cannot be used to advertise the same type of data. The suggestion below that since no more than 250 bytes will fit in a sub-TLV therefore that limits the number of admin tags which could be advertised is therefore simply incorrect. I did not follow closely the final review of RFC 7777 (apologies) but the choice of language “small and stable” is quite unfortunate. “Stable” is a legitimate concern of course. But “small” suggests that we need to limit the number of admin tags to some arbitrary number. I simply do not see the need to define that. Les From: Isis-wg [mailto:isis-wg-bounces@ietf.org<mailto:isis-wg-bounces@ietf.org>] On Behalf Of Alia Atlas Sent: Wednesday, May 04, 2016 3:46 PM To: Jari Arkko Cc: Peter Yee; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; Christian Hopps; draft-ietf-isis-node-admin-tag@ietf.org<mailto:draft-ietf-isis-node-admin-tag@ietf.org>; The IESG; isis-chairs@ietf.org<mailto:isis-chairs@ietf.org> Subject: Re: [Isis-wg] 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. 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<mailto: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