Hi Venkat, I think there are two different aspects in the problem you have described below: 1. IS-IS database overload 2. Summary prefix
On the first one, I think from ISO/IEC 10589:2002 it is clear that the database overload bit has relevance only in LSP number 0 and the value present in other LSPs of the IS are to be disregarded: <excerpt> 7.2.5 Multiple LSPs for the same system The following information shall be taken only from the LSP with LSP Number zero. Any values which may be present in other LSPs for that system shall be disregarded by the Decision Process. *a) The setting of the LSP Database Overload bit.* b) The value of the IS Type field. c) The Area Addresses option field. d) the setting of the AttachedFlag bit </excerpt> <excerpt> 7.3.4.3 The IS shall treat the LSP with LSP Number zero in a special way, as follows: a) The following fields are meaningful to the decision process only when they are present in the LSP with LSP Number zero: *1) The setting of the LSP Database Overload bit.* .... </excerpt> Hence, in the scenario below, if PE2 receives ab1's LSP number 0 w/ the overload bit set, I believe it should consider abr1 as overloaded and should not use it as a transit router for prefix reachability even if has the older incarnation of other LSPs from abr1.. That said, I think the summary prefix generated by abr1 is like a local prefix, so other ISs that match only the summary prefix during LPM will continue to send traffic to ab1 even if ab1 is overloaded. In fact, abr1 could have 100s of neighbors whose prefixes it may be summarizing. In step #6, after abr1 purges the LSP w/ the summary prefix (as part of DB sync) and then re-advertises the summary prefix after forming adjacency w/ one of its neighbors and receiving its neighbors LSP for an exact match, it will still drop traffic destined to one of its upstream neighbors it hasn't formed adjacency with, yet. I think that's one of the disadvantages of summarization.. Regards, Muthu On Wed, Apr 12, 2023 at 10:00 AM Venkataratnam Naidu <[email protected]> wrote: > Hello Experts, > > > > Need your opinion on how node should behave with "IS-IS summary-routes > with overload-bit start-up" > > > > Ideally when an overload-bit is set node can't be used as a transit node, > local routes still be reached using this overloaded node. With the below > topo there is some traffic black hole and looking for your inputs on how we > can avoid such issues. > > > > -- PE1 -- > > | 9| > > abr1 abr2 > > | | > > P1 ------ P2 > > |8 | > > -- PE2 -- > > > > 1. abr1 & abr2 summarizing is-is routes that received from PE1 and adding > summary routes as part of its LSP and flooding. > > 2. abr1 & abr2 has two lsp fragments lsp.0 and lsp.1 where summary routes > are present in lsp.1 > > 3. PE2 receives summary routes and chooses the active path as p1->abr1 and > backup path as p2->abr2. > > 4. when abr1 reloaded and comes up with overload-bit start-up set in boot > config, it forming adj with P1 and creates lsp.0 with over load bit and > floods > > 5. PE2 computes its SPF with abr1 new lsp.0 and old lsp.1 this results in > an active path as p1 ->abr1(after reload abr1 has not yet formed adj with > PE1 yet). This results in traffic drop at abr1 for a few milliseconds. > > 6. After a few milliseconds abr1(as part of db sync abr1 received its > lsp.1 from P1) sending purge to its lsp.1. > > 7. PE2 computes its SPF with abr1 lsp.0 and purged lsp.1 and chooses an > active path as p2->abr2, with this traffic issue being rectified. > > > > > > Regards, > > Venkat. > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
