Subject: [Isis-wg] operational problem might be solved by somehow extending current IS-IS

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 14 Sep 2010 14:45:18 +0200 (CEST)

Hi.

I'd like to describe two operational practices and how they cause problems 
with our current IS-IS implementation.

1. When we are about to do any major work on a router (for instance now 
lately to patch the BGP bug in IOS XR), we currently set "isis overload" 
which causes most traffic to be removed from the router as all the other 
network considers it to be unavailable for transiting traffic.

2. When we want to do maintenance on a link (or we're having bit errors), 
we before used to shut down ISIS on the interface in question ("isis 
protocol shut"), but since the link might not be totally unavailable, 
we've instead started to raise the ISIS cost/metric on the link (at both 
ends) to remove traffic from it, but still have it available in case there 
is no other path (perhaps due to another failure in the network). This is 
operationally hard since we have to login to both routers which use this 
link, and do the changes on both. This is especially of interest in 
non-p-t-p links/networks, as it's hard to increase cost at "both" ends, 
because there are more than 2 nodes involved.

Basically, what I'd like to see is the way to bidirectionally increase 
cost on a link by just changing the configuration at one end. This would 
ease the number of configuration changes needed in case 2, and I would 
also request my vendor to implement a new command that might be "isis cost 
max" (or "cost avoid") that would actually not replace the current cost 
value but just raise it to a maximum value, but only needing the change 
done at one end.

To solve case 1, instead of using "overload" I'd like to use "max-metric" 
(as done in OSPF) but this would be done to all the links connecting the 
router. This would mean that in case of a BGP failure / process restart, 
ISIS/LDP signalled LSPs wouldn't have to be torn down / re-routed (torn 
down in case of a single homed router behind the router having 
maintenance). If there was a broadcast media, it would make the traffic go 
away from the router if there was any other path.

I don't really know that much about the internals in IS-IS so I don't know 
exactly how much of an issue it would be to solve the issues I've 
described above, but I'd just like to state that this is an area of IS-IS 
that would be great to have improved.

Thanks.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tony Li <[email-masked]>
Date: Tue, 14 Sep 2010 09:39:06 -0700

Hi Mikael,

> Basically, what I'd like to see is the way to bidirectionally increase cost on a link by just changing the configuration at one end. This would ease the number of configuration changes needed in case 2, and I would also request my vendor to implement a new command that might be "isis cost max" (or "cost avoid") that would actually not replace the current cost value but just raise it to a maximum value, but only needing the change done at one end.
> 
> To solve case 1, instead of using "overload" I'd like to use "max-metric" (as done in OSPF) but this would be done to all the links connecting the router. This would mean that in case of a BGP failure / process restart, ISIS/LDP signalled LSPs wouldn't have to be torn down / re-routed (torn down in case of a single homed router behind the router having maintenance). If there was a broadcast media, it would make the traffic go away from the router if there was any other path.

The unidirectional case seems like it is entirely doable within one system and is simply an implementation issue.  You should take this up with YFRV.

What seemed like it would take standardization work is the case of doing things bidirectionally.  

I think that the ptp case is a straightforward mechanism, but I'm not seeing a ton of benefit here.  

I think that there's much more benefit in the Ethernet case.  One way of implementing this would be to simply change all of the costs associated with the pseduonode.  It would be interesting to know if current implementations would be compatible with this.

Thoughts?

Tony

---

From: Shane Amante <[email-masked]>
Date: Tue, 14 Sep 2010 12:09:51 -0600

Tony,

FWIW, I second Mikael's requests, particularly case #2.  See below.

> I think that the ptp case is a straightforward mechanism, but I'm not seeing a ton of benefit here.

Sure there is.  In today's world, routers commonly have several hundred 10G interfaces.  It would be nice to have a dirt-simple mechanism, within the IGP, to confidently isolate both sides of *the same* :-) p2p Backbone link for repair.  In theory, SP's can do this manually or auto-magically (via a script); however, the latter is [extremely] cumbersome to maintain, particularly in a multi-vendor deployment.

> I think that there's much more benefit in the Ethernet case.  One way of implementing this would be to simply change all of the costs associated with the pseduonode.  It would be interesting to kno…

I would agree that this is just as critical to solve for, however, I'll defer to implementers to respond to your question.

-shane

> Thoughts?
> 
> Tony
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Tue, 14 Sep 2010 19:22:30 -0700

Shane,

I doubt this "bi-directional max cost" thing is useful in reality, but it could be harmful,
in particular on the multi-access lan.
When a router is in trouble, it sets itself in 'overload' or like ospf, sets all outbound intf
cost to some huge value; it does not matter the neighbors outbound intf cost(the other direction)
is also adjusted or not, the path computation should not use this router with through traffic
if there is a cheap alternative paths somewhere. If the prefix is on this router, then it also
does not matter the neighbor's intf cost is high or not, the traffic will come to this router.

On a multi-access lan, if you somehow adjust the neighbor's outbound intf cost, or set
this on the pseudo-node(assume this is compatible), since there are multiple nodes on the
LAN. Say A has problem, A, B, C share this lan. Now we will see B can not even go to C since
A has problem. Again this shows there is no reason to change the neighbor's outbound costs
dynamically.

I agree that ospf's way is also useful, as Mikael pointed out, in a single path case traffic can still
come.  But as Tony mentioned, this can be a local implementation issue. One can just have a knob
"overload max-cost xxxx" for the whole router/instance/topology, and default using overload-bit if
not configured.

thanks.
- Naiming

---

From: Shane Amante <[email-masked]>
Date: Tue, 14 Sep 2010 22:36:03 -0600

Naiming,

> does not matter the neighbor's intf cost is high or not, the traffic will come to this router.

First, let's talk about "bi-directional max cost" for the p2p interface case.  I agree that max-metric/cost or overload are useful functions when you want to isolate an entire node (no through/transit traffic), except as you point out for traffic destination _to_ the node.  However, what I (and, I think, Mikael) are talking about is different.  Let's go with the following simplistic example where all links are p2p:

