Support. Rgs, R.
On Thu, Jun 4, 2020 at 6:42 PM <[email protected]> wrote: > > Dear Gentlebeings, > > I would like to formally request working group adoption of “Area Proxy for > IS-IS” (https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03). > > The goal of this work is to improve scalability of IS-IS when transit L1 > areas are in use. In legacy IS-IS, for the L1 area topology to be utilized > by L2, part of the topology must be configured as both Level 1 and Level 2. > In the case where the transit topology is most or all of the L1 area, this > creates a scalability issue as the size of the L2 LSDB approaches that of > the entire network. > > We propose to address this by injecting only a single LSP into Level 2. We > call this the Proxy LSP and it contains all reachability information for > the L1 area plus connectivity from the L1 area to L2 adjacencies. The > result is that the L1 area is now opaque, reachable, and fully capable of > providing L2 transit. > > Our use case is the deployment of Clos topologies (e.g., spine-leaf > topologies) as transit nodes, allowing these topologies to replace > individual routers. We also see applications of this approach to abstract > entire data centers or POPs as single nodes within the L2 area. > > There are two other proposals of note before the working group. > > In Topology Transparent Zones ( > https://tools.ietf.org/html/draft-chen-isis-ttz-08), an area (or zone) > may be represented by a single node or as a full mesh of tunnels between > the edges of the zone. In addition, there is a mechanism to attempt to > seamlessly enable and disable the effectiveness of the zone. Relative to > our proposal and for our use cases, the full mesh of tunnels is not as > effective at providing scalability. In the specific case of spine-leaf > networks, the leaves are typically the majority of the nodes in the > network. As they become the edges of the area, with the full mesh approach, > the majority of the area is not abstracted out of the L2 LSDB. For our use > case, we have concerns about enabling and disabling the abstraction > mechanism. There is added complexity to support this mechanism. In networks > at scale, disabling abstraction may cause scalability failures. Enabling > abstraction may cause failures as LSPs age out at dissimlar times. We feel > that establishing abstraction is fundamental to the architecture of the > network and that changing it on the fly is a highly risky operation, best > suited for maintenance windows. Accordingly, the additional complexity of > the transition mechanism is not required. > > In IS-IS Flood Reflection ( > https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01), > abstraction is achieved by mechanisms similar to ours, but transit service > is achieved by tunneling transit traffic. That’s not necessary in our > propsal. In Flood Reduction, the also is coupled to the flooding > reduction, whereas in our proposal, the two are independent, tho they do > share the Area Leader mechanism. > > While both of these proposals are very worthy, we believe that our > proposal has substantial merit. We ask that the WG adopt Area Proxy for > further work. > > Regards, > Tony & Sarah > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
