Hi Acee,
Thanks much for your comments!
My answers/explanations are inline below.
Best Regards,
Huaimo
-----Original Message-----
From: OSPF [mailto:[email protected]] On Behalf Of Acee Lindem
Sent: Saturday, December 28, 2013 6:42 PM
To: OSPF List
Subject: [OSPF] OSPF Topology Transparant Zone
We've discussed this proposal at several IETF meetings now and at IETF 88 we
committed to more discussion on the list due to the variance in opinions. I
feel that while the TTZ mechanism has some admirable goals. However, I don't
believe it satisfies its claims and believe this would be apparent if it were
to implemented and deployed.
Huaimo:
There is a saying: "Hearing about it a hundred times is not better than seeing
it once (seeing is believing)". We will try to implement the TTZ and let people
seeing its advantages.
The main goal of TTZ is scalability. However, all the comparisons have no IP
visibility into the TTZ. This begs the question of why the TTZ internal routers
exist in the first place if there is nothing to be advertised outside the TTZ.
Also, even without any connectivity, there is full mesh of P2P connections
between TTZ border routers. The LSAs for the border routers will change every
time any P2P cost across the TTZ changes. Thus one is trading more small LSAs
for fewer LSAs that are larger and change more frequently. This is not
necessarily a win.
Huaimo:
Splitting a network from one area into multiple areas or from a number of
existing areas to even more areas for resolving scalability issue, is a very
challenging task and may raise some new issues.
At first, it is a time consuming job. For some networks, it may take more than
one year. For some networks, it may take a couple of months. Because there are
significant changes on network architecture when splitting a network with one
area into multiple areas or splitting a network with some existing areas into
even more areas. Considering the one area case, originally the network has only
one area, which is the backbone area. This original backbone area will be split
into a new backbone area and a number of non backbone areas. In general, each
of the non backbone areas is connected to the new backbone area through the
area border routers between the non backbone area and the backbone area. There
is not any direct connection between any two non backbone areas. Each area
border router summarizes the topology of its attached non backbone area for
transmission on the backbone area, and hence to all other area border routers.
Secondly, service may be interrupted while the network is being split from one
area into multiple areas or from a number of existing areas into even more
areas.
Moreover, it is complex for MPLS TE tunnel to be set up after the network is
split.
In addition to resolving the scalability issue, the TTZ does not have the above
new issues.
A secondary claim is that the TTZ requires less policy. However, I don't
believe it is realistic to have no connectivity inside the TTZ. Hence, we will
need some type of policy to control what is and isn't leaked. So, we are
trading a TBD TTZ policy for the area policies that have been deployed for
decades.
Huaimo:
It seems that there are two sets of policies at an area border router: one set
for controlling route leak from backbone to non backbone area, the other for
controlling route leak from non backbone to backbone area. In TTZ, there is no
policy for the former at a TTZ border router. The policy for controlling the
route leak from the inside TTZ to outside at a TTZ border router may be
automatic or semi-automatic.
Given there are no summary LSAs, one will need to advertise these leaked routes
as stub networks in the TTZ border router-LSAs. This will further add to the
scaling problems with large frequently changing router-LSAs. IMO, this is a
very bad tradeoff.
Huaimo:
We will do some analysis on this. If there is any big issue, we will resolve it.
There is also a claim of simpler Traffic Engineering. This assumes that the TTZ
border routers perform so unspecified magic to make it all transparent. It
would seem the RSVP signaling would have to somehow be made transparent as well
as OSPF.
Huaimo:
We are working on TTZ Traffic Engineering part. It seems that RSVP-TE is well
fit for the TTZ. The TTZ border routers make the TTZ as a fully messed TE link
connections among the TTZ border routers. The RSVP-TE signaling for an MPLS TE
LSP crossing the TTZ is almost the same as before (the existing way). It
signals the segment of the LSP to the TTZ border router in the same way as
before. At this TTZ border router, it just gets the detail TE path inside the
TTZ and then signals the segment of the LSP inside the TTZ to another TTZ
border router in the same way as before. From this exit TTZ border router, the
RSVP-TE continues to signal the rest of the LSP in the same way as before.
Finally, if the core of the TTZ is opaque - how are providers going to manage
it?
Huaimo:
This is similar to the backbone area. On a router outside of the backbone area,
providers cannot see anything inside the backbone area. When they log in to a
(border) router of the backbone area, they can see all the details about the
backbone. On a router outside of the TTZ, providers cannot see anything inside
the TTZ except for the TTZ border routers. When providers log in on a TTZ
(border) router, they can see all the details about the TTZ.
Thanks,
Acee
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
