[c-nsp] Difference between ISIS NSR and ISIS NSF Cisco-Style

[Oliver Boehmer (oboehmer)]

Hi,

well, I am not aware of any plans to implement ISIS NSR which would sync
LSPDB to standby in IOS or IOS-XR, something which would not need the CSNP
to rebuild the LSDB upon failover.
So don't think we can fix this on our side if your ERX doesn't support the
official "nsf ietf". Maybe you can check j-nsp if there is a solution? If
I recall correctly, there is successful "nsf cisco" interop with JunOS
(M/MX/T series), so possibly something specific to JunosE?

	oli
 



>
>> From: Dhamija Amit <amiitdhamija at yahoo.com>
>> Subject: Re: [c-nsp] Difference between ISIS NSR and ISIS NSF
>>Cisco-Style
>> To: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
>> Date: Thursday, January 10, 2013, 12:32 PM
>> Hi Oli,
>> 
>> Many Thanks for your prompt response.
>> 
>> We have one interop issue where my peer is Juniper ERX
>> which doesn't support NSF IETF implementation , So we are
>> testing NSF cisco style where cisco router sends special LSP
>> a CSNP packet (purpose of sending special LSP is to get all
>> the valid LSP's from neigh.)and juniper ERX is not
>> understanding and is not sending PSNP is response to
>> CSNP and since delivery of ISIS is unreliable cisco needs
>> PSNP which he didnt get and after few number of tries it
>> reset the adj. 
>>  
>> My concern is there is no seperate NSR for ISIS in cisco ,
>> only nsf cisco is NSR .NSR is a local mechanism  but still
>> some-how in this scenario we have to depend upon neighbour.
>> So that's why i would like to understand in NSR do we really
>> need some refresh mechanism from neighbour or is it purely
>> independent.
>> 
>> Also you mentioned in nsf cisco-style only adjacency table
>> is synced with standby RP , However in actuall NSR both adj
>> table & LSDB will be synced.
>> 
>> So if we have NSR implementation ( with both LSDB & Adj)
>> syncing to standby , then still do we need to depend on
>> neighs.
>> 
>> Thanks.
>>   
>> --- On Thu, 1/10/13, Oliver Boehmer (oboehmer) <oboehmer at cisco.com>
>> wrote:
>> 
>> 
>> From: Oliver Boehmer (oboehmer) <oboehmer at cisco.com>
>> Subject: Re: [c-nsp] Difference between ISIS NSR and ISIS
>> NSF Cisco-Style
>> To: "Dhamija Amit" <amiitdhamija at yahoo.com>,
>> "cisco-nsp at puck.nether.net"
>> <cisco-nsp at puck.nether.net>
>> Date: Thursday, January 10, 2013, 11:54 AM
>> 
>> 
>> 
>> 
>> >I would like to know the difference between actuall ISIS
>> NSR and ISIS NSF
>> >cisco style.
>> > 
>> >Most documentation says they are same , however thereare
>> some differences
>> >also and it's not real  NSR. Also i have seen in some
>> packet sniffer in
>> >cisco style cisco router sends a dummy special CSNP
>> packet to neighbour
>> >to get all the valid LSP's in database.
>> > 
>> >Will NSR also depends upon some refresh information from
>> Neighbours ??
>> 
>> Which ISIS NSR implementation are you referring to?
>> 
>> I am asking as folks actually call "isis nsf cisco"
>> "Non-Stop Routing".
>> There is a point as this NSF/GR implementation indeed does
>> not require any
>> special help of the neighbours (the special CSNP packet
>> triggering the
>> neighbours to send all their LSPs is just regular ISIS
>> protocol
>> mechanism), unlike BGP GR or OSPF GR which requires protocol
>> extensions.
>> So it is likely an academic discussion if "nsf cisco" is a
>> creative GR or
>> an NSR implementation. From a design standpoint, "nsf cisco"
>> does not
>> require any new function/config on the neighbors, so there
>> is no
>> difference. That's at least how I look at it.
>> 
>> a "real" ISIS NSR implementation would require to sync the
>> complete LSP
>> database between active and standby RP, not only the
>> adjacency table which
>> is synced with "nsf cisco". But what would be the benefit to
>> your
>> network/services/design over "nsf cisco"?
>> 
>>     oli
>> 
>> 
>>