Continent 1 : Continent 2
          :
 A -- B --:-- C
     /|   :   |
    / |   :   |
   /  |   :   |
 D -- E --:-- F
          :

Let's say that I'm experiencing error's on link A-B and I want to temporarily take it out of service for repairs.  First, there's no reason for me to isolate the entire "B" node (using IS-IS overload bit), because that would shift all traffic to/from Continent 2 away from the perfectly OK link B-C and onto link E-F.  Second, if one were to just login to node B and max-metric the interface B -> A that would not prevent upstream nodes (not pictured) in Continent #1 from still seeing a normal IGP metric and still using A -> B -> C to get to Continent #2.  Thus, I also need to login to node A and ensure that I apply a max-metric to interface A -> B, as well, to completely remove all _transit_ traffic through that link.  Note, once this is done it's still possible for D (and, other nodes upstream of D) to use link B-C, just like it's always been doing.

Again, operationally it would be much less error-prone if there was a max-metric capability where B could tell A: "BTW, I just increased my link cost to infinity and I want you to do the same".  Done.

> A has problem. Again this shows there is no reason to change the neighbor's outbound costs

OK, switching subjects to a multi-access LAN.  Correct me if I'm wrong, but a pseudo-node LSP does not carry a metric.  Instead, each router (attached to a multi-access LAN) advertises its own LSP with its own metric to the pseudo-node LSP.  Regardless, I think I agree with you (?) that it's not possible to change the metric on a pseudo-node LSP.  Furthermore, as you point out, you can't bidirectionally change a metric between just two neighbors on a multi-access LAN given that each router is only adjacent to the pseduo-node LSP, not directly to each other router.

So, I suppose the only practical solution for multi-access LAN is for a router Z to withdraw its adjacency to the DIS and then hope the DIS quickly propagates a new pseudo-node LSP to the rest of the network so traffic is no longer directed to router Z through other routers still attached to the pseudo-node LSP.  That would make the potential options available to us as follows:
a)  Disabling IS-IS on router Z's interface attached to the LAN and waiting for the DIS <-> router Z adjacency to timeout (blech, could be upwards of several [tens of] seconds before forwarding completely restores);
b)  Running BFD on the LAN (at least between the DIS and all other routers on the multi-access LAN), but again waiting for BFD to timeout between DIS to router Z (less blech, could be upwards of a few hundred msecs just to notice adjacency is down not including LSP propagation times, SPF recalc, etc.); or,
c)  Understanding if there's a mechanism for router Z to proactively signal "Goodbye" to the DIS: "I'm going down, please remove my adjacency (and remove me from the pseudo-node LSP and flood that pseudo-node LSP immediately, so everyone else knows to recompute SPF and shift traffic somewhere else".  This is likely to translate into several 10's of msecs nationally (more, internationally), and most likely the dominant factor is always going to be propagation delay over the WAN for distant nodes to receive the updated pseudo-node LSP.

Thoughts on (c), or a better suggestion, to reduce the convergence time to more "gently" remove a node's link connected to a multi-access LAN?

Thanks,

-shane

---

From: Tony Li <[email-masked]>
Date: Wed, 15 Sep 2010 00:22:45 -0700

Hi Shane,

> OK, switching subjects to a multi-access LAN.  Correct me if I'm wrong, but a pseudo-node LSP does not carry a metric.  

It carries a metric of zero.  See 7.2.3 of ISO 10589 (2002):

Instead of treating a broadcast subnetwork as a fully connected topology, the broadcast subnetwork is treated as a pseudonode, with links to each attached system. Attached systems shall only report their link to the pseudonode. The designated Intermediate system, on behalf of the pseudonode, shall construct Link State PDUs reporting the links to all the systems on the broadcast subnetwork with a zero value for each supported routeing metric.

> Regardless, I think I agree with you (?) that it's not possible to change the metric on a pseudo-node LSP.  

It's certainly not within spec currently, but then we ARE talking about extensions.  It would be very interesting to know how implementations reacted to this.  I suspect that most would actually process the metric in the usual fashion.  

> Furthermore, as you point out, you can't bidirectionally change a metric between just two neighbors on a multi-access LAN given that each router is only adjacent to the pseduo-node LSP, not directly to each other router.

Exactly why you want to change the metric only in the pseudonode.

> Thoughts on (c), or a better suggestion, to reduce the convergence time to more "gently" remove a node's link connected to a multi-access LAN?

Are we trying to just remove one node's link?  Or are we trying to cost out the entire Ethernet?  I understood the latter.

Tony

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 15 Sep 2010 09:30:30 +0200 (CEST)

On Wed, 15 Sep 2010, Tony Li wrote:

> Are we trying to just remove one node's link?  Or are we trying to cost 
> out the entire Ethernet?  I understood the latter.

My idea was to try to avoid using one node as the gateway out of the 
ethernet.

Also, gracefully phasing out a node from a network is also nice, "isis 
protocol shut" (on Cisco) basically times out, it would be better if it 
made sure it wasn't the (B)DR anymore if it was, told everybody that it 
was going away and then when everybody acknowledged that they were "done" 
with that process, it actually went away. I'd like to see the same thing 
on p-t-p links.

So these are several different enhancements we're talking about, just to 
make sure that I'm not referring to a single thing above.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 15 Sep 2010 09:59:32 +0200 (CEST)

> When a router is in trouble, it sets itself in 'overload' or like ospf, sets all outbound intf

I'm not talking about removing overload, overload has its use-case 
absolutely and I want to keep it.

> does not matter the neighbor's intf cost is high or not, the traffic will come to this router.

This is not about "trouble", this is an administrative action.

> I agree that ospf's way is also useful, as Mikael pointed out, in a 
> single path case traffic can still come.  But as Tony mentioned, this 
> can be a local implementation issue. One can just have a knob "overload 
> max-cost xxxx" for the whole router/instance/topology, and default using 
> overload-bit if not configured.

I agree, but it doesn't solve all problems.

Having a bidirectional cost between the node and the pseudo-node has it's 
use case, and being able to do the same on p-t-p links is also useful. 
These are the changes that will require a standards change, together with 
the removal-from-ISIS mechanism discussed earlier.

The bidirectional cost thing would also be useful in conjunction with 
"MPLS LDP IGP SYNC", as a node which isn't done with it's labels could 
slow the ISIS convergence onto a link by itself without having to rely on 
the other node...

---

From: Mach Chen <[email-masked]>
Date: Wed, 15 Sep 2010 17:37:31 +0800

Hi Mikael,

If understand correctly, you have two requirements? if not, please correct 
me.

1. Simlify the configuration when doing "bidirectional cost" adjustment of a 
link;
2. Graceful shutdown a ISIS router/link/interface;

I think your requirements make sense and such functions (if we have) are 
useful.

Best regards,
Mach

--------------------------------------------------
From: "Mikael Abrahamsson" <[email-masked]>
Sent: Wednesday, September 15, 2010 3:59 PM
To: "Naiming Shen" <[email-masked]>
Cc: "Shane Amante" <[email-masked]>; "Tony Li" <[email-masked]>; 
<[email-masked]>
Subject: Re: [Isis-wg] operational problem might be solved by somehow 
extending current IS-IS

>> single path case traffic can still come.  But as Tony mentioned, this can 
>> be a local implementation issue. One can just have a knob "overload

---

From: mike shand <[email-masked]>
Date: Wed, 15 Sep 2010 11:02:48 +0100

Tony,

     Changing the metric of the pseudonode might be OK, but a likely 
place where implementations might trip up is on prioritising the 
pseudonode when removing from TENT. Do they do this on the basis of it 
being zero cost, or on the basis of it being a pseudonode LSP? Currently 
either will do, of course.

     Mike

-- 
For corporate legal information go to:
www.cisco.com/web/about/doing_business/legal/cri

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 15 Sep 2010 12:25:33 +0200 (CEST)

> I think your requirements make sense and such functions (if we have) are 

I think these two are the ones that will require changes to ISIS protocol, 
the other changes (like max-metric on all interfaces) would be doable 
without change to ISIS itself.

1 should be bidirectional in both the case of p-t-p and broadcast 
media, just so we get that in there as well. I guess the thought here is 
to have a bidirectional cost to the pseudonode in the case of broadcast 
media, so basically different routers would have individual cost to the 
pseudonode and the cost from router to router would be to add these two 
together.

One way of seeing it would be that instead of just having one-way metrics 
on an interface, one would be able to set two metrics, one for incoming 
routes and one for outgoing routes, and for an ISIS adjacency, these two 
would be added together in each direction.

---

From: Guan Deng <[email-masked]>
Date: Wed, 15 Sep 2010 14:36:33 +0200

> Instead of treating a broadcast subnetwork as a fully connected topology, the broadcast subnetwork is treated as a pseudonode, with links to each attached system. Attached systems shall only report…

That is right, so far i understood the pseudonode report always metric 0 
to it's attached system, if pseudonode is reporting a non-0 metric(dont 
know if is possible), but instead a high or max metric towards the
particular problematic node, we could potenially remove this node as 
transit on a LAN segment, without removing this node in IS-IS or setting 
overload bit.

Guan

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Wed, 15 Sep 2010 17:35:32 +0200

> -----Original Message-----
> I think that there's much more benefit in the Ethernet case.  
> One way of implementing this would be to simply change all of 
> the costs associated with the pseduonode.  It would be 
> interesting to know if current implementations would be 
> compatible with this.
> 
> Thoughts?
> 

I don't have access to more resent version of ISO 10589, but the
revision from 1992 says that pseudonode-to-is metric _shall_ be zero. So
potentially non-zero metric in pseudonode LSP could be treated as
malformed. One alternative solution could be introducing new TLV for
"reverse metric" or some kind of "link capability bitmap". When a
compatible router performs SPF calculations it will look at presence of
such TLV and override metric seen in pseudonode LSP.

P.S.: I support with both hands Mike's idea about need for a solution to
the problem

/iLya

---

From: Shane Amante <[email-masked]>
Date: Wed, 15 Sep 2010 11:36:04 -0600

Hi Tony,

> Instead of treating a broadcast subnetwork as a fully connected topology, the broadcast subnetwork is treated as a pseudonode, with links to each attached system. Attached systems shall only report…

Ah, OK.

> It's certainly not within spec currently, but then we ARE talking about extensions.

Agreed.

> It would be very interesting to know how implementations reacted to this.  I suspect that most would actually process the metric in the usual fashion.  
> 
> 

I would like to see both, since I definitely have use cases for both.  The latter is a fairly large (but, useful) sledgehammer, which is good when you're looking to take an entire Ethernet VLAN out-of-service.  However, the former is useful when you're attempting to diagnose a problem in the forwarding path[1] with a particular node attached to that VLAN and there's no (good) reason to take the whole VLAN out-of-service -- call it a gavel.  :-)

