On 12/28/13 6:42 PM, "Acee Lindem" <[email protected]> wrote:
Acee: Hi! Happy New Year! >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. I'm not going to argue with that. It is very easy to discuss either side on paper. ;-) But I do want to clarify one point that you mention several times: connectivity inside the TTZ. You mention it when talking about policy and management. There is no topology information advertised outside the TTZ, but reachability *is* advertised. Specifically Section 6 says: In addition, the LSA may contain a third group of links, which are stub links for other destinations inside the TTZ. They may be the loopback addresses to be accessed by a node outside of the TTZ. I know you made a point about scalability advertising the reachability this way. My point here is just to clarify that (1) there is no additional policy needed because the reachability is in fact advertised (unless you have a use case not to), and (2) there is no change to management because all the internal nodes should be reachable (besides being aware of the TTZ, of course). Alvaro. > > >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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
