Subject: Re: [Isis-wg] operational problem might be solved bysomehowextending current IS-IS

From: [email-masked]
Date: Fri, 1 Oct 2010 09:11:48 +0200

> 
>> First of all, i doubt is this a common scenario that most of  Carriers meet? To my experience, isis is often deployed in the IP backbone network.
>> To achieve high routing convergence performance, most carriers deploy p2p on POS(or p2p over Ethernet) link to build their network.
>> If i am right, the issue is a rare scenario...
> 

I would say this is very common scenario in SP and we do have this setup in our network as well.

Guan

---

From: "Suri, Simranjyot (Simranjyot)" <[email-masked]>
Date: Mon, 4 Oct 2010 14:42:09 -0500

Hi All,
I've been following this discussion for a while now and it's turning out to be an extremely interesting and important one. I'd like to make a few comments and hopefully have everyone look at the issue from a slightly different perspective.

Shane and Mikael,
The issues that you've brought up are very important indeed, and it would be good to get solutions for them from the protocol itself (if reasonably possible). I completely empathize with your plight -- being paged in the middle of the night (2:00 am?!) and having to debug a live customer issue after dragging oneself out of bed is no fun (to put it mildly), and you need the best tools possible! :) 
To recap briefly, the requirements that you're seeking are:
1. Instead of having the entire IS/router (router from now on) go into overload, have a mechanism for a router to isolate a specific link (p-to-p or broadcast) in BOTH directions
2. Same as 1 except have a mechanism for a router to change the metric for a specific link (p-to-p or broadcast) in BOTH directions to MAX_METRIC (so that the link can be used in case no other link/path is available)

Since people have already suggested acceptable solutions for the first point, I'd like to address the second one. Essentially, it seems like all that is being sought here is a type of "overload-link" mechanism from the IS-IS protocol. As Ilya, Tony and others have correctly pointed out, there are multiple ways to solve this issue, but of course ALL of these will require a protocol extension of some sort (i.e. ALL routers at a particular level would have to support the proposed changes). 

The proposal involving a 'reverse-metric' TLV in a Hello packet, which in turn causes the neighbor to increase its own metric, is an interesting one and is definitely very intuitive and easy to understand. It has the following characteristics:
a) It needs a protocol extension to support non-zero DIS metric and a corresponding change in SPF
- This is not an issue per-se, since a protocol extension of some form will anyway be needed if the requirements need to be satisfied
b) Protocol no longer remains purely distributed, since one router's advertised information causes a change in the neighboring router's advertised information
- The point that Les makes is a valid one. While it is easy to make the required change, it sets a dangerous precedent. The idea of one node being able to change the globally advertised values of its neighbors can be taken to the extreme (with dire consequences). I can't speak for other protocols, but the ability to change one's neighbors' globally advertised values is fundamentally different from i) Negotiating a mutually acceptable value (of local scope) between self and neighbor ii) Having self's advertised values affect the neighbor's SPF *output*.

A slightly different way to solve the requirements that gets around b) above, is to have a new 'overload-link' TLV (maybe an 'overload-link' sub-TLV within the Extended-IS-Reachability TLV would also work) included within LSPs. This TLV would signal to all other routers at that level that a particular link is overloaded. All the other routers at that level would then take this information into account during SPF computation, and the overloaded link would be used only as a link of last resort. This proposal has the following characteristics:
a) It needs an SPF change
- Again, this is not a disadvantage per-se, since a protocol change of some form is definitely needed if the requirements need to be satisfied. Another way to think of it is: what if the overload-bit functionality was not part of the original IS-IS specification, but had to be introduced now?
- The change in SPF would be: while adding a router's neighbors to TENT, we'll have to check if a particular neighbor advertised the *link* to this router as overloaded (somewhat similar to the overload-bit check being done currently). If so, we'll add the neighbor with MAX_METRIC instead of link metric. 

Compared to the 'reverse-metric' TLV proposal, the 'overload-link' proposal has the following advantages:
a) It does not need a protocol extension to support non-zero DIS metric (it needs a change to SPF computation similar to the one for 'reverse-metric')
b) Protocol remains purely distributed wrt *inputs*, since one router's advertised information does not influence/change the other router's globally advertised information.

NOTE: The failure case for both 'overload-link' and 'reverse-metric' proposals is the same -- routing loops. 

Since the approach the WG decides to take will have future consequences, it would be sobering to keep the following thought in mind :)
"Today's problems come from yesterday's solutions!"

Regards,
Simran