[Nsi-wg] Topology virtualisation

[Victor Reijs (work)]

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 at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
>