Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Shraddha Hegde <> Mon, 29 December 2014 10:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8BCD1A008B; Mon, 29 Dec 2014 02:12:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5FFgj7hLweI3; Mon, 29 Dec 2014 02:12:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C58721A007D; Mon, 29 Dec 2014 02:12:22 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 29 Dec 2014 10:12:20 +0000
Received: from ([]) by ([]) with mapi id 15.01.0049.002; Mon, 29 Dec 2014 10:12:20 +0000
From: Shraddha Hegde <>
To: Rob Shakir <>, Peter Psenak <>
Thread-Topic: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
Date: Mon, 29 Dec 2014 10:12:20 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
authentication-results: spf=none (sender IP is );
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1382;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1382;
x-forefront-prvs: 0440AC9990
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(51704005)(189002)(377454003)(199003)(99286002)(68736005)(2900100001)(33656002)(31966008)(20776003)(64706001)(46102003)(106356001)(2950100001)(66066001)(102836002)(107046002)(19580405001)(40100003)(62966003)(99396003)(93886004)(54606007)(230783001)(120916001)(74316001)(76576001)(101416001)(86362001)(97736003)(50986999)(2656002)(76176999)(54206007)(92566001)(77156002)(87936001)(122556002)(4396001)(21056001)(19580395003)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1382;; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2014 10:12:20.4385 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1382
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Dec 2014 10:12:26 -0000


 I think today there are networks which run only on SPF paths and having a facility of "unprotected node-sid" is useful in my opinion 
Rather than not providing such a facility in the protocol at all.

I agree that if there is no sufficient interest on the list it can be dropped. 
I hope we can wait until the holiday season to get over to hear others opinion on this.


-----Original Message-----
From: Rob Shakir [] 
Sent: Monday, December 29, 2014 3:11 PM
To: Shraddha Hegde
Cc: Peter Psenak;;;;
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

> On 29 Dec 2014, at 09:33, Shraddha Hegde <> wrote:
> <Shraddha> It is likely that some application wants to use the node-sids when the strict path for performance sensitive traffic matches with that of the SPF  for some segments or for the entire path. 

There is nothing stopping it doing so, but it cannot deterministically say that the path will remain coherent with the one that it expects for multiple reasons:

1) Nodes along the path may select a subset of ECMPs, the performance of which may vary.
2) There may be topology changes (triggered by failure or not) which mean that the shortest-path may change.

Given that either of these can result in performance variance, it’s very likely (from a practical standpoint) that the traffic must be able to live with FRRs too - hence it being unclear to me that there’s a requirement for an ‘unprotected’ Node SID.