Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 01 June 2017 00:58 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 2A9BB129443 for <isis-wg@ietfa.amsl.com>; Wed, 31 May 2017 17:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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.001, SPF_HELO_PASS=-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
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 wcXsUHi_6dGB for <isis-wg@ietfa.amsl.com>; Wed, 31 May 2017 17:58:00 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A01129413 for <isis-wg@ietf.org>; Wed, 31 May 2017 17:57:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20592; q=dns/txt; s=iport; t=1496278679; x=1497488279; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bxadnWO8uYmcf4lyYKA9VWvhfB6Pw8ncVUK6gC5T9zg=; b=KaKJPH6WKAlsCBduDvtGOHgMbl6m5Nzmszgb8G8XiYg4XpmXPtZoL0su UzV+u1Myyb2NuGizMC0L4saKHnXa7HKDKotxJXG+UZbTVHSbMekTe3jgj T3eWWsabPPwweVQJFZjZrzuF/3Kxd3oeER0o7NpfOngBsqpQXPRM7Ijdm o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAABpZS9Z/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoENB44EkXKVeYIPhiQCgm0/GAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAy1cAgEIEQQBASEHBzIUCQgBAQQBEgiJPmSuZYtRAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYZhgV8Bgx+EOVYQhTwFlnmHKgGKVIhKkgCUTQEfOIEKdBVGhTiBSna?= =?us-ascii?q?IRoENAQEB?=
X-IronPort-AV: E=Sophos;i="5.39,277,1493683200"; d="scan'208,217";a="252147774"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jun 2017 00:57:58 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v510vwKQ006076 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2017 00:57:58 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 May 2017 19:57:57 -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.1210.000; Wed, 31 May 2017 19:57:57 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Uma Chunduri <uma.chunduri@huawei.com>, Chris Bowers <cbowers@juniper.net>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00
Thread-Index: AdLLRtm+ZNz9pbnGTU+TnDWIYIoHggCiCx3QAyKCkkAAAhKisAAB3/CwAAIQ0MA=
Date: Thu, 1 Jun 2017 00:57:57 +0000
Message-ID: <56f3acc5d7b44e839cf4d98a2f23b548@XCH-ALN-001.cisco.com>
References: <MWHPR05MB28293E73A559496455BA7BBAA9E20@MWHPR05MB2829.namprd05.prod.outlook.com> <3547a236e630428291fccc45a0add058@XCH-ALN-001.cisco.com> <25B4902B1192E84696414485F5726854018BC396@SJCEML701-CHM.china.huawei.com> <6d001426688b431680e1d840fb04f173@XCH-ALN-001.cisco.com> <25B4902B1192E84696414485F5726854018BC3F2@SJCEML701-CHM.china.huawei.com>
In-Reply-To: <25B4902B1192E84696414485F5726854018BC3F2@SJCEML701-CHM.china.huawei.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.85.4]
Content-Type: multipart/alternative; boundary="_000_56f3acc5d7b44e839cf4d98a2f23b548XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/R1DyKHFcWPUnniiqXp35cGA1D5c>
Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
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, 01 Jun 2017 00:58:02 -0000

Uma -

If all attributes apply to all supported applications on all links on all routers  it is just as easy to use a bit mask as it is a scalar.
If however there is any exception to the above i.e. any link on any router where some attributes cannot be shared by all applications then it is simpler and less error prone to use a bit mask.

We are defining a specification which provides support for all possible use cases.

Besides, you have pointed out another good reason for having standard per application identifiers - they are not domain specific and so can be used across AS's.

   Les



From: Uma Chunduri [mailto:uma.chunduri@huawei.com]
Sent: Wednesday, May 31, 2017 4:58 PM
To: Les Ginsberg (ginsberg); Chris Bowers; isis-wg@ietf.org
Subject: RE: draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00

Les,

For #1, I was saying, if you want to assign a different attribute per application then yes, you need a different scalar. But, if the assumption is most of the attributes are application agnostic you don't have to advertise a separate scalar.

Cheers!
--
Uma C.

From: Uma Chunduri [mailto:uma.chunduri@huawei.com]
Sent: Wednesday, May 31, 2017 3:00 PM
To: Les Ginsberg (ginsberg); Chris Bowers; isis-wg@ietf.org<mailto:isis-wg@ietf.org>
Subject: RE: draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00


Looked at both proposals and here are my specific comments:


-          Perhaps without any application identifier/bit the value can be used for all applications. But specifying and ID can restrict to that particular application. With this, I don't see an explosion of identifiers per application as suggested below.

[Les:] No one - certainly not me - is predicting an "explosion" of applications. That isn't the point I am trying to make.

If we support 3 applications - say SR-TE, LFA, and one User defined App(UDA).



On any interface I could have a need to advertise a link attribute with any of the following scopes:



1)SR-TE only

2)LFA only

3)UDA only

4)SR-TE and LFA

5)SR-TE and UDA

6)LFA and UDA

7)SR-TE and LFA and UDA



If  a bit is assigned to each application (IANA registry or runtime definition), only three bit definitions are needed in order to support all of the above cases.

If a scalar is assigned to represent each combination, then 7 scalars have to be defined.



In order for advertisements to be interpreted consistently by every node these definitions have to be assigned consistently on every node in the network.



If we add support for another UDA then the list above expands to 15 entries ((2**N)-1) for scalars - but only one additional bit need be defined when using a bit mask.





-          One drawback I see with application identifiers -  these would be specific to a domain/AS.  If these values have to be used by a controller for mapping different application identifier in one domain to corresponding

application identifier in another domain would be difficult.  In that sense IANA define application bit mask might fit well.



[Les:] I agree with this point.