Agenda for OMIS meeting on 10/09/07

[Heidi Picher Dempsey-2]

Thank you to those who have volunteered to help lead discussions at the
OMIS working group meeting this week.  I expect a fairly informal round
table discussion this time around.  I will send out a summary of the
meeting to the rest of the mailing list later in the week.  I hope you
are all already thinking about operational issues in GENI, and that
this meeting will stimulate useful discussions on the mailing list.  
The following is a rough agenda.  Feel free to send me email if you
would like to add topics.


Heidi Picher Dempsey, BBN                                 Welcome and
Charter summary
Matthew Davy, Indiana University                        Operational
support for research networks--lessons from other testbeds
Jon-Paul Herron, Indiana University GRNOC    Data collection,  
monitoring and support:  NLRview experiences
Kevin Miller, Duke University                                 Aspects
of authentication and authorization
Stephen Farrell, Trinity College Dublin               Security and
Private Key Infrastructures
Keren Bergman, Columbia University                 Discussion of some
cross-layer questions from the GENI optical workshop
Michael A. Patton, Network Consultant               Network engineering
questions
All Key GENI Operations Functions, Q&A
Heidi Picher Dempsey                                           Summary
and Close


Several people have mentioned that it would be good for the OMIS group
to be able to discuss items that come up in the other working group
meetings that are related to the OMIS charter.  If there is sufficient
interest, we may schedule a short follow-up meeting during lunch on
Thursday  10/11.  Of course, discussions can also continue on the
mailing list until the next GENI Engineering Conference.


_______________________________________________
omis-wg mailing list
omis-wg@...
http://lists.geni.net/mailman/listinfo/omis-wg

[Williams, James G]

Some Operations, Management, Integration and Security (OMIS)
Observations from the GENI Engineering meeting...

The OMIS WG met at the beginning (first meeting on the first day) of the
GENI Engineering Conference.  This was a bit of a problem, as we never
had an opportunity to meet after hearing the talks and discussions
within the other WGs.  Hopefully we can use the mailing list as a forum
to discuss issues that were raised later in the meeting.

Here are some observations and issues that I thought were interesting...

1. GENI will present an opportunity (will require us) to think
about Operations in an entirely new way.  This is probably obvious to
everyone.  But, it was not obvious to me.  I had imagined Operations as
the "rational braking function" for experimentation.  To some extent
that may be true.  But, I now see a broad new opportunity (requirement)
for Operations to dramatically change how it relates to the network and
experimenters.  See point #3 below.

2. The Operations WG needs to raise its profile with some of the
GENI participants.  One participant said, "Well, the real GENI network
won't be built for 5 years.  We can begin to worry about Operations
then".  IMO that is a recipe for disaster.   We can counter that type of
thinking (Operations can come last and sweep up the pieces).  When the
System Engineer for the WG is in place, this should raise the visibility
of the WG and increase interactions with the other WGs.

3. One interesting problem, among many, will be how to document and
inform Operations about the state of the network automatically.
Historically Operations needs to know operational state information so
that operational problems can be traced back to causes.  'What has
changed in the network?"    But, maybe reflecting back to point #1, this
is not the best way to think about Operations in a GENI context.  It is
hard to imagine how this will work when there are 100 experiments
operating on GENI.

4. Another tricky problem will be measurement. The Ops WG must
define a standard measurement set.    This measurement set will be
critical to the operators of the network in determining the state of the
infrastructure and guiding possible corrective actions.  This
measurement set will also be offered to experimenters as a standard
measurement package to support their experiment.  At the same time, the
Exp WG will define other measurement support sets, perhaps different for
each type of experiment, perhaps different for each individual
experiment.  These experimental measurement sets will be critical for
the experimenters, as they will be the data used to determine, at least
in part, the success or failure of an experiment.  As an experiment
evolves, it may become a part of the GENI facility (Jon Turner's
programmable router is one possible example) and its measurement set
would become a part of the Operations measurement set and offered to all
experiments.

5. Measurement is only one area of critical interactions between
the Exp WG and the Ops WG.  What is the best way to encourage (mandate?)
productive interaction between these groups?  A failure scenario has the
Exp WG sending undefined and unclear operational requirements to the Ops
WG.  The Ops WG then bounces back all requests without any
consideration, as the Ops WG has important Ops issues to consider.  WG
interactions that occur every three-four months actually encourage this
unproductive interaction.  More, closer coordination between WGs is
required.  Perhaps that can be stimulated by interactions on the mailing
list and also by scheduled interactions among the System Engineers.


These are just some observations and ideas, not fully formed.  They are
designed to stimulate discussion on the list...(where there does not
seem to be much discussion).

Jim Williams
Indiana University




_______________________________________________
omis-wg mailing list
omis-wg@...
http://lists.geni.net/mailman/listinfo/omis-wg

[Weisong Shi]

Hi Jim,
    Thanks your summary and input. I agree that we the operation and
management of GENI should be involved in the whole process of GENI
design. OMIS is a process, rather than a product.

    Regarding to how to measurement, I think it is a good idea to
introduce reputation into the systems as a metric. The reputation will
be used as an indicator of the quality and behavior of contributing
cites. We have a dedicated workshop on Trust and Reputation Management
in Massively Distributed Computing Systems (TRAM).
http://www.cs.wayne.edu/~weisong/tram08.html.

Thanks,
-Weisong

Williams, James G wrote:

> Some Operations, Management, Integration and Security (OMIS)
> Observations from the GENI Engineering meeting...
>
> The OMIS WG met at the beginning (first meeting on the first day) of the
> GENI Engineering Conference.  This was a bit of a problem, as we never
> had an opportunity to meet after hearing the talks and discussions
> within the other WGs.  Hopefully we can use the mailing list as a forum
> to discuss issues that were raised later in the meeting.
>
> Here are some observations and issues that I thought were interesting...
>
> 1. GENI will present an opportunity (will require us) to think
> about Operations in an entirely new way.  This is probably obvious to
> everyone.  But, it was not obvious to me.  I had imagined Operations as
> the "rational braking function" for experimentation.  To some extent
> that may be true.  But, I now see a broad new opportunity (requirement)
> for Operations to dramatically change how it relates to the network and
> experimenters.  See point #3 below.
>
> 2. The Operations WG needs to raise its profile with some of the
> GENI participants.  One participant said, "Well, the real GENI network
> won't be built for 5 years.  We can begin to worry about Operations
> then".  IMO that is a recipe for disaster.   We can counter that type of
> thinking (Operations can come last and sweep up the pieces).  When the
> System Engineer for the WG is in place, this should raise the visibility
> of the WG and increase interactions with the other WGs.
>
> 3. One interesting problem, among many, will be how to document and
> inform Operations about the state of the network automatically.
> Historically Operations needs to know operational state information so
> that operational problems can be traced back to causes.  'What has
> changed in the network?"    But, maybe reflecting back to point #1, this
> is not the best way to think about Operations in a GENI context.  It is
> hard to imagine how this will work when there are 100 experiments
> operating on GENI.
>
> 4. Another tricky problem will be measurement. The Ops WG must
> define a standard measurement set.    This measurement set will be
> critical to the operators of the network in determining the state of the
> infrastructure and guiding possible corrective actions.  This
> measurement set will also be offered to experimenters as a standard
> measurement package to support their experiment.  At the same time, the
> Exp WG will define other measurement support sets, perhaps different for
> each type of experiment, perhaps different for each individual
> experiment.  These experimental measurement sets will be critical for
> the experimenters, as they will be the data used to determine, at least
> in part, the success or failure of an experiment.  As an experiment
> evolves, it may become a part of the GENI facility (Jon Turner's
> programmable router is one possible example) and its measurement set
> would become a part of the Operations measurement set and offered to all
> experiments.
>
> 5. Measurement is only one area of critical interactions between
> the Exp WG and the Ops WG.  What is the best way to encourage (mandate?)
> productive interaction between these groups?  A failure scenario has the
> Exp WG sending undefined and unclear operational requirements to the Ops
> WG.  The Ops WG then bounces back all requests without any
> consideration, as the Ops WG has important Ops issues to consider.  WG
> interactions that occur every three-four months actually encourage this
> unproductive interaction.  More, closer coordination between WGs is
> required.  Perhaps that can be stimulated by interactions on the mailing
> list and also by scheduled interactions among the System Engineers.
>
>
> These are just some observations and ideas, not fully formed.  They are
> designed to stimulate discussion on the list...(where there does not
> seem to be much discussion).
>
> Jim Williams
> Indiana University
>
>
>
>
> _______________________________________________
> omis-wg mailing list
> omis-wg@...
> http://lists.geni.net/mailman/listinfo/omis-wg
>
>  

_______________________________________________
omis-wg mailing list
omis-wg@...
http://lists.geni.net/mailman/listinfo/omis-wg