That said:
- the two use cases for the multi-access LAN I spoke of above will involve (completely) separate solutions, which IMHO is fine;
- admittedly, the former use case (removing just one node's link on a multi-access LAN bidirectionally) is likely to be used less often in practice compared to the latter use case.  IMO, that doesn't make it any less valuable.

-shane

[1] Typically with the Layer-2 switch sitting in the fwd'ing path between two Layer-2.5 or Layer-3 devices on that LAN.

P.S. -- Related to the use case of isolating a single node, bidirectionally on a VLAN/pseudo-node ... it's surprising why no one hasn't developed a more "graceful" way for an IGP to terminate its adjacency, similar to what BGP can do with a NOTIFICATION message when you issue a "shutdown" for a particular neighbor.  Why don't we have the ability to "shut" IS-IS on an interface attached to a multi-access LAN and have IS-IS do the "nice" thing and send a "Goodbye" to tell the DIS, and others, its outta here so other nodes can immediately remove the fwd'ing state for that path and quickly converge on an alternate path, instead of waiting for the adjacency to timeout?

---

From: Tony Li <[email-masked]>
Date: Wed, 15 Sep 2010 10:37:26 -0700

Mike,

> Changing the metric of the pseudonode might be OK, but a likely place where implementations might trip up is on prioritising the pseudonode when removing from TENT. Do they do this on the basis of it being zero cost, or on the basis of it being a pseudonode LSP? Currently either will do, of course.

I can't speak for all implementations, of course, but under the implementors rubric of keeping things as simple as possible and no simpler, I would guess that they do this purely on the basis of metric.

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 15 Sep 2010 10:47:42 -0700

> Why don't we have the ability to "shut" IS-IS on an interface attached to a multi-access LAN and have IS-IS do the "nice" thing and send a "Goodbye" to tell the DIS, and others, its outta here so other nodes can immediately remove the fwd'ing state for that path and quickly converge on an alternate path, instead of waiting for the adjacency to timeout?

<philosophical>
As with most innovation, it requires someone who is sufficiently irritated, intrigued, unreasonable, or duly compensated to initiate change.  

“The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”  -- George Bernard Shaw

Motivation is everything.
</philosophical>

Tony

---

From: Shane Amante <[email-masked]>
Date: Wed, 15 Sep 2010 12:03:07 -0600

Tony,

> Motivation is everything.

Fair point.  In that case, call me "sufficiently irritated, intrigued & unreasonable" then.  I'll attempt to throw a strawman draft together, related just to the above, in the next few days and circulate for review ... unless someone else already has written one before then?  ;-)

-shane

---

From: Ilya Varlashkin <[email-masked]>
Date: Wed, 15 Sep 2010 21:08:06 +0200

> Fair point.  In that case, call me "sufficiently irritated, intrigued & unreasonable" then.  I'll attempt to throw a strawman draft together, related just to the above, in the next few days and cir…

The problem Mike described was exactly that shutting down ISIS on an interface completely is undesirable, instead the interface should be only used as last resort when everything else fails.

/iLya

---

From: Shane Amante <[email-masked]>
Date: Wed, 15 Sep 2010 13:37:02 -0600

Ilya,

> The problem Mike described was exactly that shutting down ISIS on an interface completely is undesirable, instead the interface should be only used as last resort when everything else fails.

Mikael can clarify, but I'm fairly sure that is because, in current implementations, shutting down IS-IS results in having to wait for the IS-IS adjacency to timeout, before the node is withdrawn from the pseudo-node LSP and the DIS floods a new one -- which in practice translates into upwards of several 10's of seconds, (although it could be better depending on how aggressive one can be with BFD timers).

Instead, if the node leaving the LAN sent a "Goodbye" to the DIS at the time the operator issued a "isis shut" command, the DIS could immediately tear down the adjacency and flood a new pseudo-node LSP, leading to the best possible restoration times.  Although this certainly will not achieve zero packet loss, it should dramatically reduce the packet loss we currently experience when doing "isis shut" on interfaces attached to a LAN.

-shane

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 15 Sep 2010 21:41:32 +0200 (CEST)

On Wed, 15 Sep 2010, Shane Amante wrote:

> Mikael can clarify, but I'm fairly sure that is because, in current 
> implementations, shutting down IS-IS results in having to wait for the 
> IS-IS adjacency to timeout, before the node is withdrawn from the 
> pseudo-node LSP and the DIS floods a new one -- which in practice 
> translates into upwards of several 10's of seconds, (although it could 
> be better depending on how aggressive one can be with BFD timers).
>
> Instead, if the node leaving the LAN sent a "Goodbye" to the DIS at the 
> time the operator issued a "isis shut" command, the DIS could 
> immediately tear down the adjacency and flood a new pseudo-node LSP, 
> leading to the best possible restoration times.  Although this certainly 
> will not achieve zero packet loss, it should dramatically reduce the 
> packet loss we currently experience when doing "isis shut" on interfaces 
> attached to a LAN.

I see the need for both.

When I want to take away a node gracefully this should be done.

There are also scenarios where it's beneficial to have the router/link 
being used just as a last resort and never otherwise. This is for instance 
in the case of a link with bit errors. A link with bit errors shouldn't be 
used in case there is a link without bit errors, but a link with bit 
errors is better than no link at all if there is nothing else available. 
This last reason is why we stopped using "isis protocol shutdown" when 
doing maintenance on links and instead change the cost on both ends of the 
links to a high number, but this is operationally cumbersome on p-t-p 
links and impossible on LANs.

---

From: Ilya Varlashkin <[email-masked]>
Date: Wed, 15 Sep 2010 21:59:13 +0200

> Mikael can clarify, but I'm fairly sure that is because, in current implementations, shutting down IS-IS results in having to wait for the IS-IS adjacency to timeout, before the node is withdrawn f…
Even 60 seconds before the maintenance isn't problem at all, because the router still has all the routes it needs, so even if the ISIS is shut down on the interface the router can still forward traffic it receives from the peers that didn't update their routing tables (and the operator could just wait this 60 seconds before continuing maintenance). And in the event of a crash graceful shutdown ("goodbye" message) not necessarily will be sent at all. And as you've pointed out, BFD can bring those 60 seconds down to sub-second range.

> Instead, if the node leaving the LAN sent a "Goodbye" to the DIS at the time the operator issued a "isis shut" command, the DIS could immediately tear down the adjacency and flood a new pseudo-node…

Why would there be packet loss if we simply shut down ISIS on the interface while keeping the interface itself operational? Unless the interface is faulty.

/iLya

---

From: Shane Amante <[email-masked]>
Date: Wed, 15 Sep 2010 15:03:11 -0600

Ilya,

On Sep 15, 2010, at 13:59 MDT, Ilya Varlashkin wrote:
> Even 60 seconds before the maintenance isn't problem at all, because the router still has all the routes it needs, so even if the ISIS is shut down on the interface the router can still forward traffic it receives from the peers that didn't update their routing tables (and the operator could just wait this 60 seconds before continuing maintenance).

