Nabble - GENI OMIS WG

First draft of OMIS agenda for GEC5

2009-07-13T13:55:04Z

GEC5 is next week. OMIS will be meeting Tuesday from 3:30 to 5:30
(last session of the day). The first draft of the agenda has been
posted (see http://groups.geni.net/geni/wiki/Gec5OmisAgenda, or follow
link from main GEC5 agenda), and is copied below. Any comments or
suggestions are welcome. We hope this will be much more of a
"working" session. We aren't planning large presentations, but only a
few slides (if any) to spark discussion on various OMIS related
topics.

-MAP (OMIS WG SE)

----------------------------------------------------------------
= ''Draft'' Agenda for OMIS meeting at GEC5 =

The fifth [http://groups.geni.net/geni/wiki/Gec5Agenda GENI
Engineering Conference] will be held in Seattle, WA from July 20 to
22, 2009. The OMIS WG will meet from 3:30 to 5:30 pm on Tuesday, July
21. This is the ''draft'' agenda for what we will do during that
time. In particular, the order and amount of time are just guesses.
This is already tight on time, but any suggestions for other topics
that should be added, or lightning talks you'd like to do, can be sent
to the [mailto:HPD@... Chair]/[mailto:MAP@... SE] or to the
[mailto:OMIS-WG@... mailing list] for discussion.

== Agenda ==
* Administrivia - WG Chair (Heidi Picher Dempsey) 5 mins
* Introduction, agenda bashing and orientation
* Integration status
* Network (Mike Patton) 15 mins
* Operations (Jon-Paul Herron) 15 mins
* Security (Stephen Schwab) 15 mins
* Discussion starters
* Emergency Shutdown: operational concerns, security, etc. 30 mins
* Data sharing when the data is distributed 30 mins
* Distributed authorization (if time and not already covered)
* Lightning Talks (max 5 mins each)
* Quilt status update (Jen Leasure)
* others as time permits

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

OMIS working group call

2009-07-10T11:53:17Z

We will have a teleconference next Monday 7/13 from 2:30-3:30PM EDT to
discuss plans for the upcoming OMIS working group meeting at GEC5. If
you have any suggestions for the meeting in Seattle, or if you would
like to speak at the meeting, please be sure to dial in. Suggestions
via the mailing list are always welcome as well.

Dial-in info:
(866) 453-5550
Partic. Pin: 4873431#

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

Draft agenda for OMIS WG meeting at GEC4 now on wiki

2009-03-14T20:14:29Z

I've posted a first cut at an agenda for the OMIS WG session at GEC4
in Miami on the wiki. Take a look at
http://groups.geni.net/geni/wiki/GeniOmisGEC4
and send any comments (such as additional items) to the mailing list.
Everyone should take a look, if you were expecting to present and are
not on the agenda, definitely speak up. As Heidi posted earlier we
will be having a teleconference on Tuesday to work out details, feel
free to join in.

See you in Miami,

-MAP

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

OMIS working group call

2009-03-13T09:13:16Z

We will be having a teleconference next Tuesday 3/17 from 1-2PM EDT to
discuss plans for the upcoming OMIS working group meeting at GEC4.
We'll have a draft agenda published on the OMIS wiki page before the
teleconference. If you have any suggestions for the meeting, or if
you plan to speak at the meeting, please be sure to dial in.
Suggestions via the mailing list are always welcome as well.

Dial-in info:
(866) 453-5550
Partic. Pin: 4873431#

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

DRAFT GENI Recommended Use Policy

2009-03-10T19:04:37Z

