>Your explanations make it very clear, thanks. Thanks, Andrei. Looks like we've converged on pretty much all issues that we've discussed so far in this thread. One comment inline below.
[...] >>> If my considerations are correct, there are only two cases - >>> upstreams/transit providers, for which RLP doesn't matter, and others >>> (customers and peers) where an RLP indicates a leak and has to be dealt >>> accordingly. >> >> Yes, I agree that detecting route leaks from customers/peers matters. >> Detecting route leaks from upstreams/transit providers does not really matter >> (as explained above). >I guess what I am arguing for is that the semantics of RLP 01 should be >"propagate only down" rather than "do not propagate up" and any updates >with the RLP field set from a peer or a customer should be treated as a >leak. OK, I see now what you meant. Your suggestion is good. In the draft, currently in Section 3.2.2 "do not propagate up" is interpreted (implicitly) as "propagate only down" for a peer. But with this change (as suggested above by you) , we no longer have to make that distinction. The semantics of RLP 01 would be the same whether an update is received from a customer or a peer. Then route leak detection algorithm would be the same for customer or peer, and sections 3.2.1 and 3.2.2 can be merged into one. Thanks. Sriram _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
