[Nsi-wg] Policy use cases
Henrik Thostrup Jensen
htj at nordu.net
Mon Mar 9 05:53:35 EDT 2015
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
More information about the nsi-wg
mailing list