It's called "Principle of Least Astonishment" -- :-)
http://en.wikipedia.org/wiki/Principle_of_least_astonishment
(It's fitting the article mentions by way of example, user's expecting Ctrl-Q to cause a program to quit [immediately], since that's pretty much what we're talking about here).

IOW, I wish I could say I've been successful in training [new] operators that, especially in the heat of the moment when troubleshooting a suspected problem most likely with a customer on the phone, to "shut isis", wait 60 seconds, then test/break that interface, bring the interface back up if it's not faulty and repeat for other interfaces.  :-(

> And in the event of a crash graceful shutdown ("goodbye" message) not necessarily will be sent at all.

All bets are off in the case of crashes, nor did I say that this mechanism would apply in the case of crashes.

> And as you've pointed out, BFD can bring those 60 seconds down to sub-second range.

Unfortunately, in practice, sub-second has typically translated in practice into "just barely under 1 second" if you're lucky, i.e.: with typical legacy equipment, you're lucky to find BFD in SW, but unfortunately running on a [severely] under-powered centralized CPU (and no hope ever of a distributed BFD implementation), thus you need to back way off your Tx/RxInterval and/or Multiplier to avoid false-positive lost BFD packets causing an adjacency to unnecessarily be reset ... queue sprial-of-death. :-(

> Why would there be packet loss if we simply shut down ISIS on the interface while keeping the interface itself operational? Unless the interface is faulty.

Agreed; however, I'm assuming the interface may be faulty (or, the L2 switch in the middle may be partially broken) in which case you'd like to get that interface out of the fwd'ing path as quickly & gracefully as possible.

-shane

---

From: Naiming Shen <[email-masked]>
Date: Wed, 15 Sep 2010 14:35:46 -0700

Shane,

I see there are two things here. One is to 'say goodbye quickly' to neighbor or DIS,
the other is to use the link as last resort if possible.

The first one is quite easy actually with the existing scheme. The interface only needs
to immediately send out the hello without neighbor IS tlv in it. The neighbor or DIS should
immediately remove this adjacency and remove it from the lsp or pseudo-node lsp.
This can be a local implementation thing with a new knob, and this can be done with
L1 or L2 both or separately.

The second one, on p2p there should be no problem, since if one is troubleshooting some
errors on the link, the operators probably are already on both routers and monitoring the
same link, to increase the cost on both side is very natural. On the Lan, it's somewhat
convenient to do this from one place, but as the property of the LAN, it's going to impact
all the nodes on this LAN. Just because router A on the LAN has inbound errors, change
the cost to the whole LAN going to make router B, C and D all become the last resort link,
which may cause unexpected congestions some where else. So it has pros and cons,
the pro is some operational convenience, the con can be unexpected network traffic
patten changes.

thanks.
- Naiming

---

From: Shane Amante <[email-masked]>
Date: Wed, 15 Sep 2010 18:12:46 -0600

Naiming,

Agreed.

> L1 or L2 both or separately.

Great!  That sounds like it could be easily documented in a BCP then, (for other and/or future implementors to reference)?

> same link, to increase the cost on both side is very natural.

I believe the point of Mikael's original e-mail, and what I'm advocating as well, is we need to move beyond the "stone-age tools" we've currently been using to something a little more modern (bronze age? :-).  Hence, it would be preferable to enable this capability in the routing protocol itself.  Said differently, we would greatly appreciate if you made our live's easier, so we could fight other fires.  :-)

> On the Lan, it's somewhat

I think what we settled on in another e-mail was looking at applying (or, increasing) a max-metric to just the pseudo-node LSP in order to shift traffic away from the entire LAN in this case you mention.  I would envision two scenarios for how this could happen in practice:
a)  Operator has to login to router that's a DIS for a LAN and issue a CLI command to have it apply a max-metric to the pseudo-node LSP; or,
b)  Operator can login to any node attached to the LAN and, somehow, signal the DIS to apply a max-metric to the pseudo-node LSP.

Although (b) would be my preference (again for ease of use/understanding reasons), I'm guessing that it's probably significantly more complex than (a).  Thus, I would "settle" for (a) if the WG agrees that's the more straightforward route.

Lastly, to your point of the potential for congestion ... that cat was let out of the bag a long time ago.  See: overload-bit.  :-)

Thanks,

-shane

---

From: Naiming Shen <[email-masked]>
Date: Wed, 15 Sep 2010 17:59:18 -0700

Shane,

> Great!  That sounds like it could be easily documented in a BCP then, (for other and/or future implementors to reference)?

Make sense. I can draft a BCP on this.

> I believe the point of Mikael's original e-mail, and what I'm advocating as well, is we need to move beyond the "stone-age tools" we've currently been using to something a little more modern (bronz…

Ok, you are in "space-age" now, see below.

> Although (b) would be my preference (again for ease of use/understanding reasons), I'm guessing that it's probably significantly more complex than (a).  Thus, I would "settle" for (a) if the WG agr…

I would prefer 'a' then if we want to do this, and this can also be in the same BCP since really there is no
protocol change, which is the best. I would think operators want to do this traffic shifting job, they
at least need to know who is the DIS, and prepare for troubleshooting if there is problem. 'b' is
problematic, since if we don't trust router A's link, then we also should not trust router A send
send out this important message through the link reliably; besides there is an issue of router A and
router B sends different commands and this condition can keep toggling.

thanks.
- Naiming

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Sep 2010 07:07:13 +0200 (CEST)

> Make sense. I can draft a BCP on this.

Another thing that might be valuable for a BCP which I also don't think 
would require a protocol change.

For a p-t-p link, would it make sense to not include the link network in 
the LSDB unless there is actually an adjacancy active on it?

We have the problem with ethernet based links between routers that 
traverse an L2 network where the L2 network might be broken in the middle 
so both routers include the link in their LSDB but the adjacancy is down 
so there is no connectivity. This is mostly an alarm issue.

I'm ok if the recommendation is an additional knob to include this 
behaviour.

---

