On Thu, 5 Mar 2015, John MacAuley wrote:
I have added three new policy use cases covering the two you described and the one for Chin. Can you have a look to make sure I captured them correctly?
So the examples look correct. There might be more cases. I am not an expert on this matter. One the important things is that policy cannot (necessarily) be validated/enforced by inspecting the cross-connect. Hence, it is not possible for some transit networks to know if a request adheres to a policy or not, when treated as a UPA. I am aware of the possibility of including source/destination STPs as proposed elsewhere, but that is flawed too (but I will answer that in another email replying to that slideset, as there are multiple issue with that). One thing that doesn't come up in the slides is the difference between describing policy and being able to enforce it. That is, being able to describe transit policies for a network, is not the same as the system being able to enforce it. It must be difficult (impossible is a stretch) to abuse the system. I.e., we cannot assume that all the actors in the system will play by the rules / have good intentions. And also to prevent screwups. There is also a lot more to this than just pruning a result set after doing Dijkstra. The (business) purpose of transit networks is to service their customers (who are paying for the infrastructure). The reason for peering is usual for mutual benefits between the network (saving money on transit, avoiding traffic tromboning, better resilience, better QoS, etc). But it is about providing better/cheaper service to the customers. This means we have two cases of requests for transit providers: 1. Request from customers. This is no problem, they are paying to use our infrastructure, and we have a business relationship with them. 2. Request from peer/transit. Ehh what. A non-paying entity is requesting resource allocation on a network, they do not pay to use. Sure, it might be to a customer, but the cross-connect pointing to a customer is not the same as the customer want is. This means that treating a transit network as a UPA leaves it dangling enforcement wide, as it does not know if the customer really wanted to setup the circuit. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet