Subject: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases

From: Alia Atlas <[email-masked]>
Date: Thu, 15 Aug 2013 15:23:19 -0400

There was a lot of good discussion about this draft.  There were
significant concerns about what parts should remain in the draft (e.g.
configuration related) and what to do with the BGP-related uses cases in
draft-white-i2rs-use-case.

Ed and I look forward to seeing the updated draft that resolves that
discussion.  When that updated draft is published, we will issue another
call for WG adoption.

Thanks for the reviews and discussion,
Alia

---

From: "Russ White" <[email-masked]>
Date: Thu, 15 Aug 2013 19:37:12 -0400

> There was a lot of good discussion about this draft.  There were
significant
> concerns about what parts should remain in the draft (e.g.

The first question should be --do we want to call it a RIB or general use
cases draft, or specifically focus on BGP? I'll see if I can get Keyur to
talk to me about merging the relevant parts... 

:-)

Russ

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Fri, 16 Aug 2013 01:06:52 +0000

Russ:

IMHO it would be best to keep BGP specific use cases into a separate draft.

Best Regards,
Keyur

On 8/15/13 4:37 PM, "Russ White" <[email-masked]> wrote:

>_______________________________________________
>i2rs mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Russ White" <[email-masked]>
Date: Thu, 15 Aug 2013 21:20:21 -0400

> IMHO it would be best to keep BGP specific use cases into a separate
draft.

Okay --so... That leaves us with the next question --the use cases that
aren't BGP centric --do we try and continue a draft with just those one or
two, or... ?? 

I don't really understand what the situation is at this point. My
understanding of the discussion on list and in person from way back were
that the draft I was editing and the BGP use cases draft were going to be
merged, not that one was going to subsume the other completely, leaving the
remainder out of the picture entirely... In fact, the WG originally decided
to only use one use cases draft as it's basis for work until the use cases
in that first draft were covered by requirements/etc. It now sounds like
we've changed that direction completely, and we're back to boiling the
ocean.

I'm a bit confused at this point about when those decisions were changed,
and how we intend to proceed.

:-)

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 15 Aug 2013 21:23:37 -0400

Keyur:

Can you give a bit more detail on this point? 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Keyur Patel (keyupate)
Sent: Thursday, August 15, 2013 9:07 PM
To: Russ White; 'Alia Atlas'; [email-masked]
Subject: Re: [i2rs] Results of WG Adoption Call:
draft-keyupate-i2rs-bgp-usecases

Russ:

Best Regards,
Keyur

On 8/15/13 4:37 PM, "Russ White" <[email-masked]> wrote:

>> configuration related) and what to do with the BGP-related uses cases 
>> in draft-white-i2rs-use-case.
>
>The first question should be --do we want to call it a RIB or general 
>use cases draft, or specifically focus on BGP? I'll see if I can get 
>Keyur to talk to me about merging the relevant parts...
>
>:-)
>
>Russ
>
>

---

From: "Russ White" <[email-masked]>
Date: Fri, 16 Aug 2013 08:29:08 -0400

> and how we intend to proceed.

I have one possible suggestion, after looking at the structure of the drafts
again. What I think we might want to do is to pull the bgp use cases from
draft-white to bolster the bgp use cases draft, moving the bgp use cases
draft to an editor/contributor format (since it already has a lot of co's).
The remaining use cases can be put into a rib uses cases draft, where we can
collect all the various "routing protocol agnostic" use cases. Again, we
could move this to editor/contributor --I'll be happy to hold the editor
baton for this new draft.

There may be some question about what fits where (are all the bgp uses
really limited to bgp? Do we want a separate overlay use cases, or should
these fall into the protocol related draft they work with?), but I think
this is a workable model to get all the use cases organized into a
reasonable set of drafts that can be added to, etc., until the WG gets to
the point of having a 'first set' of use cases on the table. After this
initial batch is actually published, then it's going to be better to
continue with individual drafts for individual use cases, rather than
bis'ing this set, I think.

Thoughts?

Russ

---

From: Alia Atlas <[email-masked]>
Date: Fri, 16 Aug 2013 10:59:24 -0400

Russ,

I think that we realized that documenting all the use-cases in one draft
was going to be unwieldy and not provide enough detail on the specific
requirements.

I think that the use-cases will fall into protocol-specific ones, RIB or
"protocol-agnostic" ones, topology-specific ones, and "interacts with
multiple protocols" cases.  For the latter, I think we just have to
document them separately or, possibly if they are developing at similar
maturity, in a common draft.

More specifically, what we have in charter is:

  - Tightly scoped key use cases for operational use of I2RS as follows:
    o Interactions with the Routing Information Base (RIB). Allowing read
      and write access to the RIB, but no direct access to the Forwarding
      Information Base (FIB).
    o Control and analysis of the operation of the Border Gateway Protocol
      (BGP) including the setting and activation of policies related to
      the protocol.
    o Control, optimization, and choice of traffic exit points from
      networks based on more information than provided by the dynamic
      control plane.
    o Distributed reaction to network-based attacks through rapid
      modification of the control plane behavior to reroute traffic for
      one destination while leaving standard mechanisms (filters, metrics,
      and policy) in place for other routes.
    o Service layer routing to improve on existing hub-and-spoke traffic.
    o The ability to extract information about topology from the network.
      Injection and creation of topology will not be considered as an
initial work item.

I could see a separate detailed use-case draft for each of these...  We
need the use-cases flushed out to describe the feedback loop, the
frequency, and the information needed for writing and reading and events.

Alia

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Fri, 16 Aug 2013 17:16:39 +0000

Russ,

I am ok with merging of the draft. But do u think merging non-bgp centric
use cases into bgp usecases draft makes sense?

Regards,
Keyur

---

From: t.petch <[email-masked]>
Date: Fri, 16 Aug 2013 18:31:18 +0100

----- Original Message -----
From: "Russ White" <[email-masked]>
To: "'Keyur Patel (keyupate)'" <[email-masked]>; "'Alia Atlas'"
<[email-masked]>; <[email-masked]>
Sent: Friday, August 16, 2013 1:29 PM

Russ

The recurring thought I have is that we are pressing on with design -
architecture, info-model etc - and have not, AFAIK, agreed requirements,
which the use cases should do, or at least bring out into the open.  So
I would oppose the adoption of any design document until the
requirements have greater clarity.

Your comment about boiling oceans I see rather as boiling separate
lakes, each lake being firmly founded on a different view of use cases,
and I think that that has emerged in the discussion of the info-model.

So, for me, use cases comes first, one document preferred, more than one
ok; the rest should wait.

Tom Petch

---

From: Alia Atlas <[email-masked]>
Date: Fri, 16 Aug 2013 14:36:41 -0400

Tom,

I definitely want to keep a focus on getting the use-cases better
articulated.  I've been beating that drum for over 6 months now - heck,
about a year.  We do have some reasonable individual drafts that describe
fairly well various use-cases.  As usual, different are interesting to
different people.

The WG has a very tight schedule in terms of milestones - and we need to
make progress on those even while we continue to refine the use-cases.

The problem-statement, architecture, RIB info model, and topology info
models are all basic constructs that help feed multiple use-cases and help
define what I2RS is.   Do you have particular concerns on any of those
documents?  Could you start a separate thread (so it is seen) and we can
work on those concerns?

Do you have thoughts on the use-cases?  Is a particular one interesting to
you?  Can you help with defining it better or raising the concerns and
issues?  That is exactly the kind of conversations we should be having on
the I2RS mailing list!

Regards,
Alia