Hi Alvaro, On Jan 2, 2014, at 1:27 PM, Alvaro Retana (aretana) wrote:
> 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. If you don't have any policy, how do you know WHICH stub networks to advertise outside 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). So, I guess you are statically configuring the routers hidden by the TTZ in order to manage them? I don't see this as advancing the art. Thanks, Acee > > > 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
