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 <[email protected]> on behalf of [email protected]
<[email protected]>
Sent: Tuesday, July 7, 2020 3:08 PM
To: Christian Hopps <[email protected]>
Cc: Huaimo Chen <[email protected]>; [email protected] <[email protected]>;
[email protected] <[email protected]>
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
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
