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

Uma Chunduri <> Wed, 31 May 2017 23:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE3DF12EA54 for <>; Wed, 31 May 2017 16:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OKxenPLz6aZb for <>; Wed, 31 May 2017 16:57:50 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BFC7129BBB for <>; Wed, 31 May 2017 16:57:50 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DHR29601; Wed, 31 May 2017 23:57:47 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 1 Jun 2017 00:57:46 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Wed, 31 May 2017 16:57:40 -0700
From: Uma Chunduri <>
To: "Les Ginsberg (ginsberg)" <>, Chris Bowers <>, "" <>
Thread-Topic: draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00
Thread-Index: AdLLRtm+ZNz9pbnGTU+TnDWIYIoHggCiCx3QAyKCkkAAAhKisAAB3/Cw
Date: Wed, 31 May 2017 23:57:40 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F5726854018BC3F2SJCEML701CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.592F587C.00C8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f4146acae3c18784e71e83ff7e8f8c27
Archived-At: <>
Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 May 2017 23:57:53 -0000


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.

Uma C.

From: Uma Chunduri []
Sent: Wednesday, May 31, 2017 3:00 PM
To: Les Ginsberg (ginsberg); Chris Bowers;<>
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.