[c-nsp] Incremental SFP (ISPF) - Provide any benefits "now"?

[CiscoNSP List]

Hi,


Quick question re ISPF - Seems to be a very old feature (Introduced 12.0?) that was more "efficient" than full SPF algorithm (Allows OSPF to converge faster)...but it appears Cisco are deprecating it, and I can only assume because it is no longer necessary on today's faster hardware?


Does anyone use it? Find it actually improves convergence?


Cheers
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[a***@netconsultings.com]

Hi,

> CiscoNSP List
> Sent: Friday, December 16, 2016 9:55 AM
>
> Hi,
>
>
> Quick question re ISPF - Seems to be a very old feature (Introduced 12.0?)
> that was more "efficient" than full SPF algorithm (Allows OSPF to converge
> faster)...but it appears Cisco are deprecating it, and I can only assume
> because it is no longer necessary on today's faster hardware?
>
What gives you the impression that cisco is deprecating iSPF please?
I think that at most they are deprecating the knob not the functionality.

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::



_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[CiscoNSP List]

Hey Adam - Have a TAC case open atm on ASR920 rLFA FRR (Tunnels being created, when they shouldnt, and not used)...anyway, from this case, MPLS, OSPF + ASR920 Dev teams have been working on it, and they have stated that "ISPF conf under router ospf is not recommended anymore. The command will soon be deprecated." - Its not related to the tac case, its was just a recommendation from them....I asked why is it being deprecated, and the reason they gave is that was introduced to improve convergence on slower processors, processors are fast now, so it is no longer needed.....somewhat strange, but I pressed them for more info, and that is all that they have provided so far...


________________________________
From: ***@netconsultings.com <***@netconsultings.com>
Sent: Friday, 16 December 2016 11:31 PM
To: 'CiscoNSP List'; cisco-***@puck.nether.net
Subject: RE: [c-nsp] Incremental SFP (ISPF) - Provide any benefits "now"?

Hi,

> CiscoNSP List
> Sent: Friday, December 16, 2016 9:55 AM
>
> Hi,
>
>
> Quick question re ISPF - Seems to be a very old feature (Introduced 12.0?)
> that was more "efficient" than full SPF algorithm (Allows OSPF to converge
> faster)...but it appears Cisco are deprecating it, and I can only assume
> because it is no longer necessary on today's faster hardware?
>
What gives you the impression that cisco is deprecating iSPF please?
I think that at most they are deprecating the knob not the functionality.

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::



_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[James Bensley]

On 16 December 2016 at 14:01, CiscoNSP List <***@hotmail.com> wrote:
> Hey Adam - Have a TAC case open atm on ASR920 rLFA FRR (Tunnels being created, when they shouldnt, and not used)...anyway, from this case, MPLS, OSPF + ASR920 Dev teams have been working on it, and they have stated that "ISPF conf under router ospf is not recommended anymore. The command will soon be deprecated." - Its not related to the tac case, its was just a recommendation from them....I asked why is it being deprecated, and the reason they gave is that was introduced to improve convergence on slower processors, processors are fast now, so it is no longer needed.....somewhat strange, but I pressed them for more info, and that is all that they have provided so far...
>

In the case of IP FRR (r)LFA, iSPF is not a recommended setting under
OSPF. When there is a failure with FRR LFA enabled, my understanding
is that traffic will re-route via the backup LSP however the entire
OSPF DB needs to be crawled as a new backup tunnel(s) needs to be
calculated now, iSPF could hinder this process because not all
possible paths would be explored in the OSPF DB, instead the first
"suitable" match would be used. That is what Cisco had lead me to
believe although it was unclear at the time so happy to be corrected
here.

There is a note on the Cisco doc's that says something like "The
OSPF/ISIS configuration option "ispf" is not recommended although it
is supported" with no further explenation so that we may decide whats
best for us :s

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[a***@netconsultings.com]

Hi James,

