Subject: [Isis-wg] LSP Purges

From: Anshuman <[email-masked]>
Date: Wed, 25 Sep 2013 06:17:48 +0100 (BST)

Hi,

As per http://tools.ietf.org/html/rfc6232, its usually an implementation issue that results in an IS initiating a purge of LSPs that some other IS had generated.

I am trying to understand a valid scenario when an IS would want to purge LSPs generated by some other IS.

In fact, i would like to understand when somebody would issue a command like "clear isis database purge" (on Juniper).

Thanks, Anshuman

---

From: Anshuman <[email-masked]>
Date: Wed, 25 Sep 2013 06:40:00 +0100 (BST)

Hi,

ANd i understand that an IS can initiate a purge if it finds a corrupted LSP. What are the other scenarios? Why would somebody explicitly want to purge the LSP?

Thanks, Anshuman

----- Original Message -----
> From: Anshuman <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: 
> Sent: Wednesday, 25 September 2013, 10:47
> Subject: [Isis-wg] LSP Purges
> 
> Hi,
> 
> As per http://tools.ietf.org/html/rfc6232, its usually an implementation issue 
> that results in an IS initiating a purge of LSPs that some other IS had 
> generated.
> 
> In fact, i would like to understand when somebody would issue a command like 
> "clear isis database purge" (on Juniper).
> 
> Thanks, Anshuman
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: Tony Li <[email-masked]>
Date: Tue, 24 Sep 2013 22:42:49 -0700

> In fact, i would like to understand when somebody would issue a command like "clear isis database purge" (on Juniper).

Stuff Happens.

Someone misconfigures a router and imports all of their BGP routes into IS-IS.  That router crashes.  It gets reconfigured.  In the meantime, the entire network has a major case of LSP indigestion.   How do you clean out your network?

Tony

---

From: Qin Wu <[email-masked]>
Date: Wed, 25 Sep 2013 06:06:31 +0000

See RFC1142, when IS resigns as Designated IS, it will initiate a purge, when adjacency is taken down, the IS can initiate purge,
When lifetime field is zero, the IS will initiate a purge.

In worse case, it will cause purge storm, RFC6232 provides a way to locate who flooded the purged LSP.

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anshuman
Sent: Wednesday, September 25, 2013 1:40 PM
To: [email-masked]
Subject: Re: [Isis-wg] LSP Purges

Hi,

Thanks, Anshuman

---

From: "A. Przygienda" <[email-masked]>
Date: Wed, 25 Sep 2013 08:20:38 +0200

> Someone misconfigures a router and imports all of their BGP routes into IS-IS.  That router crashes.  It gets reconfigured.  In the meantime, the entire network has a major case of LSP indigestion.…
Or seen from a higher ground, a dynamic, distributed routing system of
systems is basically one big thing with tons of feedback loops that
generate strange attractors rather than completely predictable stable
states.  Yes, I know, the routing table is predictable if all goes well
but who issued how many LSPs how often & how often elections ran & so on
is pretty much chaotic & in this respect the systems ends up in one of
the 'semi-stable' attractors.

That is, if all goes well, many things can and do go wrong and as in any
chaotic system the system of systems may end up bouncing between two
semi-stable states. The cases sound hypothetical (until you lived
through them ;-).  Reseting a single system's state may not resolve the
problem & that's when you need to purge other  systems' state.

There was a famous one on OSPF where all Cascade switches had to be
rebooted in sequence. Before that I think the fuzzballs once had all to
be shut down one-by-one and new software put on since there was
sequence-number roll-over bug/optimization that put the whole system
into unusable stable strange attractor.  Corrupt LSPs in ISIS (and later
in OSPF with extensions as I pointed on the list there) were actually
not that uncommon as one may think. I think Radia documented that one in
a book or something like this.

Well, point of my rant (and I think JNPR were the first to come up with
the idea) is that in a link-state routing system it is sometimes a Good
Thing (that's Tony Li's TM by the way ;-)  to be able to wipe other
people's state you rely on. Brutally & efficiently so. 

In BGP it's kind of natural, purging a peer (and all the state it fed
you) feels natural but in link-state, because it's couple of hops away
you got the stuff from, there were initial inhibitions.

;-)

--- tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 25 Sep 2013 07:07:12 +0000

Hmmm...this seems an opportune moment to remind folks NOT to "see RFC1142" - look at ISO 10589 instead.

http://datatracker.ietf.org/doc/draft-ietf-isis-rfc1142-to-historic/

(Apologies Qin - you are not the first and likely not the last...)

   Les

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Qin Wu
> Sent: Tuesday, September 24, 2013 11:07 PM
> To: Anshuman; [email-masked]
> See RFC1142, when IS resigns as Designated IS, it will initiate a purge, when
> adjacency is taken down, the IS can initiate purge,
> ANd i understand that an IS can initiate a purge if it finds a corrupted LSP.
> What are the other scenarios? Why would somebody explicitly want to purge the
> LSP?
> 
> Thanks, Anshuman
> 
> 
> > I am trying to understand a valid scenario when an IS would want to purge
> LSPs
> > generated by some other IS.
> >

---

From: Qin Wu <[email-masked]>
Date: Wed, 25 Sep 2013 07:17:36 +0000

Right, my fault, thanks for kindly reminder.

Regards!
-Qin
-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, September 25, 2013 3:07 PM
To: Qin Wu; Anshuman; [email-masked]
Subject: RE: [Isis-wg] LSP Purges

   Les

> Anshuman

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 25 Sep 2013 11:15:17 +0200

anshuman,

think of it as the 'steam cleaner' of an IGP.

if your (lab) network got really dirty you may want to
reset it to a pristine state (without all the aged LSPs
in the database).

needless to say, i'd not recommend to initiate a network
wide purge of all our LSDBs LSPs in a production network.
  the 'steam cleaner' could then easily turn into
  a 'weapon of mass destruction' ;-)

/hannes

---

From: "A. Przygienda" <[email-masked]>
Date: Wed, 25 Sep 2013 08:07:35 +0200

;-)

--- tony