> > Self-rephrasing - if a solution to provide 100% coverage is > topology > > dependent then it simply doesn't provide 100%, there's no "right > topology" > > to apply to every network. > > No, and I don't think we need to be in the business of > standardizing topologies. But look at it the other way. If > a technology provides 100% coverage in some real-world > technologies that people are using today but provides 98% in > other topologies that are also in use, that technology seems > appropriate for the first case. Whether it's appropriate for > the second is up to the operator of the second.
Well, certainly we should not standardise topologies. :-) Maybe providing guidelines on how to build/extend topologies to be more suitable for non-full coverage solutions. Work has already been done on this e.g. for LFA. Up to now, concerns regarding non-full-coverage solutions are the following: 1. bidirectional coverage (i.e. when a solution claims e.g. 90% coverage, it could be closer to 80% in reality for practical traffic). 2. Potential struggle by the operator on knowing which of the traffic flow/failure cases are covered and which are not covered. 3. Potential struggle by the operator on knowing how exactly coverage changes after topology changes. 4. This has not been mentioned yet, but I do feel that if a proper 100% solution gets standardised and gets trusted by operators, then in a couple of years operator topology design guidelines could be relaxed *somewhat* towards a *little* less-dense connectivity, as to rely a little bit more on network layer redundancy instead of parallel or near-parallel links close to each other and quite dense mesh. So it could result in some cost reduction in the future. 5. There is talk on pushing IP/MPLS (LDP) down towards access, where topologies are not so meshy but a full-coverage solution could work with a few cross-links. Background for 4 and 5: non-full-coverage solutions perform the better, the more densly meshed the topology is, while a 100% solution could work also on a relatively rare topo. Andras _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
