Re: [Tsv-art] Tsvart last call review of draft-ietf-isis-te-app-13

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 21 May 2020 06:28 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02013A0407; Wed, 20 May 2020 23:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=fWAeyv29; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LaXkSI0D
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 KxJIuHhOtH1N; Wed, 20 May 2020 23:28:21 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93373A0404; Wed, 20 May 2020 23:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8034; q=dns/txt; s=iport; t=1590042500; x=1591252100; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aT4F1lyqRqKk5oINv6RvbmCGz9gzpQ9wbTFrNzFYYJw=; b=fWAeyv29W9X8BAEnbUDWW+BzWvU9K47o9XBKZOEuKGkDbf1ljgi4+Cra 11koZFC20B995lvTuHPlhJlWaJNnpcGo+Q3Vj1xiqy8wN545tcpoADFLr awqCuxhc2CkZjVlBjgHRQm5hg2oALbiqdQ0x5IMu87d+4HgZusPLRPjIr o=;
IronPort-PHdr: =?us-ascii?q?9a23=3ARo2QIRFgLbCCMSWChQbtA51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QObXp/c8P8CjPDZ4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8XkYEbf5Hqo4m1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYBQDdHsZe/4YNJK1lHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUeBVFEHgUcvLIQkg0YDjTyYO4FCgRADVQsBAQEMAQEtAgQ?= =?us-ascii?q?BAYREAheBeSQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFcQEBAQECARIREQwBATc?= =?us-ascii?q?BBAcEAgEIDgMEAQEDAhEVAgICMBUICAIEAQ0FCBqFUAMOIAECqB8CgTmIYXa?= =?us-ascii?q?BMoMBAQEFhSoYgg4JgQ4qgmOJXxqBQT+BEAFDgk0+hAcfKhUPGYJVM4ItjjV?= =?us-ascii?q?Rgl6gRH0KglOOMoVKhHGCYoh7kheQSIFcm34CBAIEBQIOAQEFgWkigVZwFTu?= =?us-ascii?q?CaVAYDZBACRqDT4pWdDcCBggBAQMJfIl7gkQBAQ?=
X-IronPort-AV: E=Sophos;i="5.73,416,1583193600"; d="scan'208";a="762179148"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 May 2020 06:28:19 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 04L6SJB9030006 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 May 2020 06:28:19 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 21 May 2020 01:28:18 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 21 May 2020 01:28:18 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 21 May 2020 02:28:18 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NjJSebjn+FFodwUKtpvmg56ZqrL2vx8jpOjHugOC1M7jcdzv5TdKa8FneQH47R9zV4ytWHXUT6zWrk/7wyYsJhSPMkgmdbzefSaEg8xAOAXI203bHVohOQeINJVQBhN89O9x0x51qifQMv/LAo7iMZqDgYE67kDhSQwaxyXvxmB+Y7NnWYqbfTRfimsQsFZm4lvVG7SJhzY4emHLRc72GAEVb3HWGoMoohCdx8SZi+yn0jRUIJF5KNW3IpIeRN/ougJ/sCJDIDSlJUwU6+Rc7e9+R1vX47ZSOqQ2sCzqyn6bw8z7OKb+TXJgBIu4aN6veb7hV+GT0Zb5oO/TdYddoA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aT4F1lyqRqKk5oINv6RvbmCGz9gzpQ9wbTFrNzFYYJw=; b=HdXa2QAwfn8Uu3s8gKC70j5wvxh6596B0k/1D/mHv626Pi83zZ/HxTfswO7KgG3BVeGUabwtBGI6Nnlud+TBUdqTmOS7qx57WDScI9A1PQKjOZqzhQHWjImCIpBKY7DXSziSrmpshn0x+wbz8bIAZiA0JfKEvIqmzJB9EaBnYU1BrDNxGVV/Gd1pqj9vjnCSEng5Y9ldFk1HHNn5HI9XsxhD/GwbNfwoEgiZvsG5VSxzFjQPBoMXx1iPECOmtmvKq4IJMIAGE71sO/mDAdJGhjP56WYrAFjIxPpx+dbJEgiOeuayqpcJFdwQ/zZrb7Fj06rZJsBpMC3hM87g2IjLJA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aT4F1lyqRqKk5oINv6RvbmCGz9gzpQ9wbTFrNzFYYJw=; b=LaXkSI0DU4cq8AmFkU/H7EX4AMzt+MDKA7rwjS5XlCcmisTYqLGeZ1LnryHPKQfFfdzmed/iGLgjcE41YNQQ9a683TrAvcgE7aZLf70scpWJqv8JfvllJwyVE+7Qjt+Zlf8VajQYeINzdX2p3wqXDyUL1Een10FjNb04llr3ZyA=
Received: from MW3PR11MB4619.namprd11.prod.outlook.com (20.181.54.207) by MW3PR11MB4555.namprd11.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.24; Thu, 21 May 2020 06:28:16 +0000
Received: from MW3PR11MB4619.namprd11.prod.outlook.com ([fe80::c4d2:505c:a6bf:21a6]) by MW3PR11MB4619.namprd11.prod.outlook.com ([fe80::c4d2:505c:a6bf:21a6%6]) with mapi id 15.20.3000.034; Thu, 21 May 2020 06:28:16 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Kyle Rose <krose@krose.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "draft-ietf-isis-te-app.all@ietf.org" <draft-ietf-isis-te-app.all@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-isis-te-app-13
Thread-Index: AQHWLvxvkTFHugmiH0GAZXci7fqXTaiyDhig
Date: Thu, 21 May 2020 06:28:16 +0000
Message-ID: <MW3PR11MB4619078973BA1AC8CADF9EDAC1B70@MW3PR11MB4619.namprd11.prod.outlook.com>
References: <159001647095.11068.10737326366413541910@ietfa.amsl.com>
In-Reply-To: <159001647095.11068.10737326366413541910@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: krose.org; dkim=none (message not signed) header.d=none;krose.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2602:306:36ca:6640:11e3:134f:c08f:d530]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8bbe0ff1-360a-4472-e845-08d7fd5025a9
x-ms-traffictypediagnostic: MW3PR11MB4555:
x-microsoft-antispam-prvs: <MW3PR11MB4555CA33AD615F880FD2178CC1B70@MW3PR11MB4555.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 041032FF37
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: N4LqfJd3BszoPnw4NftTAS8nLf87B3wACgp+KTbJYT9dk3D+N0ixTNOCeQERc/XOP1kQy9TZxrPCXteAQYCE5+NXh7QUHCBumW6jsJH2aiqVUMndaceB+pulA64ZvKyWZc8/aUiJsxIyVDts6N8cbZpdKKe3P6zwCg7AuBYU9Uas4+3aBbMAJAMychO9R8ajSorK/ykIUTY5EDICVZ79slw2HOz+k072Wo1PCmVlJWBYg53ApVrZgmVm6rt3QSLZEAcgWnV6R1iONm6hGLgw/KvXVJcJMTBSA8kXnE0qOAIXHqDehSzieizUbhufsefOVxPebhU9aPQUne6aGIKrGg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4619.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(366004)(376002)(396003)(136003)(8676002)(9686003)(110136005)(186003)(2906002)(316002)(52536014)(53546011)(6506007)(54906003)(8936002)(55016002)(66446008)(76116006)(4326008)(5660300002)(7696005)(86362001)(66946007)(64756008)(66556008)(66476007)(33656002)(478600001)(71200400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: q0IgnPFJEWux6r7CG4F688xyxzdbI3ctT+g6e25dbu/OUmalTgO3hVJDEEVu5PushRw1H96GGlfYB7cTd/6y0lGd5C7bR5U7U9PeKcVniWyerAsuBWbBv1Fb/gNKuWCNk8a0iBqawQhEWKUAjmADKrLd96tZKyyE+Ac1q4cs+ANime0taG/+XowYehE7TWmcOLdNxF8WXarHbkYE0LBhYvxuvxXD2hoaJxPYwzDrLnAUS60ZCzm1OkLFsnOzFZpDalkHTzRSTOtd+yDSTxuORML9WuSxxWOYo/anJMu/8b/SNmUuz5skhaEL1YNEYPyX8e/2GjVBeTy6SuHbuxce6/knLwLQkGZ/fMYZL4pl0+PKnC0pGHbyJ0fLvuCmIn4nEwa0CKT5/rIQ3QlaP4sIHKbRNAcXS4xm1fvd3MT/lSoqwYDN4lM/s67uV25YIRn7SXBlU3LelOp0qrEweLjmZAsdGyYGjJ/tUK6xpU3saRCOu1kXQbHfiWdubRtWt0mECtIDNYMySH4hJrEYgSUCOCWhE7bFSebUqHm9pw2UTHJxYPhfnFLovx7xHjeRZJn8
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8bbe0ff1-360a-4472-e845-08d7fd5025a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2020 06:28:16.5530 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lTPaYR/B8QjJxgcmg/1dHVYEG7JINSvjtwYGyx5Wm/SG9x1EA56B/WZn6zagF6tn9/Rt37PK237Hf6Snk+2OPg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4555
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/t2Fl0OiYXoQ8EMBOsdBvWRZiqxU>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-isis-te-app-13
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2020 06:28:23 -0000

Kyle -

Thanx for the review.
Responses inline.

> -----Original Message-----
> From: Kyle Rose via Datatracker <noreply@ietf.org>
> Sent: Wednesday, May 20, 2020 4:15 PM
> To: tsv-art@ietf.org
> Cc: draft-ietf-isis-te-app.all@ietf.org; lsr@ietf.org; last-call@ietf.org
> Subject: Tsvart last call review of draft-ietf-isis-te-app-13
> 
> Reviewer: Kyle Rose
> Review result: Ready with Nits
> 
> This document has been reviewed as part of the transport area review
> team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
> 
> This document describes a mechanism for specifying per-application
> attributes
> for link state routing using IS-IS. It proposes no routing functionality
> changes to applications making use of such attributes, only enabling the
> ability to choose which attributes in an advertisement apply to a particular
> application, and consequently I see no specifically transport-related issues in
> this draft.
> 
> Nonetheless, I have a few comments.
> 
> * Update language?
> 
> There are several places in which it is possible that normative language in
> prior RFCs is revised. For example, in section 6.1, the last paragraph states:
> 
>   New applications which future documents define to make use of the
>   advertisements defined in this document MUST NOT make use of legacy
>   advertisements.
> 
> This looks like it was written in such a way as to avoid requiring such
> updates, but it would be good to confirm that there is no normative language
> in
> older documents that would conflict with this requirement.
> 
[Les:] For applications which preexisted the writing of this draft (the ones defined in Section 7.4) there are existing deployments which use legacy advertisements.
Transitioning to use new advertisements has to account for partial deployment of such support.
And the transition has to be managed by the network operator using knobs provided by implementations. This is onerous - but unavoidable in these cases.

For new applications we want to avoid this complexity/pain. So we specify new applications MUST use the new advertisements from day ONE.

As these are new applications there is no legacy to deal with and no existing specification which would be in conflict.

> * Encoding
> 
> In section 4.1, the bit masks are defined with a 7 bit length field for which
> only 4 bits are useful (values 0-8). It may make sense to keep the 3 high order
> bits as "reserved" and set to zero, but either way it would be nice to
> understand the justification for whatever design decision is made.
> 
> You go to some length to save space (e.g., a zero-length SABM means "all
> applications") but always include an octet for UDABM length, which I
> presume
> will be zero outside the lab in most cases. How much does an extra octet
> cost?
> If it's a lot, you could use the three high-order bits to represent the first
> three applications (RSVP-TE, SRTE, and LFA) and save yourself an octet until a
> fourth application appears.
> 
> For that matter, how likely are you to get to 256 standardized applications
> under IS-IS?
>
[Les:] The limitation for the xABM length to be no more than 8 bytes was introduced only recently based on a review comment.
The concern was that without a limit, it would be theoretically possible for the ABM itself to consume the full sub-TLV space, leaving no room for the actual link attribute advertisements.
So we placed a maximum length to avoid this potential issue.
As each application consumes one bit, with an 8 byte maximum length we can support 64 applications.
This seems more than we will ever get to - but if anyone in the WG thinks this is not large enough they should speak now so we can increase the maximum.

There are existing implementations of this draft which have been deployed. Changing the bit positions as you suggested would not be backwards compatible.
I do not think the small space savings would be worth the trouble.
 
> The fallback from application-specific advertisements to legacy
> advertisements
> is not entirely clear. It sounds like:
> 
>  - An application is to use the legacy advertisements if there is at least one
>  application specific advertisement for that application with L=1, in which
>  case *all* advertisements for that application must also have L=1. - An
>  application is to use the application-specific advertisements if there is at
>  least one application specific advertisement for that application with L=0, in
>  which case *all* advertisements for that application must also have L=0,
> *and*
>  that application is to ignore all legacy advertisements.
> 
> In effect, use of legacy advertisements vs. app-specific advertisements is
> all-or-nothing. If that's the case, wouldn't a top-level TLV specifying a
> legacy mask for applications be more compact, less redundant, and further
> reduce the overall number/size of advertisements?
> 
[Les:] The information being advertised here (link attributes) is necessarily associated with a top level TLV describing a link to a neighbor (TLVs 22, 23, 25, 141, 222, and 223) . Without that context the link attribute information is meaningless.

The options regarding use of legacy are discussed in Sections 6.1 and 6.3.

   Les

> Anyway, I'm out of my element, so feel free to ignore these comments if I'm
> way
> off the mark.
>