Subject: [Isis-wg] Overload & Attached bits

From: Nagasta Bagamba <[email-masked]>
Date: Fri, 16 Nov 2001 04:36:00 -0800 (PST)

Hi,
It seems to me that we all want the overload bit to
have a different meaning depends on the cause of the
overloading situation:
Erik, you want to go by the book (in this case the ISO
10589). I don't think anyone can argue with your
interpretation.
Shen, in your example you prefer to send traffic to
any IS than not sending at all. I suppose in most
cases the traffic will go through the overloaded IS
and reach the destination safely. But as you said, you
suppose that in most cases the overload bit indicates
the BGP is not converged yet. 
Erez, you gave an example why not using the the
overloaded IS in the nearest attached algo.
Alan, you gave an example for why not using the
overloaded IS as transient.

It looks like there should be a different behavior
depends on the cause of the overloading (on-startup,
'real' database overload, new tested router...).
As I see it, we have 2 problems:
1. There is only ONE bit, so other routers have no
idea what was the reason for setting it.
2. We can't 'violate' the ISO/RFC standards just
because we think there are better ways to do things. 
Standards are what the protocol is all about...

In a multi-vendors isis topology, the system
administrator will have a really hard job trying to
figure out the behavior in an overloaded situation.

Regards,
Nagi

--- Naiming Shen <[email-masked]> wrote:
> To: Alan Hannan <[email-masked]>
> CC: Erik Hietbrink <[email-masked]>,
> 	Nagasta Bagamba <[email-masked]>,
> 	[email-masked]
> Subject: Re: FW: [Isis-wg] Overload & Attached bits 
> Date: Wed, 14 Nov 2001 15:18:52 -0800
> From: Naiming Shen <[email-masked]>
> 
> 
> Hi, Alan,
> 	Great to hear all the 10589 "vialations":-)
> 	I had personal experience of the similar vialation:
> routerA
> and routerB were in a webfarm connected by GigEs
> running IS-IS, and
> each had a OCx link to the backbone. It was nice to
> set OL bit on
> both routerA and routerB so that those two routers
> didn't carry
> transit traffic through the webfarm. My previous
> posting just
> responded to the case when OL and ATT bits are both
> set in a L1 area.
> 
>  ]
>  ]  FWIW, in ISP routing topology design, often
> times a box with the
>  ]  IS-IS OL-bit set is used for carrying traffic.
>  ]
>  ]  There are two situtaions where this occurs, and
> they are usually
>  ]  both where the router in question is used as
> part of an auxilliary or
>  ]  out-of-band networks.
>  ]
>  ]  The first is where the router in question is
> used only as a gateway of last
>  ]  resort for certain kinds of traffic, with a
> default route back towards the 
>  ]  NMS or NOC area, only for the purpose of
> carrying a subset of
>  ]  traffic.  Note that typically this router is not
> meant to carry
>  ]  production traffic.
>  ]
>  ]  The second is where the router in question is
> using other routing
>  ]  protocols to carry certain types of
> traffic/destinations.  i.e.
>  ]  Ships in the Night kind of stuff.  Also, this
> router is not meant to
>  ]  carry production traffic in this context, rather
> stats and
>  ]  management traffic (telnet to boxes, SNMP,
> etc..).
>  ]
>  ]  I assert that common ISP usage of IS-IS OL-bit
> does not comply with
>  ]  ISO10589-2001, section 9.8, yet it does comply
> with the wording if
>  ]  the phrase "any decision process' is changed to
> 'the IS-IS routing
>  ]  algorithm".
>  ]
>  ]  -alan
>  ]
>  ]Thus spake Naiming Shen ([email-masked])
>  ] on or about Wed, Nov 14, 2001 at 12:14:51PM
> -0800:
>  ]> 
>  ]> I would try to avoid picking the router with OL
> bit set if there are
>  ]> multiple gateways available. But if all the
> L2/L1 gateways have the OL
>  ]> bit set, then pick them anyway and send default
> traffic to them. Since
>  ]> if not, those traffic will be dropped on the
> local L1 routers. Often
>  ]> the OL bit these days indicate the BGP is not
> converged yet, at least
>  ]> a subset of the traffic can still be delivered
> through the gateways
>  ]> which is better than drop all of them. In the
> old days, routing and
>  ]> forwarding compete for the same resource on
> routers, so doing the above
>  ]> suggestion would not be a good behaviour, its
> hardly this case now.
>  ]> 
>  ]>  ]Nagasta Bagamba wrote:
>  ]>  ]> 
>  ]>  ]> 2. Should we consider overloaded routers in
> our search
>  ]>  ]> for the nearest attached level-2
> intermediate system?
>  >  ]> 
>  ]>  ]> You decided that the answer is No. But, I
> know of at
>  ]>  ]> least 2 major vendors which consider
> overloaded
>  ]>  ]> routers in the search for the nearest
> attached level-2
>  ]>  ]> IS.
>  ]>  ]> If vendors-mixture ISIS topology will be
> built,
>  ]>  ]> routing loops may occure. Does anyone have
> an idea how
>  ]>  ]> to avoid routing loops in such a topology?
>  ]>  ]
>  ]>  ]Hi,
>  ]>  ]
>  ]>  ]ISO10589-2001, section 9.8, says about the
> Overload bit:
>  ]>  ]"An LSP with this bit set will not be used by
> any decision process to
>  ]>  ]calculate routes to another IS through the
> originating system".
>  ]>  ]
>  ]>  ]I would interpret this statement so that no
> default level 2 IS
>  ]>  ]route may be calculated to an IS with the
> overload bit set.
>  ]>  ]
>  ]>  ]Regards,
>  ]>  ]Erik
>  ]> 
> ]_______________________________________________
>  ]>  ]Isis-wg mailing list  - 
> [email-masked]
>  ]> 
>
]http://external.juniper.net/mailman/listinfo/isis-wg
>  ]> 
>  ]> - Naiming
>  ]> _______________________________________________
>  ]> Isis-wg mailing list  - 
> [email-masked]
>  ]>
> http://external.juniper.net/mailman/listinfo/isis-wg
> 
> - Naiming

__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Erik Hietbrink <[email-masked]>
Date: Fri, 16 Nov 2001 15:51:37 +0100

> figure out the behavior in an overloaded situation.

Good summary. My major concern is what to do in a dual-ISIS stack 
(NE supports ISIS for OSI and I-ISIS for IP), when this overload
bit is interpreted differently.
My personal choice for conveying information retrieved from other
routing processes (like BGP convergence) would be to put it in a TLV.
We should avoid having multi-interpretable fields in PDUs.

Regards,
Erik

---

From: Henk Smit <[email-masked]>
Date: Fri, 16 Nov 2001 09:52:54 -0800 (PST)

> figure out the behavior in an overloaded situation.

  The problem is this:
  Right now we are discussing how L1-only routers should interpret the
 overload-bit and the attached-bit. IMHO this is not open for discussion.
 10589 clearly says how a router is supposed to compute routes when it
 sees LSPs with either the attached bit (ATT) set, or the overload
 bit (OVL) set. As noted, when you change this, you will run into
 compatability issues. So: don't change the interpretation of the OVL
 and ATT bits.

  What is not clearly defined is when a router must, could or should
 set the ATT bit and/or OVL bit. So implementators are free to play
 with algorithms when to set or not set those bits. Setting one of
 these bits means that the router either invites or discourages other
 routers to send traffic through it. Regardless of what algorithms
 implementors use for their L1L2 routers to decide to set the ATT
 bit and OVL bit, if all routers interpret these bits the same way,
 this should never cause routing loops.

  Let's look at the problem of a L1L2 router setting the OVL bit.
 It means it doesn't want to attract intra-area transit traffic.
 If the implementor also meant that he didn't want to attract L1->L2
 inter-area traffic, then the implementor should make sure that his
 router also does not set the ATT bit. Simple as that. If a router
 sets both ATT and OVL, that means it does not want to forward intra-area
 traffic, but it does want to forward L1->L2 inter-area traffic.

  The same is through for inter-area traffic in the other direction.
 If a L1L2 router sets the OVL bit in its L2 LSP, but it also advertises
 all L1 prefixes learned via L1 routing, then it must forward traffic
 to those L1 destinations. If it doesn't want to forward that L2->L1
 traffic, then it must not advertise those L1 prefixes in its L2 LSP.

  Last remaining problem. Suppose a L1L2 router is the only router that
 supplies connectivity between two parts of the network. Setting the OVL
 bit will make those two parts effectively disconnected. This might not
 always be the behaviour you want.
  If you want to solve this problem by making routers interpret the OVL
 in a different way, then you run into compatability problems again. So
 don't try to solve this problem by chaning the interpretation on the
 other routers. Solve it by changing the behaviour of the advertising router.
 A solution would be to not use the OVL bit to discourage other routers
 to compute a path through this router. In stead, the router could
 advertise all its links with a very high metric. That would cause paths
 through this router to be the least preferred, but in case there are no
 other paths, it would still be used. And thus the network will not become
 partitioned. (Granted, this will probably work better with the newer
 TLVs with wider metrics).

  So it might not be enough to just set or not set the OVL bit.
 A router should also adjust the ATT bit.
 And it should consider which L1->L2 and L2->L1 prefixes to advertise.
 And it should make a decision wether to use the OVL bit trick or the
 trick where it set its link metrics to a high value.

  All this can be done in the advertising router. It is easy to solve
 problems by changing semantics of existing protocols. Unfortunately
 usually that won't work in the real world. Useful solutions should
 work in a backward compatible way. Putting all intelligence in the
 advertising router should ensure backward compatibility.

  Hope this helps,

       Henk.