> James Bensley
> Sent: Wednesday, December 21, 2016 10:06 AM
> To: cisco-***@puck.nether.net
> Subject: Re: [c-nsp] Incremental SFP (ISPF) - Provide any benefits "now"?
>
> On 16 December 2016 at 14:01, CiscoNSP List <***@hotmail.com>
> wrote:
> > Hey Adam - Have a TAC case open atm on ASR920 rLFA FRR (Tunnels being
> created, when they shouldnt, and not used)...anyway, from this case, MPLS,
> OSPF + ASR920 Dev teams have been working on it, and they have stated
> that "ISPF conf under router ospf is not recommended anymore. The
> command will soon be deprecated." - Its not related to the tac case, its
was
> just a recommendation from them....I asked why is it being deprecated, and
> the reason they gave is that was introduced to improve convergence on
> slower processors, processors are fast now, so it is no longer
> needed.....somewhat strange, but I pressed them for more info, and that is
> all that they have provided so far...
> >
>
> In the case of IP FRR (r)LFA, iSPF is not a recommended setting under
OSPF.
> When there is a failure with FRR LFA enabled, my understanding is that
traffic
> will re-route via the backup LSP however the entire OSPF DB needs to be
> crawled as a new backup tunnel(s) needs to be calculated now, iSPF could
> hinder this process because not all possible paths would be explored in
the
> OSPF DB, instead the first "suitable" match would be used. That is what
Cisco
> had lead me to believe although it was unclear at the time so happy to be
> corrected here.
>
Hmmm, I'm not entirely convinced, as the LFA/rLFA is not a matter of a
simple iSPF calculation but rather:
P-space; SPF rooted at S.
Extended P-space; SPF rooted at neighbours of S.
Q-space, rSPF rooted at E (for each protected prefix).

So I'd assume that iSPF is used solely in case of primary path computation
not for LFA/rLFA selection.
But who knows...


adam


netconsultings.com
::carrier-class solutions for the telecommunications industry::

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[CiscoNSP List]

Thanks James - Very Interesting re iSPF and FRR....Ill try removing this under maintenance window, and see if fixes the issue.


The latest on the IP FRR rLFA is that TAC/Dev have asked me to "try" removing fast-reroute keep-all-paths from OSPF (Why? They think that this command is the reason behind unused rLFA tunnel).....how? not entirely sure....Its nice for troubleshooting/debugging to see the list of candidate repair paths that were considered)....but, Ill remove it, and see if it makes any difference.


Cheers


________________________________
From: cisco-nsp <cisco-nsp-***@puck.nether.net> on behalf of James Bensley <***@gmail.com>
Sent: Wednesday, 21 December 2016 9:06 PM
To: cisco-***@puck.nether.net
Subject: Re: [c-nsp] Incremental SFP (ISPF) - Provide any benefits "now"?

On 16 December 2016 at 14:01, CiscoNSP List <***@hotmail.com> wrote:
> Hey Adam - Have a TAC case open atm on ASR920 rLFA FRR (Tunnels being created, when they shouldnt, and not used)...anyway, from this case, MPLS, OSPF + ASR920 Dev teams have been working on it, and they have stated that "ISPF conf under router ospf is not recommended anymore. The command will soon be deprecated." - Its not related to the tac case, its was just a recommendation from them....I asked why is it being deprecated, and the reason they gave is that was introduced to improve convergence on slower processors, processors are fast now, so it is no longer needed.....somewhat strange, but I pressed them for more info, and that is all that they have provided so far...
>

In the case of IP FRR (r)LFA, iSPF is not a recommended setting under
OSPF. When there is a failure with FRR LFA enabled, my understanding
is that traffic will re-route via the backup LSP however the entire
OSPF DB needs to be crawled as a new backup tunnel(s) needs to be
calculated now, iSPF could hinder this process because not all
possible paths would be explored in the OSPF DB, instead the first
"suitable" match would be used. That is what Cisco had lead me to
believe although it was unclear at the time so happy to be corrected
here.

There is a note on the Cisco doc's that says something like "The
OSPF/ISIS configuration option "ispf" is not recommended although it
is supported" with no further explenation so that we may decide whats
best for us :s

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
cisco-nsp Info Page - puck.nether.net<https://puck.nether.net/mailman/listinfo/cisco-nsp>
puck.nether.net
cisco-nsp -- list for people using cisco in a NSP (Network service provider) environment About cisco-nsp



archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/