Hi Les, Tony, Thank you both for the clear and quick answers.
For context, I did not find this in a lab first: we hit it in production, during IS-IS operations on a dual-vendor network (Nokia SR OS and Juniper Junos). We drained an L1/L2 router with the overload bit, and some L1 routers kept sending inter-area traffic to it. The labs came after, to understand why. I agree: the knobs are enough, and a clarification is not worth the debate. Besides suppress-attached-bit on SR OS, we finally chose overload with the maximum metric as our default drain: with both vendors, the LSP then carries neither OL nor ATT, so every receiver behaves the same way. Good point about the route of last resort. In our design, each L1 area has several L1/L2 routers, so this case does not apply to us. Thanks again to you both. Regards, Antoine Keranflec'h Le ven. 9 oct. 2026 à 09:33, Tony Przygienda <[email protected]> a écrit : > > I agree with Les here. Yes, the spec was loose in this part, but historically > it has proven that the attached bit was not as useful as it was thought to > be, and implementations provided all kind of remedies for deployment > scenarios.We will get into religious battles, which sometimes is unavoidable, > but in this case whatever standardized will be largely ignored anyway, so why > bother. Kuddos to finding it — you have to be pretty deep into implementation > to actually find that corner.Thanks, Tony > Sent from my iPad > > > On Oct 8, 2026, at 23:11, Les Ginsberg (ginsberg) > > <[email protected]> wrote: > > > > Antoine - > > > > As your careful research has shown, ISO 10589 does not define any explicit > > relationship between OL bit and ATT bit. > > > > In practice, as you have demonstrated, implementations have chosen somewhat > > different behaviors. > > > > Having the sender automatically clearing the ATT bit when OL bit is set has > > the "advantage" that it guarantees that no receiver will ever consider that > > router as attached to other areas when the OL bit is set. > > However, this might prevent a receiver from installing a route of last > > resort when there are no other exit points from the area - which might > > cause some traffic to be unnecessarily blackholed. > > I am not advocating for or against the sender behavior - just discussing > > the implications. > > > > Some implementations have provided knobs to ignore the attached bit when > > received. > > Some implementations have provided knobs to set the attached bit under > > conditions that may differ from what is defined in ISO 10589. > > > > In general, I think there is enough flexibility and robustness in > > implementations that operators should be able to realize whatever behavior > > they deem most desirable. > > > > I don't think trying to standardize behavior is needed - nor would it be > > worth the likely "religious arguments" that might be advanced for one > > approach over the other. > > My $.02... > > > > > > Les > > > > > >> -----Original Message----- > >> From: Antoine Keranflec'h <[email protected]> > >> Sent: Thursday, October 8, 2026 1:57 AM > >> To: [email protected] > >> Subject: [Lsr] IS-IS: overload bit and attached bit in an L1 LSP, > >> implementations > >> disagree on the default route > >> > >> Hello LSR, > >> > >> When an L1/L2 IS sets the overload bit and keeps the attached bit in > >> its L1 LSP, the implementations I tested do not agree on whether the > >> L1 routers keep it as the target of the default route. As I read ISO > >> 10589, the letter of the decision process keeps it, but the use of the > >> overload bit to move traffic away from a router expects the opposite. > >> I would like to check this reading with the WG, and ask whether a > >> clarification would be useful. > >> > >> Setup: containerlab, wide metrics, point-to-point links. Releases: > >> Nokia SR OS 24.10.R3 (vSIM, lab 1) and 26.3.R1 (SR-SIM, lab 2), > >> Juniper Junos 23.4R2-S6.9 (vJunos-router), FRR 10.2.5. The L1 routers > >> have no exit other than the default route from ATT. > >> > >> Configurations and outputs: > >> > >> - Lab 1, one SR OS L1/L2 router and three L1 routers (SR OS, Junos, > >> FRR): https://github.com/antoinekh/labs/tree/master/isis_interop > >> - Lab 2, each vendor as the overloaded L1/L2 router, with one exit and > >> with three equal-cost exits: > >> https://github.com/antoinekh/labs/tree/master/isis_interop_drain > >> > >> Observations: > >> > >> 1. Sender, overload bit set: SR OS and FRR send ATT=1 and OL=1. Junos > >> sends OL=1 and ATT=0, as its documentation of the overload statement > >> says: "An L1-L2 router in overload mode stops leaking route > >> information between L1 and L2 levels and clears its attached bit." > >> 2. Receiver, one exit, LSP with ATT=1 and OL=1: SR OS installs no > >> default route. Junos and FRR install 0.0.0.0/0 toward the overloaded > >> router. Junos still applies the overload bit to the other routes: it > >> removes the routes that transit the overloaded router and keeps the > >> routes to the router's own prefixes. > >> 3. Receiver, three equal-cost exits: when the SR OS or the FRR exit is > >> overloaded, the SR OS L1 router removes it from the default-route next > >> hops, and the Junos and FRR L1 routers keep it. When the Junos exit is > >> overloaded (ATT=0), all three L1 routers remove it. > >> > >> Result: with an SR OS or FRR sender and a Junos or FRR receiver, > >> inter-area traffic keeps crossing the overloaded router. > >> > >> Relevant text: > >> > >> - ISO/IEC 10589:2002, 7.2.8.1: "The Decision Process shall not utilise > >> a link to an Intermediate system neighbour from an IS whose LSPs have > >> the LSP Database Overload indication set." Annex C.2.6 applies it: "If > >> the LSP Database Overload bit is set, only consider the End system > >> neighbours of the system P." The overloaded IS itself is still placed > >> on PATHS, so it stays reachable. > >> - ISO/IEC 10589:2002, 7.2.9.1: "A level 1 IS shall ascertain the set, > >> R, of 'attached' level 2 Intermediate system(s) for metric k such that > >> the total cost to R for metric k is minimal." 7.2.12.2 gives the same > >> preference for routes out of the area, and RFC 1195, section 1.2, > >> applies the rule to IP. None of them has a condition on the overload > >> bit. > >> - ISO/IEC 10589:2002, 7.2.9.2: an IS "considers itself attached" if it > >> can reach at least one other area, or if it has an enabled reachable > >> address prefix. No condition on the overload bit. > >> - ISO/IEC 10589:2002, 7.3.19: the overload procedure exists so that > >> the other ISs "do not rely on forwarding paths through the overloaded > >> IS". 7.3.19.1: "An overload condition can therefore exist > >> independently for Level 1 or Level 2 (or both)." > >> - RFC 3787, section 4: "an overloaded router may be used to reach End > >> Systems directly attached to the router, as it may provide the only > >> path to an End System". The receiver "SHOULD treat all IP reachability > >> advertisements as directly connected", and the overloaded router > >> "SHOULD take care in selecting which routes to advertise in the LSPs > >> it generates". ATT is a header flag, not an IP reachability > >> advertisement, so these sentences do not seem to cover it. > >> > >> My reading: by the letter of ISO 10589, an overloaded L1/L2 IS keeps > >> ATT (the SR OS and FRR sender behavior), and L1 ISs keep it in the set > >> R of 7.2.9.1, so it stays a target of their default route (the Junos > >> and FRR receiver behavior). This fits the original purpose of the bit: > >> in an L1 LSP, it says that the L1 database is incomplete, while > >> out-of-area traffic is forwarded with the L2 database. But the bit is > >> now also set on purpose: until BGP converges (RFC 3277), and before > >> maintenance (RFC 8500, appendix A). RFC 3787, section 4, already notes > >> that "the meaning of this flag has been overloaded". For these uses, > >> and for the intent stated in 7.3.19, the SR OS receiver behavior and > >> the Junos sender behavior are the ones that move the traffic away from > >> the router. > >> > >> Questions: > >> > >> 1. Is this reading of ISO 10589 correct, or is the case defined > >> somewhere that I missed? > >> 2. Would the WG see value in a short clarification for these uses? For > >> example: an overloaded L1/L2 IS SHOULD clear ATT in its L1 LSPs, as > >> Junos does; and, for the senders that do not, an L1 IS SHOULD NOT > >> select an overloaded IS as the target of the default route when > >> another attached IS is reachable. > >> > >> Regards, > >> Antoine Keranflec'h > >> _______________________________________________ > >> Lsr mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > _______________________________________________ > > Lsr mailing list -- [email protected] > > To unsubscribe send an email to [email protected] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
