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]