From: Tony Li <[email-masked]>
Date: Wed, 15 Sep 2010 22:16:02 -0700

On Sep 15, 2010, at 10:07 PM, Mikael Abrahamsson wrote:

> We have the problem with ethernet based links between routers that traverse an L2 network where the L2 network might be broken in the middle so both routers include the link in their LSDB but the adjacancy is down so there is no connectivity. This is mostly an alarm issue.

Hi Mikael,

Could you please say more about the alarm issue?  This case would seem to have little benefit beyond a trivial reduction in LSDB size.

Tony

---

From: Naiming Shen <[email-masked]>
Date: Wed, 15 Sep 2010 22:18:07 -0700

this sounds more like a bug of implementation, do you have specific example?
are you talking about real p2p link or LAN with only two nodes? is there another
parallel link also?

thanks.
- Naiming

On Sep 15, 2010, at 10:07 PM, Mikael Abrahamsson wrote:

> Another thing that might be valuable for a BCP which I also don't think would require a protocol change.
> 
> For a p-t-p link, would it make sense to not include the link network in the LSDB unless there is actually an adjacancy active on it?
> 
> I'm ok if the recommendation is an additional knob to include this behaviour.
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Sep 2010 07:18:08 +0200 (CEST)

> Could you please say more about the alarm issue?  This case would seem to have little benefit beyond a trivial reduction in LSDB size.

Our management system listens to ISIS and triggers when a prefix is not 
there anymore. This is great for POS and point-to-point ethernet with 
autoneg, but not so good for L2 media that won't go down.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Sep 2010 07:25:19 +0200 (CEST)

On Wed, 15 Sep 2010, Naiming Shen wrote:

> this sounds more like a bug of implementation, do you have specific 
> example? are you talking about real p2p link or LAN with only two nodes? 
> is there another parallel link also?

I'm talking about an ISIS p-t-p link over broadcast media like ethernet.

So the actual media is broadcast but ISIS is configured to run in p-t-p 
mode.

---

From: Naiming Shen <[email-masked]>
Date: Wed, 15 Sep 2010 22:39:56 -0700

Hmm, rfc5309 treats this case just like normal p2p link from isis point of view.
When there is no 'UP' adjacency over this p2p link, the neighbor IS record should
not be in the LSPs. It does not matter the l2 network never goes down in this case.

thanks.
- Naiming

On Sep 15, 2010, at 10:25 PM, Mikael Abrahamsson wrote:

>> this sounds more like a bug of implementation, do you have specific example? are you talking about real p2p link or LAN with only two nodes? is there another parallel link also?
> 
> So the actual media is broadcast but ISIS is configured to run in p-t-p mode.
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Sep 2010 07:58:03 +0200 (CEST)

On Wed, 15 Sep 2010, Naiming Shen wrote:

> Hmm, rfc5309 treats this case just like normal p2p link from isis point 
> of view. When there is no 'UP' adjacency over this p2p link, the 
> neighbor IS record should not be in the LSPs. It does not matter the l2 
> network never goes down in this case.

There is no IS neighbour record (if I understand correctly, this was what 
I called "adjacancy"). However, the link prefix (/30 or /31) is going to 
be in the LSDB as soon as the physical interface is up.

We do not run passive-only (to only have loopbacks in the LSDB).

---

From: Dave Katz <[email-masked]>
Date: Wed, 15 Sep 2010 23:16:34 -0700

Note that there is already a "goodbye" mechanism--send a hello with no neighbors listed, which will fail all of the other routers' adjacencies.

One could also send a hello with a holding time of 1 (still has to time out, but more quickly), or send a hello with a holding time of 0 (probably out of spec).

There's almost always a way of torquing these things--I've made a career out of it.  ;-)

--Dave

---

From: Dave Katz <[email-masked]>
Date: Wed, 15 Sep 2010 23:19:32 -0700

If BFD is in use, you also have a "goodbye" mechanism by asking your BFD implementation to send a packet listing state "Down".  No waiting.

--Dave

---

From: Dave Katz <[email-masked]>
Date: Wed, 15 Sep 2010 23:20:27 -0700

> L1 or L2 both or separately.

Beat me to it...

--Dave

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 16 Sep 2010 08:54:30 +0200

> scenarios for how this could happen in practice:
> > a)  Operator has to login to router that's a DIS for a LAN 
> and issue a 
> > CLI command to have it apply a max-metric to the 
> pseudo-node LSP; or,
> > b)  Operator can login to any node attached to the LAN and, 
> somehow, signal the DIS to apply a max-metric to the pseudo-node LSP.
> > 
> > Although (b) would be my preference (again for ease of 
> use/understanding reasons), I'm guessing that it's probably 
> significantly more complex than (a).  Thus, I would "settle" 
> for (a) if the WG agrees that's the more straightforward route.
> 
> I would prefer 'a' then if we want to do this, and this can 
> also be in the same BCP since really there is no protocol 
> change, which is the best. I would think operators want to do 
> this traffic shifting job, they at least need to know who is 

applying max-metric to every adjacency of the pseudo-node will not alter
relative cost between various routers on the segment, so would need to
specify that only metric from the pseudo-node to specific router should
be changed (ok, this are just details). Login to DIS method might seem
attractive, but what happens when DIS function moves to another router -
new DIS won't have slightest idea that it needs to apply non-zero metric
to some pseudo-node adjacency. Therefore the only solution is for the
router, that wants its interface used only as last resort, to signal
others that reverse metric should be changed.

/iLya

---

From: Naiming Shen <[email-masked]>
Date: Thu, 16 Sep 2010 13:53:01 -0700

There are many ways to handle the DIS move issue.

The simple way is to assign a high priority for the node wants to be last
resort as the DIS, and configure the pnode to itself as very high metric.
One would ask, what if the DIS moves on the Lan? since it is administratively
assigned priority, and if some other node takes over, this means the
node in question is no longer part of the isis on this Lan, and we don't
need to worry about that.

thanks.
- Naiming

---

