[Nsi-wg] Policy use cases

[Henrik Thostrup Jensen]

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