Subject: [OSPF] OSPF Topology Transparant Zone

From: Acee Lindem <[email-masked]>
Date: Sat, 28 Dec 2013 23:42:20 +0000

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. 

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. 

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. 

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. 

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. 

Finally, if the core of the TTZ is opaque - how are providers going to manage it? 

Thanks,
Acee

---

From: Huaimo Chen <[email-masked]>
Date: Sun, 29 Dec 2013 20:21:21 +0000

Hi Acee,

    Thanks much for your comments!
    My answers/explanations are inline below.

Best Regards,
Huaimo
-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem
Sent: Saturday, December 28, 2013 6:42 PM
To: OSPF List
Subject: [OSPF] OSPF Topology Transparant Zone

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.

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. 

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.

Huaimo:
We will do some analysis on this. If there is any big issue, we will resolve it.

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.

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-masked]
https://www.ietf.org/mailman/listinfo/ospf