Each poll has the same use-cases to develop plus the extras. There are three periods for small group meetings and thus 3 doodle polls. Each doodle poll represents a different time period. During each period, there will be many small groups - probably around 15-20, depending on how people sign up.
Alia On Apr 21, 2013 6:59 AM, "Jamal Hadi Salim" <[email protected]> wrote: > Hi Alia, > The doodle is a little confusing. All 3 have exactly the same columns. > Isnt each group supposed to have different layout? > I take it one cant attend all 3 since they run in parallel. > > cheers, > jamal > > > On Tue, Apr 16, 2013 at 8:49 PM, Alia Atlas <[email protected]> wrote: > >> First, I'd like to remind everyone that the deadline to register for the >> interim on April 22 & 23 is tomorrow, April 17. The registration link is: >> http://i2rs-interim.eventbrite.com/ >> >> Second, I've only seen one request for discussing a draft. This is the >> perfect and good time to present specific details of use-cases before they >> go into small groups for discussion. PLEASE do request time - to help be >> sure people are on the same page. >> >> Third, a large portion of the meeting is having focused small group >> meetings that will then report back to the whole meeting. The expectation >> is that all attendees - remote as well as local - will participate in this. >> We want your ideas! There will be Google Hangouts to facilitate the small >> group meetings involving remote participants. >> >> There are three polls to indicate which small groups each person is >> interested in. Please sign up. >> Each small group will have no more than 8 people in it - but we can have >> duplicate groups that will coordinate. >> There are about 20 topics for each meeting - it is likely that some will >> be consolidated. Please feel free to brainstorm/discuss what other >> use-cases should be included. I have generally pulled these from existing >> individual drafts (as indicated). >> >> Poll for Group Meeting 1: >> http://www.doodle.com/um37p9gds9u72mfd >> >> Poll for Group Meeting 2: >> http://doodle.com/uy9sfsc3kdsmcdut >> >> Poll for Group Meeting 3: >> http://doodle.com/2y85tbwig6hnma46 >> >> The general structure for the use-case discussions is intended to be: >> *** >> >> - >> >> First group session: >> - >> >> Taxonomy of network applications (to be used in later sessions) >> - >> >> Use-cases: clear write-up of idea, how it’s done today, >> pros/cons of doing with i2rs >> - >> >> Second group session: >> - >> >> Use-cases: flesh each out to include information to be read as >> well as written and events - so get full feedback loop. Identify >> assumptions about network application associated >> - >> >> Communications options taxonomy >> - >> >> Authentication & authorization taxonomy >> - >> >> Third group session: >> - >> >> Use-cases: connect each use-case to the functional requirements >> in the i2rs architecture. What set of features is needed? What >> about for >> communications? For authentication and authorization? Next steps & >> write-ups... >> - >> >> RIB info model >> - Topology info model >> >> * >> >> More details on the proposed use-cases are below: >> >> * >> >> 1. >> >> Use-Case Definitions: >> 1. >> >> RIB-based use-cases: >> 1. >> >> service chaining: Directing traffic into MPLS out-segments, >> LSPs, or MPLS tunnels (pick right level of abstraction). Directing >> traffic >> into other types of tunnels. >> 2. >> >> optimized exit scenario: draft-white-i2rs-use-case-00.txt Sec 2 >> 3. >> >> Distributed reaction to Network-based Attacks: >> draft-white-i2rs-use-case-00 Sec 3 >> 4. >> >> Improving hub-and-spoke overlay routing: >> draft-white-i2rs-use-case-00 Sec 4 >> 5. >> >> Optimized exit control: draft-white-i2rs-use-case-00 Sec 1 >> 6. >> >> Brainstorm/discuss other use-cases >> 2. >> >> topology-based use-cases: >> 1. >> >> Services Provisioning: Learning service points, connecting >> interfaces, abstracted topology >> 2. >> >> Standardized topology model: Path computation >> 3. >> >> Visibility of customer interfaces into standard topology: >> discuss use-cases >> 4. >> >> Visibility of peering interfaces into standard topology: >> discuss use-cases >> 5. >> >> Topology component history: failed links, interfaces that >> haven’t come up, etc... >> 6. >> >> Overlay topology: troubleshooting and monitoring: >> draft-amante-i2rs-topology-use-cases-00.txt Sec 4.1.3 >> 7. >> >> Interactions with ALTO: discuss use-cases >> 8. >> >> Brainstorm/discuss other use-cases >> 3. >> >> BGP-based use-cases: >> 1. >> >> Centralized VPN Provisioning: >> draft-keyupate-i2rs-bgp-usecases-00.txt Sec 2.1 >> 2. >> >> Centralized BGP Policy Updating: >> draft-keyupate-i2rs-bgp-usecases-00.txt Sec 2.2 >> 3. >> >> BGP Error Handling: draft-keyupdate-i2rs-bgp-usecases-00.txt >> Sec 3.1 >> 4. >> >> BGP Route Manipulation: >> draft-keyupdate-i2rs-bgp-usecases-00.txt Sec 4 >> 5. >> >> BGP Troubleshooting: draft-keyupdate-i2rs-bgp-usescases-00.txt >> Sec 5 >> 6. >> >> Brainstorm/discuss other use-cases >> 2. >> >> Taxonomy of network applications: centralized controller, focused >> service, always there, config & disappear, etc. >> 3. >> >> RIB info model: brainstorm initial data >> 4. >> >> Topology info model: brainstorm initial data >> 5. >> >> Communication transport options taxonomy: TLS, UDP, TCP, SCTP, etc - >> pros and cons of each for secrecy, replay attacks, reliability, etc. >> 6. >> 1. >> >> Authentication and authorization taxonomy: What types of >> authentication and authorization are desirable? Which can we reuse and >> what are their feature-sets? >> >> >> 1. >> >> >> Thanks, >> >> Alia >> >> * >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
