Re: [Lsr] Request for Working Group Adoption: Area Proxy

support

Sent from my iPhone

> On 04.06.2020, at 18:43, tony.li@tony.li 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr