[Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Tue, 17 July 2018 11:13 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 76535130E11; Tue, 17 Jul 2018 04:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vABD6DLmiOpB; Tue, 17 Jul 2018 04:13:29 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46246130DDB; Tue, 17 Jul 2018 04:13:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2377; q=dns/txt; s=iport; t=1531826009; x=1533035609; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=rlQbIpjP8HLPpHl3DnaMusIKAuW+Gf0FOqgq2704tjY=; b=dzrOgVtrEiZWOhAqzsGtqG5xYjFZj4jQ/QaLWeIjYcenicPyWjsjJPl+ yvMfU3hFhQlpC8m9wokIVTflinbuBqTZ/iV2n6IYe6gokI33bUsxYLfQH EDU1Q1K8dcQdPflnRbxT5770KwFWcULzVvD454b5cUTTJ5ZLhdonE/j/U o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAAA8zk1b/49dJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMbLoFiMot3jDyXRYF6CgGEbIJsITQYAQIBAQIBAQJtKIV?= =?us-ascii?q?3PxIBGiRCFw8BBAENDROFBawQikWJAoFXP4EQjWMCkVGICwkCgT6NX4FLhBG?= =?us-ascii?q?IEZFtAhEUgSQdOIFScBU7gmqCJBeOF40UgRoBAQ?=
X-IronPort-AV: E=Sophos;i="5.51,365,1526342400"; d="scan'208";a="144305727"
Received: from rcdn-core-7.cisco.com ([]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2018 11:13:28 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com []) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w6HBDSW2006230 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jul 2018 11:13:28 GMT
Received: from xch-aln-008.cisco.com ( by XCH-RCD-009.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 17 Jul 2018 06:13:27 -0500
Received: from xch-aln-008.cisco.com ([]) by XCH-ALN-008.cisco.com ([]) with mapi id 15.00.1320.000; Tue, 17 Jul 2018 06:13:27 -0500
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "uma.chunduri@huawei.com" <uma.chunduri@huawei.com>, "lsr@ietf.org" <lsr@ietf.org>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: Concerns with draft-chunduri-lsr-isis-preferred-path-routing
Thread-Index: AdQdvIF2mtuL/a9RTae0GqOPQrjRDA==
Date: Tue, 17 Jul 2018 11:13:27 +0000
Message-ID: <5a180e3dc86047beb3991ad8b1d6d54d@XCH-ALN-008.cisco.com>
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: <https://mailarchive.ietf.org/arch/msg/lsr/LAKFf4MCerg0IUmFUjjJ29IwkEM>
Subject: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2018 11:13:32 -0000

Hi Uma,

I would like share more context on the concerns that I raised on this proposal in LSR WG yesterday where we could not complete our discussion on the mike due to time constraints.

IGPs were originally invented for topology computation and then route programming based on the SPT computed. We've extended IGPs to carry/flood information and this includes information that were meant for various applications. IGPs always do distribute topology computation - that is the core principle.

The PPR proposal takes IGPs into the area of flooding p2p paths and then setting up forwarding state along the path - essentially introducing path provisioning capabilities into it. Essentially adding a new functionality that is NOT distributed topology computation.

For clarity, I could summarize the PPR as follows (please correct if wrong):
- Someone (head-end or controller) computes a SR Path which is expressed as a SID List (it's a list of EROs just like in RSVP-TE - loose or strict)
- The head-end floods this SR Path (and its EROs) into the IGP domain so all routers in the area get the P2P paths computed by all head-ends
- Each router then must look at every such SR Path flooded by every router and examine if it is part of the ERO list; if so then it needs to program the forwarding state for that PPR id (aka label)
- The headend can then just look at this like a "tunnel" and do something like IGP shortcut to the destination behind it

This is picking EROs from RSVP-TE and putting them into IGPs for flooding p2p path state pervasively. Consider the kind of flooding scale and challenges when all these SR Paths go to every router irrespective of whether they need/use it. Then on top of that, we are proposing IGPs to program a local cross-connect if they are on that SR Path.

My question is, why not just use RSVP-TE in this case? RSVP-TE does signalling but it does it only on the nodes that matter for a specific LSP. 

This is called SR but it introduces a forwarding state on each of the hops (i.e. the PPR label cross-connect) - something different from SR architecture. Including SPRING group as well for the review of this proposed SR solution.

Seems like a mishmash of SR and RSVP-TE to me and I am concerned about where this takes IGPs.