As some of you will remember, the OMIS meeting at GEC3 included a
discussion of security issues for GENI operations. One of the
suggestions made there was to draft a GENI security policy. (You can
listen to the discussion, or read summary notes by following the links
at http://groups.geni.net/geni/wiki/GeniOmis.) I've posted a
discussion draft of a GENI Recommended Use Policy at http://groups.geni.net/geni/wiki/RUP
as a first step. I've tried to follow the main spirit of the
discussion at GEC3, and include only those restrictions that seem
absolutely necessary for GENI operations. I'm sure opinions will
differ on this, so please reply to the mailing list with comments.
The OMIS group will also be discussing this document at our GEC4
meeting. The final policy will be used for Spiral 1.

For those of you who'd rather avoid the wiki, I've included the core
text from the Recommended Use policy. (Thanks to the PlanetLab
Acceptable Use Policy authors, from whom I've borrowed much, as
recommended by many at the OMIS meeting.

-Heidi

--------
2 GENI Use Overview
The suite of GENI facilities coordinated by the GENI Project Office
(GPO) is meant to support network science and engineering experiments,
and to provide a collaborative environment in which participants can
evaluate prototypes and gain a better understanding of the behavior
and utility of various design alternatives. In addition to sponsored
development projects, the GENI facilities suite may include resources
contributed by research and commercial organizations and individuals.
These resources are governed by their local policies, as well as by
GENI guidelines. GENI facilities should be used only for research and
education purposes. GENI does not allow illegal activities

3 Guidelines
All GENI use should be consistent with the goals expressed in the use
overview.

All individuals contributing to the suite of GENI infrastructures
should follow these guidelines. Individual sites that contribute GENI
infrastructure may also have separate guidelines and Acceptable Use
Policies (AUPs). GENI participants should not knowingly violate local
AUPs.

Many GENI resources are hosted and donated by organizations interested
in the GENI project, and GENI work should not adversely affect those
organizations. GENI participants should adhere to widely-accepted
standards of network etiquette. Software and hardware should be
debugged in a controlled environment prior to moving to GENI
infrastructures, so that system behaviors are well understood before
they become part of shared infrastructures. Participants should
ensure their work does not disrupt other infrastructure, (for example
by using more than their share of bandwidth or performing systematic
port scans on local machines). If such an event is reported, the
participant will be expected to investigate and address the issue if
it appears to be related to their work. The GPO will provide guidance
if requested for participants who are unsure whether their work might
adversely affect local infrastructures.

GENI participants are responsible for ensuring that their
experiments, prototypes, or contributed infrastructure cannot be
hijacked and used to attack or spam other infrastructure or users. If
such an event occurs despite the participants’ best efforts, they are
expected to investigate and remediate resultant problems. Although
the GPO-sponsored GENI operations mailing list may receive initial
complaints about misbehaving services or systems, staff from the
operations list will put complainants in direct contact with the
researcher or development project lead responsible for reported
problems, and follow the response emails.

GENI resources are accessible to various opt-in users, who may not be
officially registered with GENI clearinghouses. Researchers who
sponsor services that include these users are responsible for ensuring
that their users do not violate the GENI infrastructure recommended
use policy.

GENI offers no privacy guarantees on data sent to and from the GPO-
coordinated GENI suite of infrastructure. GENI participants should
assume data will be monitored and logged, for example to investigate
abuse. GENI also offers no reliability guarantees. Systems and
services may be rebooted, briefly taken off-line, and reinstalled
without prior warning

4 Consequences
This is a collaborative infrastructure, and the nature of some
violations may require immediate action to protect the rest of the
community (for example responding to a denial-of-service attack).
Staff on the GPO-sponsored GENI operations mailing list will strive to
contact all parties involved in a suspected or reported violation, and
to discuss options with those parties before taking action to address
the violation. Staff will take action before reaching all parties if
necessary. Local providers or project participants may act
independently if they perceive an immediate threat, although GENI
encourages coordination with the GENI operations mailing list.

Violation of this Recommended Use Policy may result in any of the
following:
* disabling experiments, systems, or users access to GPO-
coordinated GENI infrastructure
* removing sites or resources from the GPO-coordinated GENI
infrastructure
* Informing the participant’s administrative organization of the
violation
* Informing the GENI community, including the National Science
Foundation, of the violation

To report a suspected violation of this policy, contact the GENI
operations mailing list (geni-ops@...).

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

Re: Draft Spiral 1 Security Design Report

2009-03-04T07:11:03Z

Agreed -- both good points to address. Keep in mind that with limited
time, we've got to focus on some aspects while deferring other aspects
of the security architecture into subsequent months and years of work.
The backlog of things to work out on paper is large.

--Steve

-----Original Message-----
From: Heidi Picher Dempsey [mailto:hdempsey@...]
Sent: Wednesday, March 04, 2009 8:27 AM
To: Bon sy
Cc: omis-wg@...
Subject: Re: [omis-wg] Draft Spiral 1 Security Design Report

On Mar 3, 2009, at 12:01 PM, Bon sy wrote:

> Hi
> I just finished the first read of the report. Thanks for the
> effort!
>
> I have two high level questions:
>
> First, I am curious why there is no discussion on the accounting
> aspect;
> the third "A" in AAA (Authentication, Authorization, and
> Accounting). I
> would think some level of discussion on accounting would be
> necessary if
> we are to provide meaningful audit and forensic analysis as
> mentioned in
> the report. I would also think that accounting information may be
> useful
> for providing some guidance on how to approach isolation on
> experimentations.

This is worth discussing more on the list. At a high level, we expect
the aggregates to be doing much of what would normally be considered
accounting. But you are right that there will be some records kept
that could be considered accounting records. This overlaps with the
data sharing document the GMOC team is drafting as well.

>
>
> Second, should the privacy discussion be part of the security
> design? From
> the security perspective, what would be logged for accounting/audit
> and
> how the data/information may be provided for consumption and analysis
> seems to me an important aspect in the security design.

I agree. This is also an overlap with the GMOC document, and it is a
very important area.

I'd like to see Steve Schwab and Jon Paul Herron's high-level
responses to this group.

Thanks for taking the time to evaluate and discuss this Bon!

>
>
> Thanks again on the effort for the report and sharing.
>
> Bon
>
>
>
>
> On Mon, 2 Mar 2009, Heidi Picher Dempsey wrote:
>
>> Please take a look at the draft report on the GENI wiki:
>>
>>

http://groups.geni.net/geni/attachment/wiki/GENISecurity/GENI-SEC-ARCH-0
.3.doc

>> .
>>
>> The goal of this draft is to help guide and coordinate GENI
>> prototyping teams, as well as other projects or people interested in
>> joining or using GENI. A secondary goal of the document is to start
>> discussions about security topics that are unclear or controversial
>> as
>> currently approached in Spiral 1. The project team expects to revise
>> the document periodically, based on feedback from these discussions.
>> Please post comments to this list. We will be discussing this topic
>> at the OMIS working group meeting at GEC4.
>>
>>
>>
>> _______________________________________________
>> 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

_______________________________________________
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

Re: Draft Spiral 1 Security Design Report

2009-03-04T05:26:39Z

On Mar 3, 2009, at 12:01 PM, Bon sy wrote:

>
>
> Thanks again on the effort for the report and sharing.
>
> Bon
>
>
>
>
> On Mon, 2 Mar 2009, Heidi Picher Dempsey wrote:
>
>> Please take a look at the draft report on the GENI wiki:
>>
>> http://groups.geni.net/geni/attachment/wiki/GENISecurity/GENI-SEC-ARCH-0.3.doc
>> .
>>
>> The goal of this draft is to help guide and coordinate GENI
>> prototyping teams, as well as other projects or people interested in
>> joining or using GENI. A secondary goal of the document is to start
>> discussions about security topics that are unclear or controversial
>> as
>> currently approached in Spiral 1. The project team expects to revise
>> the document periodically, based on feedback from these discussions.
>> Please post comments to this list. We will be discussing this topic
>> at the OMIS working group meeting at GEC4.
>>
>>
>>
>> _______________________________________________
>> 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

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

Re: Draft Spiral 1 Security Design Report

2009-03-03T09:01:06Z

Hi
I just finished the first read of the report. Thanks for the
effort!

I have two high level questions:

First, I am curious why there is no discussion on the accounting aspect;
the third "A" in AAA (Authentication, Authorization, and Accounting). I
would think some level of discussion on accounting would be necessary if
we are to provide meaningful audit and forensic analysis as mentioned in
the report. I would also think that accounting information may be useful
for providing some guidance on how to approach isolation on experimentations.

Second, should the privacy discussion be part of the security design? From
the security perspective, what would be logged for accounting/audit and
how the data/information may be provided for consumption and analysis
seems to me an important aspect in the security design.

Thanks again on the effort for the report and sharing.

Bon

On Mon, 2 Mar 2009, Heidi Picher Dempsey wrote:

> Please take a look at the draft report on the GENI wiki:
>
> http://groups.geni.net/geni/attachment/wiki/GENISecurity/GENI-SEC-ARCH-0.3.doc
> .
>
> The goal of this draft is to help guide and coordinate GENI
> prototyping teams, as well as other projects or people interested in
> joining or using GENI. A secondary goal of the document is to start
> discussions about security topics that are unclear or controversial as
> currently approached in Spiral 1. The project team expects to revise
> the document periodically, based on feedback from these discussions.
> Please post comments to this list. We will be discussing this topic
> at the OMIS working group meeting at GEC4.
>
>
>
> _______________________________________________
> 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

Draft Spiral 1 Security Design Report

2009-03-02T15:51:19Z

Please take a look at the draft report on the GENI wiki:

http://groups.geni.net/geni/attachment/wiki/GENISecurity/GENI-SEC-ARCH-0.3.doc
.

The goal of this draft is to help guide and coordinate GENI
prototyping teams, as well as other projects or people interested in
joining or using GENI. A secondary goal of the document is to start
discussions about security topics that are unclear or controversial as
currently approached in Spiral 1. The project team expects to revise
the document periodically, based on feedback from these discussions.
Please post comments to this list. We will be discussing this topic
at the OMIS working group meeting at GEC4.

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

Upcoming GEC preparations

2009-02-24T23:47:53Z

GEC #4 is just over a month away. It's time to start getting ready.

The OMIS Working Group will be meeting for two hours and the WG agenda
is currently being developed. If you would like to report on anything
to the group, or wish to suggest a topic for discussion, let myself
and/or Heidi Dempsey (MAP@... and HPD@...) know. Anything
relevant to the Operation, Management, Integration or Security of GENI
will be welcome.

Since they were so well received last time, we are again planning to
reserve a block on the agenda for lightning talks. These are really
short informal talks for general information and/or to spark
interesting discussion. No formal presentation is required, but feel
free to start thinking of ideas. The actual talks will be determined
at the WG session.

-MAP
(GENI OMIS SE)

P.S. A special note for those of you that haven't made reservations
yet, the conference rate room block expires end of this week, so get
those reservations in...

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

Document posted: "Requirements for Wholesale Opt-In"

2009-02-24T13:10:47Z

The document "Requirements for Wholesale Opt-In" has been posted to:
http://groups.geni.net/geni/wiki/OptInReqs

This document outlines requirements for a strong wholesale opt-in mechanism
for GENI. When fully deployed it would permit GENI experimenters to request
that ISPs redirect traffic from a huge population of innocent users through
GENI infrastructure. These users are innocent in the sense that they do not
have to do anything at all to participate, and might not even be aware that
they are doing so. Key to wholesale opt-in is that it fully engages the
Institutional Review Board (IRB) process and that all participants are
motivated by their own self interests to do the right thing. It does not
require "selling" GENI to application developers or anybody other than network
researchers.

Since the ISPs bear a disproportionate share of the risk with this technique,
the ISPs are granted additional controls, implemented in an "ISP Daemon" that
serve to isolate the ISPs' critical core routers from GENI.

When this approach is fully mature we expect it to be sufficiently robust
where NSF might include GENI opt-in language in research solicitations across
the entire foundation. This could bring as much traffic to GENI as is
currently carried in aggregate by all of today's production research and
education backbones.

(Cross posted at the request of the GPO.)

Thanks,
--MM--
-------------------------------------------
Matt Mathis http://staff.psc.edu/mathis
Work:412.268.3319 Home/Cell:412.654.7529
-------------------------------------------

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

Audio from GEC3

2009-01-26T10:59:15Z

Audio files of the OMIS working group meeting at GEC3 are now
available from the GENI wiki.

http://groups.geni.net/geni/wiki/OMISAudio

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

Draft of GEC3 meeting notes

2008-12-09T20:02:20Z

I put up a page on the wiki with my notes from the GEC3 OMIS meeting.
It's at <http://groups.geni.net/geni/wiki/GeniOmisGEC3Notes>. These
are "draft" minutes, corrections or additions are welcome. Early next
week, I'll take the "draft" off the page, unless we're still
discussing something...

-MAP

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

Re: [substrate-wg] GENI IP space?

2008-12-01T14:01:47Z

I made a comment along these lines at the microphone at GEC3.

The general problem is that if GENI uses a slice of address space "borrowed"
from an ongoing production network, then GENI potentially exposes the owner of
the address space to churn caused by defective or erratic routing
announcements.

As I noted at the mic everyone attached to GENI will be happy as long as GENI
has some other IP address space, but nobody will want to share addresses with
GENI.

I suggest another option, that is solicit the wider community for unused
address space that is disjoint from current production announcements, or can
otherwise tolerate potential churn caused by GENI. NLR may have space too.

How much space does GENI need? We certainly have unused class C's from the
swamp that are available. They should be fine in the global R&E Internet, but
may be blocked by some commercial and International ISPs. We may also be able
to find some other larger blocks... How much space does GENI need and for how
long?

Thanks,
--MM--
-------------------------------------------
Matt Mathis http://staff.psc.edu/mathis
Work:412.268.3319 Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

On Mon, 1 Dec 2008, Aaron Falk wrote:

> Hi Joe-
>
> I agree this is a broad topic and am cc'ing the wg list.
>
> Can you expand more on why "Options (1) and (2) will not support
> independent routing policies"? I can see that the campus would need
> to cooperate on developing GENI-needed policies. Is that what you
> meant?
>
> We do plan to get some addresses from ARIN, although not for every
> GENI component. There is no timeline yet. Our assumption has been
> that, in general, if you were deploying something you would provide
> addresses for it (your 'option 1' below) and we would assist you to
> work with your IT dept on getting appropriate policies in place.
> Perhaps this is simple-minded, but if it won't work it I'd like to
> understand why.
>
> I think the goal of collecting parameters we need to register is a
> good one. Is there anything other than IP addresses and AS numbers?
>
> --aaron
>
> On Dec 1, 2008, at 3:42 PM, Joseph B. Evans wrote:
>
>> Aaron:
>> GpENI is going to need IP space for its control and management
>> plane, and perhaps for parts of the data path as well. I assume
>> projects in other clusters are going to come up against this as well.
>>
>> GpENI is looking into a few options, (1) using KU or KANREN space,
>> (2) using Internet2 space, (3) getting GpENI space from ARIN, or (4)
>> getting space through a coordinated request to ARIN from the GPO.
>> Note that eventually, we will also likely want to have at least one
>> AS number for GENI. Options (1) and (2) will not support
>> independent routing policies, and (3) is unlikely to be successful.
>>
>> So the question is, is the GPO pursuing IP space for the whole of
>> GENI, and if so, what is the timeline? If not, well, I'd recommend
>> that it should.
>>
>> There is some urgency to this, since renumbering will be
>> increasingly irritating as the systems grow.
>>
>> I've copied the Substrate WG co-chairs because I think this is a
>> general substrate issue.
>>
>> Cheers,
>> Joe
>>
>> ---
>> Joseph B. Evans, Ph.D. <evans@...>
>> Distinguished Professor, Electrical Engineering & Computer Science
>> Director, Information & Telecommunications Technology Center
>> University of Kansas
>>
>
>
> _______________________________________________
> substrate-wg mailing list
> substrate-wg@...
> http://lists.geni.net/mailman/listinfo/substrate-wg
>

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

Re: GENI IP space?

2008-12-01T13:07:17Z

Hi Joe-

I agree this is a broad topic and am cc'ing the wg list.

Can you expand more on why "Options (1) and (2) will not support
independent routing policies"? I can see that the campus would need
to cooperate on developing GENI-needed policies. Is that what you
meant?

We do plan to get some addresses from ARIN, although not for every
GENI component. There is no timeline yet. Our assumption has been
that, in general, if you were deploying something you would provide
addresses for it (your 'option 1' below) and we would assist you to
work with your IT dept on getting appropriate policies in place.
Perhaps this is simple-minded, but if it won't work it I'd like to
understand why.

I think the goal of collecting parameters we need to register is a
good one. Is there anything other than IP addresses and AS numbers?

--aaron

On Dec 1, 2008, at 3:42 PM, Joseph B. Evans wrote:

> Aaron:
> GpENI is going to need IP space for its control and management
> plane, and perhaps for parts of the data path as well. I assume
> projects in other clusters are going to come up against this as well.
>
> GpENI is looking into a few options, (1) using KU or KANREN space,
> (2) using Internet2 space, (3) getting GpENI space from ARIN, or (4)
> getting space through a coordinated request to ARIN from the GPO.
> Note that eventually, we will also likely want to have at least one
> AS number for GENI. Options (1) and (2) will not support
> independent routing policies, and (3) is unlikely to be successful.
>
> So the question is, is the GPO pursuing IP space for the whole of
> GENI, and if so, what is the timeline? If not, well, I'd recommend
> that it should.
>
> There is some urgency to this, since renumbering will be
> increasingly irritating as the systems grow.
>
> I've copied the Substrate WG co-chairs because I think this is a
> general substrate issue.
>
> Cheers,
> Joe
>
> ---
> Joseph B. Evans, Ph.D. <evans@...>
> Distinguished Professor, Electrical Engineering & Computer Science
> Director, Information & Telecommunications Technology Center
> University of Kansas
>

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

OMIS wg agenda

2008-10-29T13:18:19Z

Our meeting starts at 10:00 AM EDT on 10/30 in the Spyglass
auditorium, which is a bit of a walk from the main auditorium at HP.
Please make sure to be at the main auditorium by 9:45 in order to walk
with our HP escort to the Spyglass Auditorium.

I'd like this to be an interactive meeting, so the times below are
only approximate, and assume an active discussion following each talk
(or better yet interrupting each talk repeatedly).

10:00-10:30
GENI Meta Operations Center - Jon-Paul Herron, Indiana University
10:30-11:00
GENI Security Architecture - Stephen Schwab, SPARTA, Inc.
11:00-11:15
GENI at Four-Year Colleges - Pierre Tiako, Langston University
11:15-11:30
GENI 2008 Operations Security Internship summary and call for
participation - Ketly Jean-Pierre, Howard University
11:30-12:00
Spiral 1 Integration Plans and OMIS working group deliverables- Mike
Patton and Heidi Picher Dempsey, GPO
12:00-12:30
Discussion and Lightning talks.

Please put your presentations or any materials or URLs you'd like to
share on the wiki before the meeting:

http://groups.geni.net/geni/wiki/presentations

Mike and I will link the GEC3 presentations to the OMIS working group
pages on the wiki and publish notes there after the meeting.

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

GEC3 working group topics

2008-10-20T07:39:37Z

I've been putting together a tentative agenda for the upcoming GEC3
OMIS working group meeting that will happen from 9:00am-12:30pm PDT on
10/30. (Information on the GEC3 meeting, including the agenda, is
available at http://www.geni.net/GEC3/GEC3.html.) The agenda is open
to all, so if a topic you want to discuss is missing, please let me
know and we'll address it.

We have three talks from Spiral 1 project teams scheduled, as well as
discussions of Spiral 1 integration and security plans. I would very
much like meeting participants to give 5 or 10 minute "lightning
talks" on their areas of interest that are relevant to OMIS. These
talks are informal, and you do not have to prepare slides or other
materials for them unless you want to. (Overhead projectors will be
available). We plan to record the OMIS meeting, so your talk will
also reach people who are interested in GENI but can't attend in
person. If you are interested in giving a lightning talk, please let
me know so that I can reserve the right amount of time for them in the
agenda.

Current OMIS working group discussion topics (not ordered)

1) GENI Meta Operations Center - Jon-Paul Herron, Indiana University
2) GENI Security Architecture - Stephen Schwab, SPARTA, Inc
3) GENI at Four-Year Colleges - Pierre Tiako, Langston University
4) Spiral 1 Integration Plans - Mike Patton and Heidi Picher Dempsey,
GPO
5) OMIS working group deliverables (recent changes)
6) GENI 2008 Operations Security Internship summary and call for
participation - Ketly Jean-Pierre, Howard University
7) Lightning talks.

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

Re: small changes to OMIS working group page

2008-10-01T07:10:52Z

I think it might be a good idea to add the following parts:

1. how OMIS interact with components of GENI? This might help us determine the APIs.

2. define what kind of information should be interested to OMIS? and how to generate/collect this information?

Thanks
-Weisong

On Wed, Oct 1, 2008 at 9:30 AM, Heidi Picher Dempsey <hdempsey@...> wrote:

I made some small changes to OMIS deliverable wording on the geni.net
working group page to reflect changes in GENI over the past year. I'd
appreciate it if other members of the working group would take a look
at the deliverables and send email to the list if you think there are
things we should add, delete, or change. If there's interest, we can
put this discussion on the agenda for the GEC3 OMIS working group
meeting. Thanks.

http://geni.net/wg/omis-wg.html

_______________________________________________
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

small changes to OMIS working group page

2008-10-01T06:30:56Z

I made some small changes to OMIS deliverable wording on the geni.net
working group page to reflect changes in GENI over the past year. I'd
appreciate it if other members of the working group would take a look
at the deliverables and send email to the list if you think there are
things we should add, delete, or change. If there's interest, we can
put this discussion on the agenda for the GEC3 OMIS working group
meeting. Thanks.

http://geni.net/wg/omis-wg.html

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

it's time to register for GEC3

