Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen <[e-mail]>]

Hi Tony and Chris,

    Thank you very much for your comments.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo node. That is that a zone can be smoothly transferred to a single pseudo node, and the pseudo node can be smoothly rolled back to the zone.
This strikes me as the important difference from area proxy. It certainly adds complexity to things, I wonder if it's worth it?
    It is worth it because it reduces service interruption and improves customer experiences.

    When users plan to do these operations on a network, they will select a maintenance window. During this window, there should be minimum service traffic being transported in the network. However, there is still some live traffic in the network even during this window in general. If we do not provide smooth transferring between a zone/area and its single pseudo node, some live traffic will be lost even during this window while doing the transferring.

    There are some challenges for providing smooth transferring between a zone and its single pseudo node. I believe that we will be able to have a good enough solution. We have had a prototype implementation of smooth transferring a zone to the zone edges' full mess in OSPF. The testing shows that a zone (block of an OSPF area) is smoothly transferred to its edges’ full mess without any routing disruptions.  In addition, we have spent lots of time and efforts on smooth transferring between a zone and its single pseudo node. Moreover, we may get suggestions from the experts in IETF, especially in LSR WG.

Best Regards,
Huaimo

________________________________
From: Tony Li <[e-mail]> on behalf of [e-mail] <[e-mail]>
Sent: Tuesday, July 7, 2020 3:08 PM
To: Christian Hopps <[e-mail]>
Cc: Huaimo Chen <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Moreover, TTZ provides smooth transferring between a zone and its single pseudo node. That is that a zone can be smoothly transferred to a single pseudo node, and the pseudo node can be smoothly rolled back to the zone.

This strikes me as the important difference from area proxy. It certainly adds complexity to things, I wonder if it's worth it?


FWIW, we looked at this quite seriously a while ago. Turning abstraction on and off is simply not a daily occurrence. Doing it properly requires careful thought and planning.
Where are the boundaries? What prefixes will be advertised and with what metrics? How will the affect traffic flow?

The corner cases that happen when you are in this transition are large. We have to deal with the issue of the metrics that are abstracted away.  We chose to go down the path
of intra-area vs. inter-area metrics, exactly as OSPF does. But if you do this, then you have an issue: the metrics are different when abstraction is enabled or disabled and
different nodes will compute different paths depending on which LSPs have propagated to them. This seemed like a wonderful opportunity for forwarding loops. This
is especially problematic when abstraction is enabled, as there is now an entire area’s worth of LSPs that need to age out before you can be assured of consistency.
Yes, you can try to purge them, but purges aren’t the most reliable thing in the world.

Net net, we felt that the complexity exceeded the benefit. Yes, there is benefit there, but from the pragmatic viewpoint of making it work in production, the risks and costs seemed very high.
We expect that operators would want to make the change in a maintenance window anyway, and as long as you’re having a maintenance window, you might as well do things the
simpler way.

Regards,
Tony