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

[steve ulrich <[e-mail]>]

support.

On Thu, Jun 4, 2020 at 11:42 AM <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>


-- 
steve ulrich (sulrich@botwerks.*)