support Sent from my iPhone
> On 04.06.2020, at 18:43, [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
