Re: [Lsr] Gentle Reminder!!!Re: draft-ietf-isis-te-app: Clarification on Application Identifier bits

"Les Ginsberg (ginsberg)" <> Mon, 11 June 2018 14:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 664B4130E51; Mon, 11 Jun 2018 07:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N5_B1cuIWfSq; Mon, 11 Jun 2018 07:07:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26A461294D0; Mon, 11 Jun 2018 07:07:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=18058; q=dns/txt; s=iport; t=1528726069; x=1529935669; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7JqZOHvbi2o+zrg3XSruPDC8fdn3Thu+bMwXQ0DxN0g=; b=BpOptEorhj2SvHxrt7uxt6VX8+HOAqzyw7Hd2yvu93iJrcHhzkl+H+99 qC4+QKfRfRTvjLvAxrLzzEUgZTkd77MoeCH4SYxTjTsQpjBvdcYi9rTNY +GXJx8LvomPWb+SrNXHjQG3i5vhRDGvI3Brrtg8GjCEG57f+FkRD8kSOL s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAAD7gR5b/5tdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJOdWJ/KAqDbYgEjGSBfogYh0SEdxSBZAuEbAIXgkghNBg?= =?us-ascii?q?BAgEBAQEBAQJtKIUoAQEBBCMKTBACAQgRBAEBKAMCAgIfERQJCAIEAQ0FCBe?= =?us-ascii?q?DBYEbTAMVqHeCHIcHDYEsgWiIRIFUP4EOAYMMgk+BbF4QgkqCVQKRMIcgLAk?= =?us-ascii?q?Ci2mCe4FGg3uHb4pRhjkCERMBgSQdOIFScBWCfoJJjgZvj0+BGgEB?=
X-IronPort-AV: E=Sophos;i="5.49,502,1520899200"; d="scan'208,217";a="190675290"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2018 14:07:37 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w5BE7a9U018425 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jun 2018 14:07:36 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 11 Jun 2018 09:07:36 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Mon, 11 Jun 2018 09:07:36 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Mahend Negi <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Gentle Reminder!!!Re: draft-ietf-isis-te-app: Clarification on Application Identifier bits
Thread-Index: AQHUAGOwN6/iGTzS8U2lv72RAhMMkaRbGb9Q
Date: Mon, 11 Jun 2018 14:07:36 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_6252a7d4e0384fac93367c226b303f0eXCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Lsr] Gentle Reminder!!!Re: draft-ietf-isis-te-app: Clarification on Application Identifier bits
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Jun 2018 14:07:52 -0000

Mahend –

In regards to IPv4/IPv6, in IS-IS there are two ways to support this:

1)Multi-topology mode

Here there are topology specific neighbor advertisements and therefore topology specific link attribute advertisements. Hence no benefit from having afi-specific bits.

2)Single topology mode

Both address-families are supported on a single topology. Every link in the topology MUST support both address families for this configuration to work.
So although we do not have afi specific neighbors, the topology congruence argues against any need for AFI specific link attribute advertisements.

As regards SR-MPLS/SRv6, I expect that – other than as a transition strategy – we won’t have deployments where both technologies are in use for IPv6.  (You certainly could have SR-MPLS for IPv4 and SRv6 for IPv6.) Therefore, in combination with MT, there does not seem to be a use case for different advertisements for SR-MPLS/SRv6.

(BTW, the same arguments hold for OSPF – and even more so because there would be different instances of the protocol for each address family.)


From: Mahend Negi <>
Sent: Saturday, June 09, 2018 7:35 PM
Cc:;; Les Ginsberg (ginsberg) <>om>;
Subject: Gentle Reminder!!!Re: draft-ietf-isis-te-app: Clarification on Application Identifier bits

Dear Authors,

Could you please help me with the query.

Please confirm about the new bit for SRv6-TE applications.
We are working on this draft implementation.

On Wed, Jun 6, 2018, 11:49 Mahend Negi <<>> wrote:

Dear Authors,
I seek few clarifications on "Application Identifier bits".

As defined in the draft:

R-bit: RSVP-TE

S-bit: Segment Routing Traffic Engineering

F-bit: Loop Free Alternate

X-bit: Flex-Algo

Am I right, when I say:

R-bit: For RSVP-TE on IPv6 and IPv4 networks.

S-bit: For SR MPLS and SRv6-TE applications.

I think a bit to be allocated for SRv6-TE applications?

Not sure about RSVP-TE IPv6 case.

If you please your opinion.