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

[Dhamija Amit]

Adding CC once again 
 


--- On Tue, 1/15/13, Dhamija Amit <amiitdhamija at yahoo.com> wrote:

> 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>
> Cc: cisco-nsp at puck.nether.n
> Date: Tuesday, January 15, 2013, 8:40 AM
> Hi Oliver
> 
> I was testing NSR ( NSF - CIsco) in IOS-XR in GSR and CRS ,
> However i am able to see the LSP-DB's syncing in both the
> routers.
> 
> RP/0/8/CPU0:cr2.BLB#sh isis checkpoint lsp
> Tue Jan 15 05:49:21.676 IST
> 
> IS-IS COLT checkpoint LSPs
> Level  LSPID           
>       Chkpt ID
>   2    crs1.BLB.00-00     
>    80002c38
>   2    cr2.BLB.00-00     
>     80002c18
>   2   
> dr2.blb-ASR1004.00-00   80002bf8
>   2    vrr2.BLB.00-00     
>    80002bd8
>   1   
> SAR3-test7.blb.00-00   80002bb8
>   1    crs1.BLB.00-00     
>    80002b98
>   1    cr2.BLB.00-00     
>     80002b78
>   1   
> pr1.BLB-7206G1.00-00   80002b58
>   1    dr1.blb:inet.00-00 
>    80002b38
>   1    cng1.BLB.00-00     
>    80002b18
>   1    dr1.blb.00-00     
>     80002af8
>   1    sar4.BLB-re1.00-00 
>    80002ad8
>   1    sar5.BLB.00-00     
>    80002ab8
> 
>  Total LSP count: 13 (L1: 9, L2 4, local L1: 1, local L2 1)
> RP/0/RP1/CPU0:crs1.BLB#sh isis checkpoint lsp
> Tue Jan 15 06:09:50.825 IST
> 
> IS-IS COLT checkpoint LSPs
> Level  LSPID           
>       Chkpt ID
>   2    crs1.BLB.00-00     
>    80002e98
>   2    cr2.BLB.00-00     
>     80002e78
>   2   
> dr2.blb-ASR1004.00-00   80002e58
>   2    vrr2.BLB.00-00     
>    80002e38
>   1   
> SAR3-test7.blb.00-00   80002e18
>   1    crs1.BLB.00-00     
>    80002df8
>   1    cr2.BLB.00-00     
>     80002dd8
>   1   
> pr1.BLB-7206G1.00-00   80002db8
>   1    dr1.blb:inet.00-00 
>    80002d98
>   1    cng1.BLB.00-00     
>    80002d78
>   1    dr1.blb.00-00     
>     80002d58
>   1    sar4.BLB-re1.00-00 
>    80002d38
>   1    sar5.BLB.00-00     
>    80002d18
>  Total LSP count: 13 (L1: 9, L2 4, local L1: 1, local L2 1)
> 
> Just to make sure LSPDB syncing is happening with NSF cisco
> style .Is this something newly added??
> 
> Thanks
> Amit 
> 
> --- 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>
> > Cc: "cisco-nsp at puck.nether.net"
> <cisco-nsp at puck.nether.net>
> > Date: Thursday, January 10, 2013, 1:00 PM
> >  
> > 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
> > >> 
> > >> 
> > >> 
> > 
> >
>