Subject: [i2rs] i2rs interim reminder & small group sign-ups

From: Alia Atlas <[email-masked]>
Date: Tue, 16 Apr 2013 20:49:24 -0400

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

*

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 20 Apr 2013 04:20:21 +0200

Hi Alia,

Two little points ...

> service chaining:  Directing traffic into MPLS out-segments, LSPs, or MPLS
> tunnels (pick right level of abstraction).  Directing traffic into other
> types of tunnels.

This IMHO could be also accomplished with segment routing proposal.
Draft: draft-previdi-filsfils-isis-segment-routing-02.txt

> optimized exit scenario:  draft-white-i2rs-use-case-00.txt Sec 2

This is pretty much the objective of IDR WG document:
http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-04

Best regards,
R.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 21 Apr 2013 09:58:52 -0400

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-masked]> wrote:

> 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).
>
>          Use-cases: clear write-up of idea, how it’s done today,
>          pros/cons of doing with i2rs
>          -
>
>       Second 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
>          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.
>
>          Visibility of customer interfaces into standard topology:
>          discuss use-cases
>          4.
>
>          Topology component history: failed links, interfaces that
>          haven’t come up, etc...
>          6.
>
>          BGP Troubleshooting: draft-keyupdate-i2rs-bgp-usescases-00.txt
>          Sec 5
>          6.
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>

---

From: Alia Atlas <[email-masked]>
Date: Sun, 21 Apr 2013 12:02:58 -0400

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-masked]> wrote:

>>          Visibility of peering interfaces into standard topology:
>>          discuss use-cases
>>          5.
>>
>>          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.
>>