ISIS on SDA

[JUANNN]

Hello,

Why is IS-IS level-1 not used in SDA, instead of level-1-2? Why on an SDA site we need to mantain a level-2 adjacency and database too, if we can just have everything on the same area? In what production scenario do we benefit from level1-2 on SDA?

Thanks,

Juan

[Andrii Oliinyk]

Hi,
i'd assume it's bc of default IS-IS configuration developers chosen as single automation option for underlay. But just quick Q: what benefit can u see in using L1-only instead L2-only?

[JUANNN]

With level-1 only switches only need to maintain 1 database rather than 2. No need to copy level-1 information to level-2 database. Less calculations, less workload, ... and simple setup. 

[Andrii Oliinyk]

the same basically is relevant to L2-only. 
"and simple setup." - for CatC automated underlay provisioning (built-in) of for custom Day0-templates to do the same by admin?

[JUANNN]

Why not level-1 (all in the same area, where the area can be understood as the site itself). Why having multiple areas if I can just have everything on 1, for the sake of simplicity.

[Andrii Oliinyk]

single L2-only doesnt necessary mean multi-area domain :0)
& at very 1st approach reason for not L1-only: if for some reason admin will decide to partition site into multi-area (just hypothetically) - it will be easier to do with L2-backbone.

[M02@rt37]

Hello @JUANNN 

In a single area SDA fabric, L1-only would generaly be sufficient because all nodes can learn the complete topology within the same area...

L1/L2 is used mainly because it provide scalability for hierarchical designs ; I mean L1 handle the local area, while L2 can connect that arae to other ISIS areas or an external backbone.

So, in a production SDA environment with multiple fabric domains or an underlay that must integrate with other isis areas, L1/L2 is useful; in a truly flat, single-area deployment, the L2 database/adjacency provide little practical benefit and adds some overhead...

Hope that clear.

[Andrii Oliinyk]

"in a truly flat, single-area deployment, the L2 database/adjacency provide little practical benefit and adds some overhead" - could u please bring more details about "little practical benefit and adds some overhead"?

[Andrii Oliinyk]

"In a single area SDA fabric, L1-only would generaly be sufficient because all nodes can learn the complete topology within the same area..." vs "single L2-only doesnt necessary mean multi-area domain" 
give me single advantage of using L1-only vs L2-only in single area SDA fabric :0)

[Andrii Oliinyk]

Hi M02@rt37 
i already asked above this specific Q about "L2 database/adjacency provide little practical benefit and adds some overhead" in single IS-IS domain (read fabic site underlay). Can u maybe bring more details on both "little practical benefit and adds some overhead" especially keeping in mind that in SDA we rely on automation from CatC (either LAN-A or Day0 templates)?

[M02@rt37]

Hello @Andrii Oliinyk 

The overhead is mostly protocol/state overhead rather than configuration overhead. CatC/Day-0 templates can make configuring L2 trivial, yes, but they do not eliminate what ISIS does at runtime: L2 adjacencies must be maintained, L2 LSPs are flooded through the fabric, every L2 router maintains the corresponding LSDB, and topology changes can trigger SPF processing...

For a "normal" SDA fabric this cost is usually small, so I would not argue that L2 is a performance problem. The stronger argument is unnecesary state: if L1 already gives every node the complete topology/reachability required inside one area, L2 add another level of topology state without a corresponding SDA service benefit.

Where L1/L2 can make sense in production is when you deliberately introduce an ISIS hierarchy. For example, an SDA underlay that must interact with a larger ISIS infrastructure, or where you want a boundary between the fabric and another routing domain/area. Inside a genuinely self-contained SDA site, however, there is little architectural reason to maintain L2 purely for the sake of L2. The fact that Catalyst Center automates it makes the configuration argument weaker, not stronger: automation hides the complexity from the engineer, but the switches still pay the runtime cost of maintaining the L2 database and adjacencies...

No ?

[Andrii Oliinyk]

"L2 adjacencies must be maintained, L2 LSPs are flooded through the fabric, every L2 router maintains the corresponding LSDB, and topology changes can trigger SPF processing" - prove me wrong but if u replace L2 w/ L1 nothing will change.
"normal" SDA deploys either L1/L2 or L2 (post DNA Center version 2.3.2.3). If either already gives every node the complete topology/reachability required inside one area, removal L2 or L1 from L1/L2, or replacement L2 w/ L1 add unnecessary burden "without a corresponding SDA service benefit."
"Inside a genuinely self-contained SDA site, however, there is little architectural reason to maintain L2 purely for the sake of L2. " - replace L2 w/ L1 & nothing will change.
Finally, "cost of maintaining the L2 database and adjacencies" - i still do not see any calculable facts of why  "cost of maintaining the L1 database and adjacencies" is less than it is w/ L2 only.
Give me at least one that is not as well applicable to L1 or this dispute will lose it's sense.

[M02@rt37]

Hello @Andrii Oliinyk 

Yes, I agree, in a single-area, self-contained SDA fabric, there is no strong technical argument that L1-only is inherently cheaper than L2-only—both maintain one adjacency level, one LSDB, flood LSPs, and run spf for essentialy the same topology.

The real, non-equivalent advantage of L2 is when the SDA underlay must participate in a larger IS-IS hierarchy or connect multiple areas, because L2 provides the backbone/inter-area routing function; L1 does not.

If that requirement does not exist, then maintaining L1/L2 rather than simply L1-only or L2-only is mainly an architectural/automation choice, not an SDA service necessity. No ?

[Andrii Oliinyk]

glad we came to the same page
finally, as we could notice, Cisco replaced mixed leveling w/ L2-only which gives a hint it evolves :0)

[M02@rt37]

Yep! That’s a reasonable takeaway... The move from mixed L1/L2 toward L2-only in newer SDA versions suggests cisco’s design evolved toward a simpler single-level underlay, which reinforce the point that L1/L2 was not fundamentally required by SDA itself.

The remaining question is really whether L2-only is cisco’s preferred long-term model, or simply the best fit for the way SDA automation and scaling are currently implemented...

Thanks for this exchange.