On October 6, 2015 at 17:46:41, Black, David (david.bl...@emc.com) wrote: > Rob, > > > Given that we are really selecting candidates from within a set of paths > > that > > have already been selected by OSPF as valid, and usable - then I’m not sure > > that I can understand the logic behind this sentence from your review: > > "There > > appears to be more than enough enabled by this draft to wreak serious > > operational havoc”. > > Perhaps, I'm not understanding something, but I thought I saw an > unreachability > problem in the example in Section 4.5/Figure 3: > > - The following example of an explicitly routed policy: > > - Traffic from A nodes to I nodes must not go through R and T > nodes > > prevents the leftmost pair of A nodes from sending traffic to the > I nodes. Was this "black hole" intended as part of the example? > > Was that a mistake, and at least one path from the leftmost pair of A nodes > to the I nodes will be selected despite that "explicitly routed policy”?
If the operator chooses to deny prefixes being installed in the RIB based on these tags, then yes, they could end up with unreachability problems. However, an operator can do this today with any routing policy (a number of implementations already have inbound route filtering) - we should not prevent this kind of mechanism based on the fact that an erroneous config might be problematic. In the case that the operator *preferences* things based on the tags, then this would not be an unreachability problem - OSPF would still correctly determine that there is a path between all nodes in the pictured network - and this would be installed in the RIB as per normal operation. (My memory is not 100% clear on whether this is intended as part of the example, if it is, then the text should be clarified I agree.) Kind regards, r. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
