Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te- protocols

"Les Ginsberg (ginsberg)" <> Fri, 13 October 2017 21:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7FF8126B6E; Fri, 13 Oct 2017 14:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.531
X-Spam-Status: No, score=-12.531 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 JlsVyyLaodbW; Fri, 13 Oct 2017 14:08:38 -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 79BF312895E; Fri, 13 Oct 2017 14:08:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=31166; q=dns/txt; s=iport; t=1507928918; x=1509138518; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cQa8YBdbP0wvDtQcamf7ZNyDluaM3IvZSOJp8TcDOjw=; b=Lg/g5A3iKAynGl05g2DexcvNg36MsF4pcWTqEr8344rCLSfbDen1/sIe 0xik7ArG57WBUlaiuC2/zqztC5dDusC5XnGxj6WVeZc6dkifVWxuqocVL 4/JvABKJK+eSCXJx1qWypW/RgjYaPBRHcTdsFmOn0VrqcI3nzIvo2DN3k 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQDXKuFZ/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9CLmRuJweDc5lSgXaWL4IUCiKFGQIahDxAFwECAQEBAQEBAWs?= =?us-ascii?q?ohR0BAQEEIwo+AwsMBAIBCBEEAQEhBwMCAgIwFAkIAgQBDQUIiTFkEKwVgieLM?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgy2CB4FRgWmDK4MygXkQgl2CYQWYZIh?= =?us-ascii?q?iAoddg2KJIYIdhXaLCJVCAhEZAYE4ASEBNYFZehVJgmSCI4I8dgEBAYk6gREBA?= =?us-ascii?q?QE?=
X-IronPort-AV: E=Sophos; i="5.43,372,1503360000"; d="scan'208,217"; a="16876728"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Oct 2017 21:08:37 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v9DL8btE017378 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Oct 2017 21:08:37 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 13 Oct 2017 16:08:36 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Fri, 13 Oct 2017 16:08:36 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Shraddha Hegde <>, Sami Boutros <>, "" <>
CC: "" <>, "" <>
Thread-Topic: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te- protocols
Thread-Index: AQHTQ6UlCVZYVHnP2U6EFixdhp46FKLhw5GwgABmJ4A=
Date: Fri, 13 Oct 2017 21:08:35 +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_6df8e346c72f4d008e6d7e47a7f0d36aXCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te- protocols
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: Fri, 13 Oct 2017 21:08:41 -0000

Shraddha –

RSVP-TE has been deployed for many years and the separation of RSVP enablement from link attribute advertisements has never been required or done.

What is true today is that implementations use the presence of link attribute advertisements to infer that RSVP is enabled on a link. The problem detailed in Figure 1 of your draft demonstrates that implementations do not agree on what specific sub-TLV is required to indicate RSVP enablement. The TE-APP draft resolves this issue by indicating whether link attribute advertisements are to be used by RSVP-TE – but it deliberately does NOT change the existing model of requiring at least one link attribute advertisement in order to infer RSVP enablement. This resolves the interoperability issue but does so in a way which is far less disruptive than what you propose.

You are suggesting that there is a use case for RSVP in the absence of any link attribute advertisements and that the lack of this separate signaling is causing a significant problem in networks today. This flies in the face of existing deployments – and is certainly not backwards compatible with anyone’s shipping code today.  I have discussed this issue with several RSVP-TE experts over the last several months and none of them has identified this as a problem which needs to be solved.


From: Isis-wg [] On Behalf Of Shraddha Hegde
Sent: Friday, October 13, 2017 6:27 AM
To: Sami Boutros <>om>;
Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te- protocols

Hi Sami,

Its better to keep protocol enabled/disabled information decoupled from the

“Application Specific Link Attributes sub-TLV”

Its useful to advertise RSVP enabled/disabled on a link so the head-end nodes/controllers can use this

Information instead of depending on non-standard mechanisms. IMO, this was needed many years ago.

It’s not a good idea to couple protocol enablement with application specific attribute because application specific link attribute sub-tlv may not be generated in
Deployments which do not need the feature.


From: Isis-wg [] On Behalf Of Sami Boutros
Sent: Friday, October 13, 2017 3:28 AM
Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te- protocols

Given the revised text in<> section 6, is this draft still needed?


-----Original Message-----
From: Isis-wg [] On Behalf Of Christian
Sent: Friday, October 06, 2017 7:43 PM
Subject: [Isis-wg] WG Adoption poll for
draft-hegde-isis-advertising-te- protocols
Hi Folks,
The authors have requested the IS-IS WG adopt
as a working group document. Please indicate your support or
no-support for taking on this work.
Authors: Please indicate your knowledge of any IPR related to this
work to the list as well.
Chris & Hannes.

Isis-wg mailing list<>