Hello John, I see the client end system (including its routing policy, etc.) also as a domain. For me there is no real different between a 'Linking domain' and a 'User domain'. Except that a User domain only has an egress *or* an ingress (while a Linking domain has an egress *and* an ingress port). I don't yet know if it are different objects and different instantiations of 'Domain'. In the Stitching Framework they are different instantiations. But there is a difference (like with your policies): A User domain can convey the requirements on the path (both policy, but also end-to-end SLA/performance/etc.), beside its internals (like actual delay, etc. only inside the domain). But perhaps a Linking Domain in general could even also make such 'demands' on the path (like "I only want to link if that GOLE/NREN in an other continent takes part"). All the best, Victor John MacAuley wrote:
Quick question that may be related. How would we model a client routing policy? For example, my organization has a policy against routing over links from another organization and I am requesting a schedule from the network. How does the NSA learn of this policy? I would assume it is a similar issue to specifying SLRG values, and the requesting client would specify the domain for exclusion.
John.
On 10-06-28 7:16 PM, John Vollbrecht wrote:
On Jun 28, 2010, at 3:02 PM, Freek Dijkstra wrote:
John Vollbrecht wrote:
[..] A domain of a single link however seems different [..]
[...] it is important to note that the adjacent network (not necessarily a node) enforces the policy of the link. This could be done by having the link delegate policy to the adjacent network or by having the adjacent network contact the policy server for the link. In the first case policy is run by the adjacent network for the link, in the second the adjacent network asks for approval from the link.
This is indeed the crucial question. From an architectural point of view, the former model is the easiest one, as the requester does not need to have knowledge about the delegation is done (the requester directly talks to the owner of the link without worrying how it is enforced). In the later model, the requester ask one domain for resources in another domain, and (presumably?) has to be aware of that.
For reasons of simplicity, I prefer the first model. As added advantage is that this seems very similar to how delegation is done for virtual networks.
It seems to me that the first model has some problems that might make it harder. The biggest is that it has to delegate policy for its domain to another domain. It is not clear how to do this in a standard way - perhaps XACML could be used to define policy and send it to the enforcing domain.
The alternative - having the enforcing domain query the link's policy requires knowing how to question the other domain policy server. This is pretty much what happens during connection reservation where there is no enforcement other than by provider NSAs accepting or rejecting a request.
Either way requires an SLA between enforcing domain and adjacent domain - one domain must trust that the other will enforce policy as agreed.
My thinking is that either of these ways might be best - perhaps in different situations. Some specific use cases would help.
John
Perhaps related is the question how NSI deals with domains that do not support NSI yet. This is something to consider -- if we create an architecture that only works if all domains in the world deploy it at the same time, then we risk that the deployment takes as long as, say, IPv6. I wonder if the second model you describe above (where a domain enforces the policy of a neighbouring domain that does not support NSI) is applicable to this situation as well.
Regards, Freek
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg