[Nsi-wg] NML topology

[Gigi Karmous-Edwards]

Inder and All,


I also agree with all the below statements, with the exception that an 
"NSA must include RM capabilities". I can imagine an NSA that serves to 
process and break up a single request from a requester agent and then 
use the NSI to make sub-requests to other NSAs that do have RM 
capability. In this example the first NSA does not have resources that 
it directly manages and it also does not manage other NSAs.

In this way an NSA can be a neutral entity (broker) that is not 
associated with network resources.

Thanks,
Gigi

Inder Monga wrote:
>> I think owned and controlled are synonymous for our purposes - even 
>> if the physical device interface is delegated to a subordinate 
>> function (e.g. an RM) it is still under the control and management of 
>> the NSA.
>
> I agree with your comments. 
>
> Let me try to re-iterate the conclusions, so it can be captured in the 
> Architecture Document:
>
> - There can be only one owner of the resource that 
> controls/manages/provisions the resource. This is known as the 
> Resource Manager.
>
> - All others can only "request" access (provision, schedule, reserve) 
> to that resource from that resource manager (RM)
>
> - The service "request" interface is "Network Service Interface" (NSI).
>
> - NSI + RM = NSA. This does not mean they have to be the same software 
> module or function. The two functions can be distributed, but for the 
> outside world looking in, NSA includes the RM capability. 
>
> - ONE NSA can manage  MULTIPLE local RM's. The interface between NSA 
> and RM MUST NOT be a publicly accessible interface. An RM can ONLY be 
> controlled by a SINGLE NSA. 
>
> - An NSA can decompose the service request to multiple sub-requests 
> and send them to other NSAs. An NSA that decomposes the requests, MUST 
> compose the responses and respond to the original service request. 
>
> Inder
>
>
> On Feb 23, 2010, at 5:46 AM, Jerry Sobieski wrote:
>
>> Comments in line:
>>
>> Guy Roberts wrote:
>>> Freek,
>>>
>>> Some interesting questions, here are my thoughts your questions-
>>>
>>> Requirement 1:  In my opinion each network resource should be owned by only one NSA.  However, one NSA can own many resources.  I guess this means that 'owned' and 'controlled' are synonymous.  Though perhaps the distinction could be that a passive object (eg patchcord link) can only be owned and not managed?
>>>   
>> It seems to me even a passive patch cable is still managed - what 
>> happens if it breaks?   I think the issue here is that it is a 
>> component of a network, and b/y definition/ it is managed by the 
>> associated NSA.  (What that NSA needs to do - if anythng- to control 
>> or manage the patch cable is a separate issue. )   Also, often in 
>> this whole conflagration we find that one agent controls the port on 
>> one end of a link and another agent controls the port on the other 
>> end, and these two separate objects must *MUST* correspond to one 
>> another, ..so the configuration is negotiated via protocols and the 
>> link in-between simply reflects this agreed config.   It is sort of 
>> moot who actually owns the resource, or "controls" it, as that agent 
>> simply has the priviledge of writing the negotiated configuration 
>> into the device...
>>
>> I think owned and controlled are synonymous for our purposes - even 
>> if the physical device interface is delegated to a subordinate 
>> function (e.g. an RM) it is still under the control and management of 
>> the NSA.
>>
>> Jerry
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto: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
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100223/ab129c15/attachment.html