From: Ilya Varlashkin <[email-masked]>
Date: Thu, 16 Sep 2010 22:55:44 +0200

> need to worry about that.

Unlike loss of OSPF DR, you will have to re-run best-path calculations if DIS is lost. This is best to be avoided.

/iLya

---

From: Naiming Shen <[email-masked]>
Date: Thu, 16 Sep 2010 13:59:50 -0700

OSPF DRs is definitely over optimized. Re-run SPF due to changing of DR should never
be a problem, particular in today's CPU power.
But regardless, we are talking about handling DIS move, be definition, it needs to
re-run.

thanks.
- Naiming

---

From: Ilya Varlashkin <[email-masked]>
Date: Thu, 16 Sep 2010 23:26:31 +0200

To: Naiming Shen <[email-masked]>

> But regardless, we are talking about handling DIS move, be definition, it needs to

Implying loss of packets, however small

Being not coder myself, I'm curious to hear what protocol implementors think about the idea of 'reverse metric' - how much work would it be to implement one of the two variants of 'reverse metric' that I've described in previous mail. If it's not too much work, I could come up with more formal specs of the solution.

/iLya

---

From: Tony Li <[email-masked]>
Date: Thu, 16 Sep 2010 14:50:46 -0700

> Implying loss of packets, however small

In a competent implementation, if you re-run SPF and the topology has not changed and the prefixes have not changed, then there will be no changes to make to the RIB.  

Even if metrics do change, as long as next hops do not change, there will be no FIB changes.  So, no packet loss.  Everything is contained within the control plane.

> Being not coder myself, I'm curious to hear what protocol implementors think about the idea of 'reverse metric' - how much work would it be to implement one of the two variants of 'reverse metric'…

I believe several folks have already stepped up to spec it.  However, I think the bigger issue is one of backward compatibility.   It's not obvious how to introduce this without creating forwarding loops.

Tony

---

From: Ilya Varlashkin <[email-masked]>
Date: Fri, 17 Sep 2010 00:20:10 +0200

> I believe several folks have already stepped up to spec it.  However, I think the bigger issue is one of backward compatibility.   It's not obvious how to introduce this without creating forwarding…

_If_ current implementations permit (will not balk in the presence of) non-zero metric from pseudo-node to a node, then DIS setting reverse metric based on presence of 'reverse metric' TLV seems like a safe bet - only the router that wants to have non-zero reverse metric and DIS must support the feature, all other routers on the network can keep running old code and still select correct (consistent) best path. It would be perhaps useful to run quick poll among implementors whether or not their particular implementation (in current state) will allow non-zero metric in pseudo-node LSP.

/iLya

---

From: "Chen, Jay (Jay)" <[email-masked]>
Date: Fri, 17 Sep 2010 11:23:28 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
>> OSPF DRs is definitely over optimized. Re-run SPF due to changing of 
>> DR should never be a problem, particular in today's CPU power.
>> But regardless, we are talking about handling DIS move, be 
>> definition, it needs to re-run.
> 

Sure, there are three places in software this is checked. First, ISIS will not send it to RIB after consulting its local RIB. Seondly, global RIB process will not propagate it to forwarding plane. Thirdly, even all failed in control plane, forwarding will detect it and does not bother to program the ASIC.

---

From: "Chen, Jay (Jay)" <[email-masked]>
Date: Fri, 17 Sep 2010 12:02:12 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ilya Varlashkin
Sent: Thursday, September 16, 2010 3:20 PM
To: Tony Li
Cc: Shane Amante; IETF IS-IS
Subject: Re: [Isis-wg] operational problem might be solved by somehowextending current IS-IS

> I believe several folks have already stepped up to spec it.  However, I think the bigger issue is one of backward compatibility.   It's not obvious how to introduce this without creating forwarding…

_If_ current implementations permit (will not balk in the presence of) non-zero metric from 

Depending on how much you define balk. Some implementation assumes zero metric in pseudo-node, also prioritise for ECMP path. However I think reverse metric is a less risky option.  

Jay

pseudo-node to a node, then DIS setting reverse metric based on presence of 'reverse metric' TLV seems like a safe bet - only the router that wants to have non-zero reverse metric and DIS must support the feature, all other routers on the network can keep running old code and still select correct (consistent) best path. It would be perhaps useful to run quick poll among implementors whether or not their particular implementation (in current state) will allow non-zero metric in pseudo-node LSP.

/iLya

---

From: Tony Li <[email-masked]>
Date: Fri, 17 Sep 2010 10:11:38 -0700

> Depending on how much you define balk. Some implementation assumes zero metric in pseudo-node, also prioritise for ECMP path. However I think reverse metric is a less risky option.  

That's not yet clear to me.  If an IS doesn't support the reverse metric TLV, then it will compute different SPF results than an IS that does.  That seems like it is guaranteed to create forwarding loops.

Please feel free to convince me otherwise.  Mathematical proofs preferred.  ;-)

Tony

---

From: "Chen, Jay (Jay)" <[email-masked]>
Date: Fri, 17 Sep 2010 12:42:00 -0500

I can't see how the routing loop can be abvoided either, if the topology is not partitioned. Assume the topology can be split to routing instances triggered by reverse metric TLVs, can it be possible to avoid routing loop ?

Jay   

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: Friday, September 17, 2010 10:12 AM
To: Chen, Jay (Jay)
Cc: Ilya Varlashkin; Shane Amante; IETF IS-IS
Subject: Re: [Isis-wg] operational problem might be solved by somehowextending current IS-IS

Tony

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 27 Sep 2010 16:25:03 +0200

On Tue, Sep 14, 2010 at 09:39:06AM -0700, Tony Li wrote:
| 
| Hi Mikael,
| 
| > Basically, what I'd like to see is the way to bidirectionally increase cost on a link by just changing the configuration at one end. This would ease the number of configuration changes needed in case 2, and I would also request my vendor to implement a new command that might be "isis cost max" (or "cost avoid") that would actually not replace the current cost value but just raise it to a maximum value, but only needing the change done at one end.
| > 
| > To solve case 1, instead of using "overload" I'd like to use "max-metric" (as done in OSPF) but this would be done to all the links connecting the router. This would mean that in case of a BGP failure / process restart, ISIS/LDP signalled LSPs wouldn't have to be torn down / re-routed (torn down in case of a single homed router behind the router having maintenance). If there was a broadcast media, it would make the traffic go away from the router if there was any other path.
| 
| 
| The unidirectional case seems like it is entirely doable within one system and is simply an implementation issue.  You should take this up with YFRV.
| 
| What seemed like it would take standardization work is the case of doing things bidirectionally.  

i am wondering if we could streamline the "suppress adjacency bit" for that purpose.
see http://datatracker.ietf.org/doc/rfc5306/ section 3.2.2

since many of us already have implemented the SA logic for graceful startup,
my guess is that we can massage it for graceful shutdown as well.

/hannes

[ ... ]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 27 Sep 2010 11:56:45 -0700

Hannes -

I don't think SA is useful in this case.

SA is targeted to be used in those cases where there are stale LSPs from
a previous incarnation of a router. If that router restarts, it is
possible that as soon as the neighbors of the restarting router announce
new adjacencies to the restarting router that some routers in the
network will see two way connectivity before the restarting router has
fully converged and/or has had a chance to purge any stale LSPs.

In this case there is no issue w stale LSPs. We are concerned with
either bringing down an existing adjacency quickly (i.e. w/o waiting for
holdtimer expiration) and/or modifying the cost to a node via a given
link so that it is seen as a path of last resort. I do not see why a
neighbor would react more quickly to the introduction of SA than they
would to the reception of an IIH w zero holdtime.

  Les 

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hannes Gredler
> Sent: Monday, September 27, 2010 7:25 AM
> To: Tony Li
> Cc: [email-masked]
> | > Basically, what I'd like to see is the way to bidirectionally
> increase cost on a link by just changing the configuration at one end.
> This would ease the number of configuration changes needed in case 2,
> and I would also request my vendor to implement a new command that
> might be "isis cost max" (or "cost avoid") that would actually not
> replace the current cost value but just raise it to a maximum value,
> but only needing the change done at one end.
> | >
> | > To solve case 1, instead of using "overload" I'd like to use "max-
> metric" (as done in OSPF) but this would be done to all the links
> connecting the router. This would mean that in case of a BGP failure /
> process restart, ISIS/LDP signalled LSPs wouldn't have to be torn down
> / re-routed (torn down in case of a single homed router behind the
> router having maintenance). If there was a broadcast media, it would
> make the traffic go away from the router if there was any other path.
> |
> |
> | The unidirectional case seems like it is entirely doable within one
> system and is simply an implementation issue.  You should take this up
> with YFRV.
> |

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 29 Sep 2010 17:45:55 +0200

On Mon, Sep 27, 2010 at 11:56:45AM -0700, Les Ginsberg (ginsberg) wrote:
| Hannes -
| 
| I don't think SA is useful in this case.
| 
| SA is targeted to be used in those cases where there are stale LSPs from
| a previous incarnation of a router. If that router restarts, it is
| possible that as soon as the neighbors of the restarting router announce
| new adjacencies to the restarting router that some routers in the
| network will see two way connectivity before the restarting router has
| fully converged and/or has had a chance to purge any stale LSPs.

agreed;

| In this case there is no issue w stale LSPs. We are concerned with
| either bringing down an existing adjacency quickly (i.e. w/o waiting for
| holdtimer expiration) and/or modifying the cost to a node via a given
| link so that it is seen as a path of last resort. I do not see why a
| neighbor would react more quickly to the introduction of SA than they
| would to the reception of an IIH w zero holdtime.

wasn't the original problem to keep the adjacency up but somehow
not carry any transit traffic ?

| > -----Original Message-----
| > From: [email-masked] [mailto:[email-masked]] On
| > Behalf Of Hannes Gredler
| > Sent: Monday, September 27, 2010 7:25 AM
| > To: Tony Li
| > Cc: [email-masked]
| > Subject: Re: [Isis-wg] operational problem might be solved by somehow
| > extending current IS-IS
| > 
| > On Tue, Sep 14, 2010 at 09:39:06AM -0700, Tony Li wrote:
| > |
| > | Hi Mikael,
| > |
| > | > Basically, what I'd like to see is the way to bidirectionally
| > increase cost on a link by just changing the configuration at one end.
| > This would ease the number of configuration changes needed in case 2,
| > and I would also request my vendor to implement a new command that
| > might be "isis cost max" (or "cost avoid") that would actually not
| > replace the current cost value but just raise it to a maximum value,
| > but only needing the change done at one end.
| > | >
| > | > To solve case 1, instead of using "overload" I'd like to use "max-
| > metric" (as done in OSPF) but this would be done to all the links
| > connecting the router. This would mean that in case of a BGP failure /
| > process restart, ISIS/LDP signalled LSPs wouldn't have to be torn down
| > / re-routed (torn down in case of a single homed router behind the
| > router having maintenance). If there was a broadcast media, it would
| > make the traffic go away from the router if there was any other path.
| > |
| > |
| > | The unidirectional case seems like it is entirely doable within one
| > system and is simply an implementation issue.  You should take this up
| > with YFRV.
| > |
| > | What seemed like it would take standardization work is the case of
| > doing things bidirectionally.
| > 
| > i am wondering if we could streamline the "suppress adjacency bit" for
| > that purpose.
| > see http://datatracker.ietf.org/doc/rfc5306/ section 3.2.2
| > 
| > since many of us already have implemented the SA logic for graceful
| > startup,
| > my guess is that we can massage it for graceful shutdown as well.
| > 
| > /hannes
| > 
| > [ ... ]
| > _______________________________________________
| > Isis-wg mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "iLya" <[email-masked]>
Date: Wed, 29 Sep 2010 18:01:00 +0200

> not carry any transit traffic ?

not exactly - it was 'keep ajacency up but carry traffic over that link only 
as last resort'

/iLya