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

Uma Chunduri <uma.chunduri@huawei.com> Thu, 01 June 2017 17:59 UTC

Return-Path: <uma.chunduri@huawei.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 871F31293DB for <isis-wg@ietfa.amsl.com>; Thu, 1 Jun 2017 10:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ZcML0_EtdCPt for <isis-wg@ietfa.amsl.com>; Thu, 1 Jun 2017 10:59:41 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A0D1270A7 for <isis-wg@ietf.org>; Thu, 1 Jun 2017 10:59:40 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHS70588; Thu, 01 Jun 2017 17:59:38 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 1 Jun 2017 18:59:37 +0100
Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.56]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0235.001; Thu, 1 Jun 2017 10:59:30 -0700
From: Uma Chunduri <uma.chunduri@huawei.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.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/CwAAIQ0MAAI7hp4A==
Date: Thu, 01 Jun 2017 17:59:30 +0000
Message-ID: <25B4902B1192E84696414485F5726854018BC63C@SJCEML701-CHM.china.huawei.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> <56f3acc5d7b44e839cf4d98a2f23b548@XCH-ALN-001.cisco.com>
In-Reply-To: <56f3acc5d7b44e839cf4d98a2f23b548@XCH-ALN-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.49.181]
Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F5726854018BC63CSJCEML701CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5930560A.0238, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f4146acae3c18784e71e83ff7e8f8c27
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/pbYMs6YG9o6uoDIJqhYj1PLGaAU>
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 17:59:43 -0000

Les,


In-line [Uma]:

--
Uma C.

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

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.
[Uma]: Fine by me.

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.
[Uma]: Yes, some advantage here.

   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<mailto: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.