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

"Les Ginsberg (ginsberg)" <> Thu, 12 October 2017 14:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40EBD132D4E; Thu, 12 Oct 2017 07:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 NlG16yBbJEwv; Thu, 12 Oct 2017 07:43:39 -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 DF60D132A1A; Thu, 12 Oct 2017 07:43:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6207; q=dns/txt; s=iport; t=1507819418; x=1509029018; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6SC4gL9DfeCYMChIAqbKv4r6QTQfvY+cYwsKlrZkuho=; b=Fx1cujOvLZ24b81PZt3u1OBZe4rOIE2AkOvC8/lC4AJxrGPJ7htpvttB kEIurBlTC3ZET4WcUvkxWlJvNpPoGxkiyoSsWSTCyESghcLpIBnM41QyP gzeqz9kHk/4QTOH3M9hnKdfj30s9CZPjIoAu1qYyMEOXRfB4h7adxMMBo 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAABcft9Z/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg11kbicHjhKPLoF2li+CEgolhRYChDw/GAECAQEBAQEBAWsohR0?= =?us-ascii?q?BAQEEOjQEBwwEAgEIDgMEAQEfCQcyFAkIAgQBDQUIE4oDEKxIizgBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYMtggeBUYFpAYMqhSuFTgWKFpcuAodcjQOCHYV0iwi?= =?us-ascii?q?VPgIRGQGBOAEfOIEOeBVJhx12AYpHgREBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,366,1503360000"; d="scan'208";a="306985386"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2017 14:43:37 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v9CEhbhQ018259 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Oct 2017 14:43:37 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 12 Oct 2017 09:43:36 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 12 Oct 2017 09:43:36 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Christian Hopps <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
Thread-Index: AQHTPxYHrHG571lUpkWJFBhDImQkMqLgUX7A
Date: Thu, 12 Oct 2017 14:43: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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: Thu, 12 Oct 2017 14:43:41 -0000

In August of 2017 the IS-IS WG adopted draft-ietf-isis-te-app (formerly draft-ginsberg-isis-te-app) as a WG document.

This happened after extended debate between the proponents of draft-ginsberg-isis-te-app/draft-hegde-isis-advertising-te-protocols, multiple presentations at several IETFs, and considerable WG input both on the mailing list and at WG meetings.

This SHOULD have put this debate behind us so that the WG could focus on refining the adopted solution and getting it ready for deployment - but it seems we have taken a giant step backwards.

Let's look at the content of the latest version: [HEGDE]
 and see what if anything has yet to be addressed by the current WG document  [GINSBERG]

1)Explicit and unambiguous indication of TE protocol

Section 1 of [HEGDE] details an interoperability issue which exists in networks today i.e., different implementations infer RSVP-TE enablement on a link based on different advertised TE attributes.

Why does this problem exist? It exists because the link attribute advertisements (defined primarily in RFC 5305) sometimes are used by applications other than RSVP-TE. It can therefore be ambiguous as to whether advertisement of TE link attributes indicates that RSVP is enabled on that link or not. Different implementations have made different assumptions as to what indicates RSVP-TE enablement - this is detailed very clearly in Figure 1 of [HEGDE].

[GINSBERG] resolves this issue by associating an explicit application bit mask with link attribute advertisements. Currently defined applications include:

  Segment Routing Traffic Engineering
  Loop Free Alternate

The solution is extensible to additional applications as needed.

As a result, the interoperability issue regarding RSVP enablement is resolved. If, for a given link, there exists a set of link attribute advertisements with the "RSVP-TE bit" set, then RSVP has been enabled on that link. If there are no advertisements with the RSVP-TE bit set then RSVP has NOT been enabled on that link.

This also resolves any ambiguity as to whether a given link attribute advertisement can or should be used by an application other than RSVP-TE e.g., the usage described in [HEGDE] Section 1:

"...IP/LDP fast-reroute using loop-free alternates as described in [RFC7916]"

is now also explicit because there is a bit defined specific to that application.

A new version of draft-ietf-isis-te-app has been published which clarifies the relationship between application specific link attribute advertisements and application enablement.

2)Segment Routing Forwarding Support on a Link

Section 3.2 of [HEGDE] asserts that a centralized application/ingress router requires knowledge of SR-MPLS forwarding support on a given link. This is true, but Section 3.1 already states:

"I-Flag: MPLS IPv4 flag.  If set, then the router is capable of
 processing SR MPLS encapsulated IPv4 packets on all interfaces.

 V-Flag: MPLS IPv6 flag.  If set, then the router is capable of
 processing SR MPLS encapsulated IPv6 packets on all interfaces."

Therefore, link level SR-MPLS support can be inferred from the SR Capability advertisement which an SR capable router sends.

If the authors of [HEGDE] wish to argue that there is a use case for a node enabling MPLS(sic) on only a subset of its interfaces, then the correct problem to solve is not SR specific but generic to the use of MPLS i.e., such a use case could be equally applicable to an LDP deployment. Further, this issue affects non-TE traffic as well i.e., IGPs would have to compute and install different paths for IP traffic vs MPLS traffic. This issue is therefore out of scope for both [HEGDE] and [GINSBERG]. 

NOTE: In the many years of MPLS deployment there has been no need to address this issue. A real world deployment requirement is then a prerequisite and any solution belongs in a draft with an MPLS centric context.

3)Backwards compatibility

Both [HEGDE] and [GINSBERG] define new advertisements which will not be understood by legacy routers. Full realization of the benefits of either solution therefore require full deployment of the protocol extensions.

In the interim, [HEGDE] proposes to require use of administrative group configurations on all routers (legacy and new). This has a distinct disadvantage in that the presence of routers supporting the extensions defined in [HEGDE] configuration changes will be required on legacy routers. 

[GINSBERG] however supports a legacy mode which requires no configuration changes on legacy routers.


[HEGDE] adds no value over what is defined in [GINSBERG] - its new advertisements would be redundant given what is advertised by the extensions defined in [GINSBERG]. There is therefore no reason to adopt [HEGDE] as a WG document.


> -----Original Message-----
> From: Isis-wg [] On Behalf Of Christian
> Hopps
> Sent: Friday, October 06, 2017 7:43 PM
> To:
> Cc:;; draft-hegde-isis-advertising-te-
> 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.
> Thanks,
> Chris & Hannes.