[Nsi-wg] interim call tomorrow

[Tomohiro Kudoh]

Hi Chin and all,

I just mapped Chin's components to the modules of my architecture
proposal at OGF27 meeting.

External interface: NSI server module & NSI client module
- I think north interface and south interface should be distinguished.
  This is not a classification based on the functionality the agent provides.

Topology manager: Agent finding service?
- Now I think AFS is not an appropriate term here. It represents
whatever external service.

NSA Look up service: Agent selection module

Local Resource Coordinator: Local Resource Manager Module

Authentication service: included in the NSA server module and NSA client module
- making this separate and clear is good.

Authorization service: not clearly defined in my architecture

Notification service: not clearly defined in my architecture
- whether to have notification mechanism or not is a matter of the
server module and client module
- the information to be provided to the client is naturally prepared
by the aggregation module

Path finding service: ?
- I am not sure the definition and the difference of NSA look up
service and this service







2009/11/4 Chin Guok <chin at es.net>:
> Hi all,
>
> Here's an initial draft of the NSA functional components.  There are some
> comments from Radek that I left inline for discussion.
>
> Thanks.
>
> - Chin
>
> --On November 3, 2009 2:43:56 PM -0500 John Vollbrecht <jrv at internet2.edu>
> wrote:
>
>> We will have an interim call tomorrow.    My proposed agenda is to
>> talk about work under way,   I suggest
>>
>> 1. Joan's slides modified from OGF
>> 2. Review block diagram - from Tomohiro slides at OGF
>> 3. Go over status -- my view of where we are is below.
>>
>> I am hoping we can make some progress before SC, and then have
>> sections 2,3, and 4.b, 4.h, 4.j. and part of section 5 available as
>> candidate sections for the recommendationrecomendation -- by the end of
>
> the year.
>>
>> We can talk about whether this seems possible.
>>
>>
>> My view if status -  please comment --
>>
>> I am thinking that we need to make some progress on actual document in
>> the next few weeks.  Progress for me will be to have some sections in
>> place that are ready for detailed editing.
>>
>> Section 1 - Summary and Abstract  [to be done]
>>
>> Section 2 - Context and Motivation
>>
>> I think we are close on the first part section 2 the context and
>> motivation.    I keep thinking of some changes to it as I go along,
>> but I think it is ok as a starting point for editing.
>> We are planning a second part of section 2 that describes service and
>> transport planes and their relation to other planes.  I believe that
>> Inder will propose something for that.
>>
>> Section 3 - Concepts and Terminology
>>
>> We have documentation that covers most of this.  However, in my view,
>> after rereading in a couple times, it needs to be revised to
>> correspond with the NSA model that we came up with in Banff,
>> particularly the concepts of Agent Selection and Aggregation, and the
>> naming of NSI server and client model.  I think we should talk this
>> through on the call to be sure we all agree and I can rework the
>> section.
>>
>> I believe that the transport terms described in the second part of
>> this section are ok for a version to be edited.  I will modify the
>> order of some of this section when I do the first part.
>>
>> Section 4 -- Architecture (details)
>> 4.a Services offerred over NSI [hold till after 4.b]
>>
>> 4.b Block diagram of requestor and service agents
>>        This will build on diagrams from Tomohiro at OGF.  Chin has
>> offerred
>> to provide a first cut at all modules.  Many are are interested in
>> helping to define this, including Chin, Radek, Tomohiro, Joan and
>> others].  I believe the hope is that discussion on this can occur on
>> the skype chat as well as on calls and email.
>>        I think that this is key to defining much of the rest of the
>> document.  The blocks help define what is done by an  agent, and allow
>> the agent to use interfaces other than NSI by some blocks.  It also
>> helps explain the recursive nature of calls to other NSAs.  It also
>> helps to clarify what a request needs to contain.
>> This is a NSA architecture section that provides context for the NSI
>> interface
>>
>> 4.c Domain interaction --
>> As I think about this, which I believe Tomohiro proposed, I think it
>> is meant to define what a domain is, especially relative to a NSA.  I
>> am thinking this might better be called "recursive NSAs" or hierarchy
>> imposed by aggregation module, or something else.  Any thoughts about
>> that?
>>
>> 4.e Responsibiliy division between Management, Control, Transport, and
>> Service Plane.
>> I am not sure how this will be different that section 2.2, except more
>> detailed
>>
>> 4.f Security and Accounting (I have volunteered for a first cut at
>> this, but not till earlier sections are farther along)
>>
>> 4.g. Deployment [of multiple NSAs] architecture [hold till earlier
>> sections done]
>>
>> 4.h Messaging interaction [ Tomohiro has volunteered to take the lead
>> on this]
>>        two phase commit (required or not), synchronous / asynchronous
>> message triggers
>>
>>        path description in reservations - I will take initial lead on
>> this
>>
>> 4.i Request and Response messaging characteristics
>>        Resources (objects) and parameters, and their topology [Guy]
>>
>>  Section 5  Imlementation and Deployment frameworks
>>        Overview [Joan, Tomohiro, John, Inder]
>>        Using NSI in othe models - GMPLS, GRID, GENI [John, Joan]
>>        Application examples of NSI - [KDDI, LHC, CoUniverse, other?]
>> _______________________________________________
>> 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
>
>