2008-09-03T13:26:21Z

Folks-

If you are planning to attend, please register for the GEC3 meeting
ASAP.

Registration site: http://www.edjassociates.com/geni3

Agenda: http://www.geni.net/GEC3/agenda.html

Thanks,

--aaron

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

Re: [cwg] Fwd: Indiana University comments on OMIS use Cases

2008-06-03T10:06:44Z

On Wed, May 21, 2008 at 01:32:17PM -0400, Larry Peterson wrote:
> Robert is right. For symmetry's sake, we might drop the word
> ticket and replace it with "resource credential" (the counterpart
> being a "slice credential" issued by a slice authority).

Are tickets credentials? They don't prove what a resource is or confer
rights to operate on them (other than to allocate them). I think it
would be more clear to call them "resource promises."

I think slice credentials are credentials, in as much as I understand
them.

--
Ted Faber
http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

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

attachment0 (202 bytes) Download Attachment

Fwd: [cwg] Fwd: Indiana University comments on OMIS use Cases

2008-05-21T10:47:56Z

<forwarded because Robert isn't a member of omis-wg>

Begin forwarded message:

> From: Robert P Ricci <ricci@...>
> Date: May 21, 2008 1:01:33 PM EDT
> To: Heidi Picher Dempsey <hdempsey@...>
> Cc: control-wg@..., omis-wg@...
> Subject: Re: [cwg] Fwd: [omis-wg] Indiana University comments on
> OMIS use Cases
>
> Thus spake Heidi Picher Dempsey on Wed, May 21, 2008 at 09:57:12AM
> -0400:
>> Below are some comments on the OMIS use cases that we posted on the
>> wiki a while ago. What do folks on this list think about using the
>> term "token" instead of "ticket" for control descriptions to avoid
>> future confusion between the overlapping term "ticket" that ops and
>> control both currently use?
>
> The word "token" is already used in the architecture documents to
> refer
> to a system built on top of tickets by brokers, which might permit
> over-booking or other economic models more complex than the simple
> semantics of a ticket. So, that name isn't an option.
>
> It seems like a few of the groups that are implementing prototypes are
> finding it convenient to treat a ticket as a particular type of
> credential. So, it's probably worth considering whether "resource
> credential" or something similar would work as an alternate name.
>
> --
> /-----------------------------------------------------------
> | Robert P Ricci <ricci@...> | <ricci@...>
> | Research Associate, University of Utah Flux Group
> | www.flux.utah.edu | www.emulab.net
> \-----------------------------------------------------------

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

Fwd: Indiana University comments on OMIS use Cases

2008-05-21T06:57:12Z

Below are some comments on the OMIS use cases that we posted on the wiki a while ago. What do folks on this list think about using the term "token" instead of "ticket" for control descriptions to avoid future confusion between the overlapping term "ticket" that ops and control both currently use?

Begin forwarded message:

From: "Williams, James G" <william@...>
Date: May 21, 2008 9:28:10 AM EDT
To: "'omis-wg@...'" <omis-wg@...>
Subject: [omis-wg] Indiana University comments on OMIS use Cases

Posted on the OMIS-wiki…..

Comments on OMIS Use Cases (and other OMIS issues)

Michael raised several issues in his latest message about OMIS Use Cases. We would like to add a bit to that discussion in two areas, ticket terminology and notifications and operational data sharing.

Ticket Terminology

Michael raised a question of terminology confusion between “trouble tickets” and “resource tickets” if both are called “tickets”. We have a suggestion here. It seems to us that one way to eliminate this confusion is to talk about tickets and tokens. A component issues a token (or resource token [RT]) that can be redeemed for services. These tokens are directed toward a Clearinghouse (and perhaps later used in a conversation between the Clearinghouse and an experiment). A trouble ticket (TT) would be created by a NOC (Aggregate Ops or GENI Ops), and would describe a problem (current issue) or an event (future issue). A TT would (could) be shared with a Clearinghouse and experimenters. But, tokens and tickets would be issued by different entities (components and Ops).

Notifications and operational data sharing

The very pervasive issue of “notifications” and operational data sharing seems to be a crucial area that deserves detailed discussion. An open question posed by Michael in all Use Cases relates to how interrelated experiments would notify each other about service issues. The issue of notifications seems one of basic importance to operations, and one which cuts across all of the use cases mentioned. As Michael states, notification is a difficult and problematic area. Should notifications come from a myriad of NOCs, or be channeled through some kind of normalizing system to coordinate and standardize the notifications? Who does Ops (GENI or Aggregate) notify about outages (emergency or scheduled)? How does an experiment, end user, or aggregate signal its desire to receive notices? How do notification recipients signal what type of notifications they want to receive, and how they want to receive them? How does an experiment or an aggregate signal its intention to send out notices reflecting its internal state? These issues are already complex even for networks that are simpler and less federated, such as the NLR and Internet2 networks. We’ve already begun to see keen interest in developing a rich mix of push/pull notifications of customized granularity and audience. Some in the community want to see only a very small set of notifications for very specific things. Others want to see everything they can. Some want a simple system to “poll” for network status information. Others want notifications to be pushed out very aggressively through a number of channels. Given the diversity of audience for GENI-related notifications, this will only be more complicated (and important) for GENI.

Here are some initial ideas based on our experience.

Any notification feature must be automated as much as possible. This will have implications for (among other things) the data structure that describes experiments, aggregates and clearinghouses. This seems obvious. But, this network will be way too complex for much “operator intervention” at the notification level.
For notification information to be exchanged there must be some process for information providers (the ones producing notifications) and information consumers (the ones wanting to see notifications) to opt-in, and authorize the exchange of information. This process must be strict enough to protect against information flooding or leaking, but must also be simple enough so it doesn’t become a roadblock to research information sharing and so it doesn’t inadvertently slow down operational troubleshooting and maintenance.
Standards for notification formats could be very helpful. If notifications can be sent in a standardized format, the Aggregate owners and Experimenters can use the notifications programmatically. This could be to update the aggregates trouble ticketing system or to change the configuration/ suspend an experiment.

_______________________________________________
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

Re: Indiana University comments on OMIS use Cases

2008-05-21T06:40:01Z

Very useful comments. I'm going to cross-post to the control group to
see what they think about tokens, which would certainly be better
naming from our point of view.

On May 21, 2008, at 9:28 AM, Williams, James G wrote:

> Posted on the OMIS-wiki…..
>
>
>
>
>
> Comments on OMIS Use Cases (and other OMIS issues)
>
> Michael raised several issues in his latest message about OMIS Use
> Cases. We would like to add a bit to that discussion in two areas,
> ticket terminology and notifications and operational data sharing.
>
>
>
>
> Ticket Terminology
>
> Michael raised a question of terminology confusion between “trouble
> tickets” and “resource tickets” if both are called “tickets”. We
> have a suggestion here. It seems to us that one way to eliminate
> this confusion is to talk about tickets and tokens. A component
> issues a token (or resource token [RT]) that can be redeemed for
> services. These tokens are directed toward a Clearinghouse (and
> perhaps later used in a conversation between the Clearinghouse and
> an experiment). A trouble ticket (TT) would be created by a NOC
> (Aggregate Ops or GENI Ops), and would describe a problem (current
> issue) or an event (future issue). A TT would (could) be shared
> with a Clearinghouse and experimenters. But, tokens and tickets
> would be issued by different entities (components and Ops).
>
>
> Notifications and operational data sharing
>
> The very pervasive issue of “notifications” and operational data
> sharing seems to be a crucial area that deserves detailed
> discussion. An open question posed by Michael in all Use Cases
> relates to how interrelated experiments would notify each other
> about service issues. The issue of notifications seems one of basic
> importance to operations, and one which cuts across all of the use
> cases mentioned. As Michael states, notification is a difficult and
> problematic area. Should notifications come from a myriad of NOCs,
> or be channeled through some kind of normalizing system to
> coordinate and standardize the notifications? Who does Ops (GENI or
> Aggregate) notify about outages (emergency or scheduled)? How does
> an experiment, end user, or aggregate signal its desire to receive
> notices? How do notification recipients signal what type of
> notifications they want to receive, and how they want to receive
> them? How does an experiment or an aggregate signal its intention
> to send out notices reflecting its internal state? These issues are
> already complex even for networks that are simpler and less
> federated, such as the NLR and Internet2 networks. We’ve already
> begun to see keen interest in developing a rich mix of push/pull
> notifications of customized granularity and audience. Some in the
> community want to see only a very small set of notifications for
> very specific things. Others want to see everything they can. Some
> want a simple system to “poll” for network status information.
> Others want notifications to be pushed out very aggressively through
> a number of channels. Given the diversity of audience for GENI-
> related notifications, this will only be more complicated (and
> important) for GENI.
>
> Here are some initial ideas based on our experience.
>
> • Any notification feature must be automated as much as possible.
> This will have implications for (among other things) the data
> structure that describes experiments, aggregates and
> clearinghouses. This seems obvious. But, this network will be way
> too complex for much “operator intervention” at the notification
> level.
> • For notification information to be exchanged there must be some
> process for information providers (the ones producing notifications)
> and information consumers (the ones wanting to see notifications) to
> opt-in, and authorize the exchange of information. This process
> must be strict enough to protect against information flooding or
> leaking, but must also be simple enough so it doesn’t become a
> roadblock to research information sharing and so it doesn’t
> inadvertently slow down operational troubleshooting and maintenance.
> • Standards for notification formats could be very helpful. If
> notifications can be sent in a standardized format, the Aggregate
> owners and Experimenters can use the notifications programmatically.
> This could be to update the aggregates trouble ticketing system or
> to change the configuration/ suspend an experiment.
>
>
> _______________________________________________
> 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

Indiana University comments on OMIS use Cases

2008-05-21T06:28:10Z

Posted on the OMIS-wiki…..

Comments on OMIS Use Cases (and other OMIS issues)

Michael raised several issues in his latest message about OMIS Use Cases. We would like to add a bit to that discussion in two areas, ticket terminology and notifications and operational data sharing.

Ticket Terminology

Michael raised a question of terminology confusion between “trouble tickets” and “resource tickets” if both are called “tickets”. We have a suggestion here. It seems to us that one way to eliminate this confusion is to talk about tickets and tokens. A component issues a token (or resource token [RT]) that can be redeemed for services. These tokens are directed toward a Clearinghouse (and perhaps later used in a conversation between the Clearinghouse and an experiment). A trouble ticket (TT) would be created by a NOC (Aggregate Ops or GENI Ops), and would describe a problem (current issue) or an event (future issue). A TT would (could) be shared with a Clearinghouse and experimenters. But, tokens and tickets would be issued by different entities (components and Ops).

Notifications and operational data sharing

The very pervasive issue of “notifications” and operational data sharing seems to be a crucial area that deserves detailed discussion. An open question posed by Michael in all Use Cases relates to how interrelated experiments would notify each other about service issues. The issue of notifications seems one of basic importance to operations, and one which cuts across all of the use cases mentioned. As Michael states, notification is a difficult and problematic area. Should notifications come from a myriad of NOCs, or be channeled through some kind of normalizing system to coordinate and standardize the notifications? Who does Ops (GENI or Aggregate) notify about outages (emergency or scheduled)? How does an experiment, end user, or aggregate signal its desire to receive notices? How do notification recipients signal what type of notifications they want to receive, and how they want to receive them? How does an experiment or an aggregate signal its intention to send out notices reflecting its internal state? These issues are already complex even for networks that are simpler and less federated, such as the NLR and Internet2 networks. We’ve already begun to see keen interest in developing a rich mix of push/pull notifications of customized granularity and audience. Some in the community want to see only a very small set of notifications for very specific things. Others want to see everything they can. Some want a simple system to “poll” for network status information. Others want notifications to be pushed out very aggressively through a number of channels. Given the diversity of audience for GENI-related notifications, this will only be more complicated (and important) for GENI.

Here are some initial ideas based on our experience.

Any notification feature must be automated as much as possible. This will have implications for (among other things) the data structure that describes experiments, aggregates and clearinghouses. This seems obvious. But, this network will be way too complex for much “operator intervention” at the notification level.
For notification information to be exchanged there must be some process for information providers (the ones producing notifications) and information consumers (the ones wanting to see notifications) to opt-in, and authorize the exchange of information. This process must be strict enough to protect against information flooding or leaking, but must also be simple enough so it doesn’t become a roadblock to research information sharing and so it doesn’t inadvertently slow down operational troubleshooting and maintenance.
Standards for notification formats could be very helpful. If notifications can be sent in a standardized format, the Aggregate owners and Experimenters can use the notifications programmatically. This could be to update the aggregates trouble ticketing system or to change the configuration/ suspend an experiment.

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

OMIS Use Cases

2008-04-25T12:04:48Z

I've written up four OMIS Use Cases in the spirit of the presentation
Aaron did in Arlington. Get to them from the OMIS-WG page on the
wiki, or at <http://groups.geni.net/geni/wiki/GeniOmisUseIntro>.

Everyone should take a look at them and send comments. We could
especially use feedback from people with experience in other
experimental networks on what is really practical and any important
factors that have been left out. Also suggestions on other scenarios
that would be especially useful to work out are welcome (or feel free
to write them up yourself and put them on the wiki).

-MAP

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

Re: [cwg] Problems with the GID

2008-04-25T02:06:48Z

Robert P Ricci wrote:

> These are some notes about the GID (aka the GGID) as it's currently
> defined in the architecture documents (eg. GDD-07-44). As we've tried to
> implement a prototype of a GID as part of Utah's ProtoGENI project, we
> run into some things that we think make the GID, as currently specified,
> unworkable. My goal in sending this mail is to get a discussion of these
> issues started, possibly ending up with a revised definition of the GID,
> or at the very least, a clarification of the existing definition.
>
> Much of the content of the discussions at Utah that have lead us to
> these conclusions are available here:
>
> http://www.protogeni.net/trac/protogeni/wiki/GID
>
> The design documents currently state that a GID is a certificate binding
> a UUID to a public key - thus, the identities of users, slices,
> component managers, etc. are certificates.
>
> The main advantage of this is that it makes identity self-certifying:
> giving another party a GID is, by itself, enough (along with some
> standard cryptographic challenge) to "prove" that the entity supplying
> the GID holds the private key that matches the certificate, and thus
> "is" the entity the GID belongs to.
>
> There are a number of problems with using a certificate as an identity,
> however. An example of this is that the certificate includes an
> expiration date,

I agree that the notAfter field in x.509 was a mistake, however
its easily handled. The successor [1] to RFC3280 will say: "To indicate
that a certificate has no well-defined expiration date, the notAfter
SHOULD be assigned the GeneralizedTime value of 99991231235959Z."
I'm personally happy to revisit this decision at the relevant time:-)

[1] http://tools.ietf.org/html/draft-ietf-pkix-rfc3280bis-11

More generally, I don't believe GENI should get into the business
of tweaking PKI, which is what can easily happen here, and secondly
I would also pose the following requirement:

"It should be possible to securely tie a GID to any of the following:
- an x.509 certificate
- a Kerberos identity
- a SAML assertion
- an openid
or whatever equivalents see wide deployment as GENI is rolled out."

If people accept that, then that suggests the discussion ought not
be about mechanism specifics (e.g. key loss) but more a
security-mechanism independent discussion of the life-cycle of the
GID.

Stephen.

> and if we were to renew a certificate by creating one

> with a later expiration date, this would constitute the creation of a
> new identity, unrelated at an architectural level to the previous one.
> It also ties identity strongly to the authority that has signed the
> certificate - ie. if my institution signed my GID, and I change
> institutions, I have to get a new identity (or my old institution must
> continue vouching for my identity.) Finally, if an entity needs to
> change its public key for any reason - ie. a real or suspected
> compromise of its private key, this also requires a new identity. When
> entities are users, and they store keys, etc. on desktops and laptops,
> this is not an uncommon operation. Because many objects and rights in
> GENI will be tied to GIDs (eg. rights to create and control slices, the
> slices themselves, tickets, etc.), having to change a GID is a pretty
> big deal.
>
> The design documents don't make the purpose of the UUID in this clear,
> but it seems that it was intended to be the "real" identifier - ie. in
> any of the above situations, I would obtain a new certificate, possibly
> from a different authority, and possibly with a different public key,
> but with the same UUID. If this is the case, I'd argue that the GID is
> misleadingly misnamed - it's not an identifier at all, it's simply a
> certificate used for *authenticating* an identity. Thus, in the rest of
> the documents, when we refer to, say, issuing a ticket to a specific
> slice, the identifier to which that ticket is bound should be the
> slice's UUID, not a particular certificate. Similarly, when delegating
> rights to control (eg. stop) a slice, the delegate and slice should be
> specified as UUIDs. This makes the identity itself relatively permanent,
> while attestations as to that entity's public key (certificates) may
> change, be revoked, etc.
>
> Using a UUID as identifier rather than a certificate solves the problems
> listed above, but loses the property of self-certification. To a first
> approximation, this seems okay: when an entity wants to talk to another
> entity via the GENI API, it supplies both its UUID and a certificate
> binding this to a public key. This looks very much like it did before,
> with the distinction that it's the UUID and not the certificate that is
> the identifier. At different times, an entity with the same UUID might
> use a different certificate to authenticate itself, but with the
> understanding that it is still the "same" entity. (We'll need a
> certificate revocation mechanism, but we would need that anyway.)
>
> It also loses another property, though, that might be a bigger problem:
> the binding between UUID and public key is no longer unforgeable. With
> certificate-as-identifier, one cannot impersonate another entity short
> of stealing their private key (or tricking them into using it, etc.) If
> one were to try to make a new certificate with a different public key in
> it, it would be considered a new identity, and thus not succeed as an
> impersonation attempt. If the identifier, however, is simply a UUID,
> there is nothing to stop an authority unrelated to the entity from
> issuing a certificate binding its UUID to another public key. Thus, a
> researcher from institution A with UUID X and public key K may be
> impersonated by institution B: it simply needs to sign a certificate
> binding UUID X to public key J.
>
> Essentially, a flat UUID does not "belong" to any issuing authority, and
> thus any authority can bind it to a public key. This means that once one
> trusts an authority (which may be a root, such as GENI itself, or may
> derive authority from the root, such as an institution that has has been
> authorized by GENI to create users) to bind UUIDs to public keys, that
> authority has the ability to bind a public key to *any* UUID, a power
> that it can use for good (to help the entity authenticate) or evil (to
> impersonate the entity "improperly"). It looks to me like the GENI
> architecture expects there to be a relatively large number of
> authorities trusted to create GIDs (probably deriving their authority
> from a fairly small number of roots). So it doesn't seem like this is a
> power we should be willing to give all of them.
>
> One way to fix this is to somehow "partition" the UUID space, so that
> some of the bits are used to identify the issuing authority, in a way
> that is verifiable. This limits the scope of each authority to UUIDs
> that it has issued, and allows more flexible policy with respect to
> trusting authorities (ie. I might trust the global GENI authority to
> assign public keys to any user at all, but I might only trust Utah to
> bind public keys to UUIDs within its own space). It does, however, tie
> an identity to the authority that originally issued it, so one cannot
> "move" and identity from one authority to another, so it's missing one
> of the desirable properties. So, I'd be interested in hearing
> alternatives that would preserve this property.
>

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

Re: What, exactly, has actually failed...

2008-03-05T06:29:24Z

I was motivated by the WG discussion on "GENI is not a network"
to read through the OMIS archives and happened upon this
related post from Mike Patton. So herewith some thoughts.

So, while I have to agree that GENI is not a network in the
same sense as a current day ISP, the fact that it has distributed,
interconnected and shared resources, does mean that GENI
would operationally have many of the same concerns that current
networks have. (I.e., a slice is only useful to the extent that
the underlying substrate components are operational and
connected.)

As a simple example, suppose an optical (or other transport)
path between two GENI nodes, further suppose no currently
running GENI experiments using this path and finally assume
a fiber cut somewhere between these two nodes. So the question
is whether operationally GENI would/should be aware of this
fiber cut (even in the absense of any experiments using the
path in question)? I think it should. And I think that illustrates
the need for an operational "in-band substrate view", i.e.,
being operationally aware of the state of the substrate independent
of any experiments. (And to some extent this is a network view,
albeit not a conventional IP network view.)

I think of the operational view via the component manager (CM), as
Mike described it, as an "out-of-band substrate view". I.e., monitoring
the path to the CM only tells you about the availablity of
an out-of-band view, but does not tell you anything about the
health of the substrate itself. Although, this would be the
way to obtain information about the in-band substrate view.

