Rob/Peter,
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. Rgds Shraddha -----Original Message----- From: Rob Shakir [mailto:r...@rob.sh] Sent: Monday, December 29, 2014 3:11 PM To: Shraddha Hegde Cc: Peter Psenak; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; ospf@ietf.org; isis...@ietf.org Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions > On 29 Dec 2014, at 09:33, Shraddha Hegde <shrad...@juniper.net> 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. r. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