The third operational view needed (i think), is a "slice view",
which would tell us something about the health of a slice.
Here I would agree with the sentiments expressed at the WG
that this view could be a noop (in the case of experiments
that either don't care about that, or want to role-their-own),
or could be something of an outsourced operational service/function
provided by GENI for long lived experiments that do not want to
do it themselves.

Kobus

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

Fwd: [services-wg] WG overlap: services and control

2008-02-29T13:18:24Z

I'm sure OMIS members are interested in this as well.

Begin forwarded message:

> From: Jeff Chase <chase@...>
> Date: February 29, 2008 4:08:22 PM EST
> To: control-wg@..., services <services-wg@...>
> Subject: [services-wg] WG overlap: services and control
>
> Since one of the goals for the upcoming meeting is to work on cross-WG
> issues, I have posted some notes on the Services wiki about our
> tendrils
> to the control WG.
>
> http://groups.geni.net/geni/wiki/GeniServices/Tendrils/Fcf.html
>
> This interaction in particular raises some basic issues about what
> powers the "facility" actually has with respect to its components, and
> how the services reflect those powers. These issues generated a good
> discussion at the meeting at BBN a couple of weeks ago, and we'll need
> to make sure we are all on the same page before we go forward. We
> are
> interested in hearing perspectives from others in both working groups.
>
> Jeff
>
>
> _______________________________________________
> services-wg mailing list
> services-wg@...
> http://lists.geni.net/mailman/listinfo/services-wg

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

WG overlap: GIMS

2008-02-28T22:53:29Z

One of the things I've been looking at for the OMIS WG is where we
overlap with other WGs. One particular area that's got both lots of
overlap and is critical and important to GENI is the instrumentation
(GIMS) for experiments. It seems like these three WGs, at least, all
have a considerable stake in it. But where the lines are drawn is not
at all clear.

Since one of the goals of the upcoming conference is to work on
cross-WG issues (since all WG sessions are in full plenary and
therefore open to all other WGs), I thought it might be fruitful to
see if we could spur some discussion on how to attack the design and
specification for GIMS.

----------------

I think that getting GIMS right is a hard (and therefore interesting)
problem. There are lots of issues, and I think some of them cross the
normal boundaries between the WGs. This leads me to think that first
we may need to decide on the meta-question of how to handle it.

One possible way to get a more consistent overall design would be to
have a sub-group (that would, in essence be a sub-grioup of each of
the WGs) to work on GIMS. This sub-group would need to have people
from all three WGs and would interact back to each of the full WGs as
needed both for input and review.

Another idea (really just a less organized version of the above, I
suspect) is to have a wiki page common to the 3 WGs (and any others
that think they have a stake) to collect the issues and work out how
the subdivision of the problem will be defined.

If you have any comments on those approaches, or want to suggest some
other alternatives, please do.

----------------

There are a lot of issues that need to be worked out, here are just
some that occur to me...these are short summaries, I could probably
write a lot more on each of them.

I think one of the big issues with GIMS is that with the 20 plus year
expected lifetime, data collection, archiving, and analysis techniques
will evolve considerably and an architecture is needed that can evolve
as well and keep all the required old data available.

Another big one is privacy, anonymity, and other concerns in the
tradeoff between disclosure and secrecy. This is especially tough as
public perception and even legislation can affect what protections are
needed, and these change over time. So, again there is a need for a
design that can adjust to changing circumstances. And, what about
combining data collected under two different sets of privacy
assumptions?

Another issue is avoiding duplication between data collected for
operating the network and for instrumentation of experiments. There
are several kinds of data that need to be collected for both purposes.
How do we integrate these systems in a way that avoids having to
collect the same information multiple times?

OK, that's a short sample of issues. Feel free to contribute your
own...

----------------

In summary, I think GIMS is going to be an important part of GENI and
getting its design going soon seems desireable. So, please contribute
your own input on this.

-MAP

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

Working Group overlap/interface

2008-02-27T22:40:37Z

I have started a wiki page to collect places where the OMIS-WG may
overlap and/or interface to other WGs. I've just put down the things
that immediately occurred to me. Everyone should take a look (the
direct URL is <http://groups.geni.net/geni/wiki/OmisOverlap>) and
think about any other areas of overlap. Feel free to add any you
think of to the page or bring them up on the mailing list.

-MAP

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

Use Case: Emergency Shutdown

2008-02-27T18:36:52Z

The one place where the slides show Operations involved is in
emergency shutdown. But there isn't much there, OMIS should flesh
that out. I'd think we (OMIS) should make a more-than-one-slide
version of the Mini Use Case to explore it.

A number of questions arise. What policies does the NOC use to decide
to shutdown? What do they need to look at to get the evidence that
it's really a specific slice that's at fault? What else needs to be
considered? Does the NOC have any less drastic recourse?

What about handling other emergencies? What if a compute cluster gets
turned into a botnet and unallocated slivers actually start to
misbehave? If they aren't part of a slice there's no slice to
"emergency shutdown". If the compute cluster is just cut off, you
penalize experiments that aren't misbehaving but just happen to have
slice resources there.

-MAP

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

Use Case: Registry operations

2008-02-27T18:22:41Z

Another OMIS related question raised by the Use Case slides is
registries. There are a number of registries mentioned in the Use
Case (and many --- with some overlap --- in the design documents).
The Operation and Security of these registries needs to be planned
out. We probably need to enumerate the registries and for each one
decide if there's any practical way to have the administration
decentralized. That could be heirarchical delegation or other
structure.

Some of the registries seem to need to be a single central resource.
That seems like a bad design choice, so some rethinking (and perhaps
some risk-reduction prototypes) seems in order for these registries.
I think some of this is just oversimplification in the "cartoon" style
presentation of the Use Case slides, but OMIS seems like the right
place to thrash out this operationsl question and especially to try
and track down the potential bottlenecks.

-MAP

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

Use Case: Operational outages

2008-02-27T15:49:08Z

Another point that I came up with is how GENI deals with both planned
and unplanned outages wrt the experiments they affect.

In the case of an unplanned outage, say a particular slice is using a
particular fiber which suffers a "backhoe fade" event or some other
outage does the researcher want:
- to just get notified?
- to use it as a test for the failure resilience of their design?
- to have some automatic reroute happen?
- or is there something else?

Which of these options can/should be offered? Is there a clear
default, or should this be something the researcher has to think about
on a experiment by experiment basis?

For planned outages, there can be even more options. Say the owner of
some compute cluster needs to take it down for maintenance, or
whatever reason. If they post a notification of that, the researcher
could just let it happen and treat it like an unplanned outage, or
they could plan ahead and migrate services to other components outside
the group that will be down. Of course, if their experiment is about
automatic migration and failover, they might welcome a planned outage
as they could make it a point of being there to observe the failover
in real time.

As I was writing this message, another closely related question
occurred to me. I haven't thought about this much, but I wonder about
techniques to inject failures into experiments (having a sliver or two
fail, without actually taking out the whole component). That's
certainly something that GENI should offer the researchers, but I
haven't seen any discussion of how that would be done.

-MAP

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

Use Case: Who operates the slice?

2008-02-27T15:30:24Z

The slides make the assumption that the researcher is providing
operations (within the experiment). It was discussed at the OMIS
meeting in Minneapolis (or maybe in a small group afterward) that
researchers with an experiment that is long running may want to
"out-source" operations for whatever service it provides. This might
be especially true if they have Opt-In users to support. Most
researchers _will_ want to do their own operations until they suffer
from too much success and it becomes a burden. So, it's a good
assumption, for small experiments and inital stages of most, but
possibly not always. OMIS should explore how outsourcing operations
would work.

An interesting thing to me was someone's suggestion to look at that as
an extension of the existing "slicing", your experiment gets a
"virtual NOC" that is just a sliver of the NOC (potentially much less
than one FTE worth) assigned to your slice. This leads to either (or
both) the possibility of the GENI NOC subcontracting (in some sense,
possibly just by fiat of NSF) and/or having an "aggregate" that is
(sliceable) NOC services independent of the "GENI NOC" which you get
authorized and allocated in a manner similar to any other aggregate.
Like Measurement it's not inside the experiment, but an external
support service. It's a little wierder because it's partially people
and not just electronics (or photonics) that you are allocating, but
dealing with that is up to the CM of the aggregate that represents
it... But, setting up monitoring systems for operations is almost
exactly like setting up an experiment measurement, so it's not _that_
different.

So, does anyone else have suggestions for (or specific experience
with) providing researchers with resources for ongoing operation of
their experiments? Is this really a common resource that GENI should
be providing, or will researchers want to go it alone or get service
some other way?

-MAP

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