Subject: [i2rs] I2RS charter

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Dec 2012 19:35:36 -0000

Hi,

I have ploughed through the emails discussing the charter and come up with some
minor tweaks.

1. "Interface"
There was a strong desire to separate the two meanings of "interface". However,
the solutions suggested were all rather variable. In fact, the word is only used
in the first paragraph of the charter, so it seems best to be long-winded for
the sake of clarity. This leads to:

==
A routing system is all or part of a routing network.  A part of a routing
network may be a  single router or a collection of routers.  The routing system
may be further divided to be an interface over which data traffic is forwarded,
or a collection of such interfaces.

I2RS facilitates real-time or event driven interaction with the routing system
through a collection of control or management interfaces.  These allow
information, policies, and operational parameters to be injected into and
retrieved (as read or notification) from the routing system while retaining data
consistency and coherency across the routers and routing infrastructure, and
between multiple interactions with the routing system.
==

2. Include Control Plane Protocols
This got immediate support and leads to:

==
A routing system is all or part of a routing network.  A part of a routing
network may be a  single router or a collection of routers.  The routing system
may be further divided to be an interface over which data traffic is forwarded,
or a collection of such interfaces.  The routing system also includes the
control plane protocols that operate the routers.

I2RS facilitates real-time or event driven interaction with the routing system
through a collection of control or management interfaces.  These allow
information, policies, and operational parameters to be injected into and
retrieved (as read or notification) from the routing system while retaining data
consistency and coherency across the routers and routing infrastructure, and
between multiple interactions with the routing system.
==

3. Rationalise the Use Cases
There was good support in theory (at the BoF) for reducing / focussing the use
cases., but as I predicted, the rule of thumb is "Cut out other people's use
cases. Leave mine in."
There were some emails of a generally supportive nature for focussing the use
cases a bit better, and some suggestions for additional (but focussed) use
cases. 
Here is my suggestion based on:
  draft-atlas-irs-problem-statement section 3
  draft-keyupate-irs-bgp-usecases
  draft-white-irs-use-case-00.txt section 2
  draft-white-irs-use-case-00.txt section 3
  draft-white-irs-use-case-00.txt section 4
  draft-amante-irs-topology-use-cases
==
OLD
- Tightly scoped key use cases for operational use of I2RS. These use cases will
include at least:
   o Interactions with the RIB.
   o Association of routing policies with routing state.
   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.

   Other use cases may be adopted by the working group only after milestones
have been added to the charter page.
NEW
- Tightly scoped key use cases for operational use of I2RS. These use cases will
include at least:
   o Interactions with the RIB. Allowing read and write access to the RIB and to
the policies used to construct the FIB, but no direct access to the FIB.
   o Control and analysis of the operation of 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 quickly modification
of the control plane behavior to reroute traffic for one destination while
leaving a 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.

   Other use cases may be adopted by the working group only after milestones
have been added to the charter page.
END
==

4. Rationalise milestones
There was concern that each and every document did not need to be listed in the
milestones.  And it was noted that the chairs (once the WG is running) can add
milestones as they consider useful.
Additionally, we need to have some proposed dates against the milestones.
That leads to:

==
Jul 2013 : Request publication of an Informational document defining the problem
statement
Jul 2013 : Request publication of an Informational document defining the
architecture framework
Aug 2013 : Request publication of Informational documents describing use cases
Sep 2013 : Request publication of an Informational document defining the
protocol requirements
Sep 2013 : Request publication of an Informational document defining encoding
language requirements
Nov 2013 : Request publication of Standards Track documents specifying
information models
Nov 2013 : Request publication of an Informational document providing an
analysis of existing IETF and other protocols and encoding languages against the
requirements
Dec 2013 : Consider re-chartering
==

I have made these changes and updated the draft charter at
http://datatracker.ietf.org/doc/charter-ietf-i2rs/

It is my intention to put this charter to the IESG early in the New Year. So
please review and comment heartily.

Thanks,
Adrian

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 22 Dec 2012 15:25:53 +0100

Thanks Adrian,

I support including both 1 and 2, but if I need to choose then prefer
1, comments in lines;

> or a collection of such interfaces.

AB>Suggest Amend> A routing system SHOULD be in all or part of the
routing network.

AB> Amend to> The routing system may be further divided by an
interface over which data traffic can be forwarded, or by a collection
of such interfaces.

> between multiple interactions with the routing system.

AB> replace: between with among

> This got immediate support and leads to:

I think If included we need to define the interface within this plane,
separating I2RS protocol and the control operation protocol.

> control plane protocols that operate the routers.

AB> Amend> The routing system also includes the operational protocols
that are within control plane that operate the routers.

>   draft-amante-irs-topology-use-cases

no objection, as after a year we may recharter :)

> have been added to the charter page.

agree

> Additionally, we need to have some proposed dates against the milestones.

Yes preferable we can leave it after in the meetings and discussion
while the work and efforts is flowing, so I agree with your suggest.

> problem

+1 for the above,

> http://datatracker.ietf.org/doc/charter-ietf-i2rs/

Thanks

> It is my intention to put this charter to the IESG early in the New Year.

+1 with above,

> So

Thanking you

AB

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 Dec 2012 11:39:55 -0000

Hi Abdussalam,

Thanks for contributing.

> > network may be a  single router or a collection of routers.  The routing
> > system may be further divided to be an interface over which data 
>> traffic is forwarded, or a collection of such interfaces.
> 

Not sure what you mean.
The use of upper case here would have no meaning.
How is "should be in" more useful that "is"?

> interface over which data traffic can be forwarded, or by a collection

You have s/to be/by/
Doesn't "by" imply that it is the interface that does the dividing?
I don't think that language works.

> > I2RS facilitates real-time or event driven interaction with the routing
> > system through a collection of control or management interfaces.  
> > These allow information, policies, and operational parameters to be
> > injected into and retrieved (as read or notification) from the routing
> > system while retaining data consistency and coherency across the
> > routers and routing infrastructure, and between multiple interactions
> > with the routing system.
> 

Fine.

> > network may be a  single router or a collection of routers.  The routing
> > system may be further divided to be an interface over which data
> > traffic is forwarded, or a collection of such interfaces.  The routing
> > system also includes the control plane protocols that operate the
> > routers.
> 

I think an "operational protocol that is within the control plane" is a "control
plane protocol."

Thanks,
Adrian

---

From: Joe Marcus Clarke <[email-masked]>
Date: Sun, 23 Dec 2012 10:16:58 -0500

> between multiple interactions with the routing system.

I know this was bikeshedded quite a bit -- and I have no objection to
the dual meaning -- but I do think that these two paragraphs mix
"interface" in a way that might be confusing.  A "router" already has a
management "interface" (either virtual or physical) and that is
independent of the "interface" mentioned in paragraph two.
Unfortunately, I don't have a better suggestion other than putting the
word "programmatic" or "structured" in there to help disambiguate the
two uses.  However, since this has been beaten to death, and this is
what the majority agrees to, then so be it.

More of a nit, but I think the parenthetical portion should read, "(as
read or by notification)

> Aug 2013 : Request publication of Informational documents describing use cases

While it's written correctly here, you have two 'b's in "describing" in
the web charter.

>From the web charter:

"The I2RS working group works to develop a framework and architecture
that will enable specific use cases, and lead to an understanding of the
informational models and requirements for encodings and protocols. Small
and well-scoped use cases are critical to constrain the scope of the
work and achieve sufficient focus for the working group to deliver
successfully. Initial work within the working group will be limited to
within a single administrative domain."

Another grammatical nit, but perhaps the last two sentences could read:

"Small and well-scoped use cases are critical to constrain the scope of
the work an achieve sufficient focus for the working group to deliver
successful outcomes.  Initial work within the working group will be
limited to a single administrative domain."

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 Dec 2012 17:03:44 -0000

Thanks Joe,

> > network may be a  single router or a collection of routers.  The routing
system
> > I2RS facilitates real-time or event driven interaction with the routing
system
> I know this was bikeshedded quite a bit --

A bit? ;-)

> and I have no objection to

I think many object to programmatic on account of we are not building an API,
but a protocol.

While "interface" now appears multiple times in the paragraphs, each is
specifically qualified.

> More of a nit, but I think the parenthetical portion should read, "(as

Yes

> While it's written correctly here, you have two 'b's in "describing" in

Two b's or not two b's?

> limited to a single administrative domain."

I've made these changes.

Cheers,
Adrian

---

From: Joe Marcus Clarke <[email-masked]>
Date: Sun, 23 Dec 2012 12:24:27 -0500

>> I know this was bikeshedded quite a bit --

For some value of "a bit." :-)

> I think many object to programmatic on account of we are not building an API,

Yeah, that's why I wasn't terribly happy with either word.

> While "interface" now appears multiple times in the paragraphs, each is

Okay, I guess my reading of the second use of "interface" didn't make it
clear that it designates a hook into the routing system as opposed to a
physical or logical port on which to pass generic management and control
data.

> I've made these changes.

Thanks!  Happy holidays.

Joe

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 23 Dec 2012 18:44:06 +0100

Hi Adrian,

I agree that my input/suggestions for the charter are not necessary,
my idea was to just separate if possible the definitions of RS and the
I2RS to make it flexible until we agree on such architectures.
However, some inline;

> How is "should be in" more useful that "is"?

In the charter of  WG it is better we don't define the routing
systems. When using "is" we are somehow defining the routing system,
but using SHOULD, MUST and MAY, make clear pecifications direction
with the interfaces to these systems. The "is" seems like "must",
which I don't prefer in this stage.

> I think an "operational protocol that is within the control plane" is a

I agree, but I prefer to avoid the definition of routing system as
some prefered to avoid separating data and control interface to RS.
Also we still will discuss the I2RS architecture in the WG. I just as
not mentioning data interface and control interface to RS as types, as
we may not have to define control plane in the routing system.
Therefore, my concerns is if we mention the data and control interface
then it is ok to mention the control plane as must be included in the
routing system.

Please note that if you see that the above is not reasonable, the you
may ignore, it is just thoughts,

Regards
AB

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 Dec 2012 18:21:04 -0000

Hi,

> >> > A routing system is all or part of a routing network.  A part of a
> >> > routing network may be a  single router or a collection of
> >> > routers.  The routing system may be further divided to be
> >> > an interface over which data traffic is forwarded, or a
> >> > collection of such interfaces.
> >>

OK, I understand your point.
I think that the text describes the "routing system" which this working group
will work on.
I'm also pretty sure it describes every routing system that exists.

> > I think an "operational protocol that is within the control plane" is a
> > "control plane protocol."
> 

I think the conversation I heard on the list was that people strongly wanted to
consider the control plane as part of the routing system.

I would also add that "data interface and control interface to RS" is subtly
wrong. The word "to" is at odds with the intention. The intention is that these
interfaces are part of the routing system, not interface to the routing system.

> may ignore, it is just thoughts,

No problem.
Through discussion we get solutions.

Adrian

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 24 Dec 2012 03:50:35 +0100

Hi Adrian,

> interfaces are part of the routing system, not interface to the routing

I think that only I2RS servers must be part of the RS and not I2RS
clients. However, I think I should read more into the drafts again,
thanking you,

AB

---

From: Russ White <[email-masked]>
Date: Mon, 24 Dec 2012 08:13:23 -0500

>   draft-amante-irs-topology-use-cases

My sense is we (the authors of each of these documents) should combine
the sections indicated into one document --this would expidite the
work... We can work together to build a single "leftovers" document, or
figure how to structure another set of documents that could be used for
future phases of work after this initial batch is considered.

> - Tightly scoped key use cases for operational use of I2RS. These use cases will

My only objection here is the words "at least..." I think we want to
restrict the charter at this point, not set ourselves up to increase
scope from the start. I think we're looking for an upper bound, not a
baseline.

> Injection and creation of topology will not be considered as an initial work

I'm afraid these might be too broad in terms of the solution set. The
last 5 should fit within the first one, rather than being expansions on
the first one, I think.

:-)

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 24 Dec 2012 15:52:45 +0100

Hi Russ,

My comments/opinion in line;

> future phases of work after this initial batch is considered.

I agree too,

> scope from the start. I think we're looking for an upper bound, not a

I understand that important reason, but I prefer not and leave it as
*baseline*, because we are in the stage to think in and out the box,
open ideas and welcome new input not to keep it into some drafts'
scope. The proposed charter does form a solid framework direction not
structure. If we do restrict work to thoes drafts then the drafts are
the source of charter not the participants' ideas joining the WG. I
think it is good to encourage new participants to join as well from
the charter. As I am not an author of any of thoes drafts (still under
my and others review) and thoes drafts still didn't get to alot
discussions, that will be my opinion :)

>>Injection and creation of topology will not be considered as an initial
work item.
> last 5 should fit within the first one, rather than being expansions on

I don't think all are expansions of the first one, however, it seems
it was a reflection of the drafts on this proposed charter. I agree to
remove the last 5 if confusing by rewrite it into two points that may
relate to participants concerns (ending with three points) as:

AB>Amend to>  - The key use cases for operational use of I2RS. These
use cases will include at least:

o Interactions with the RIB. Allowing read and write access to the RIB
(includes to extract information about topology from the network) and
to the policies used to construct the FIB, but no direct access to the
FIB.

o Control and analysis of the operations of Router(s) including the setting
and activation; of policies related to the routing protocol, and
including the optimizing of traffic exit points.

o Service layer routing to improve on existing hub-and-spoke traffic.

Important Note: Injection and creation of topology will not be
considered as an initial
work item.

Regards
AB

---

From: Russ White <[email-masked]>
Date: Mon, 24 Dec 2012 09:57:16 -0500

> discussions, that will be my opinion :)

The problem we currently have isn't leaving the door open to new ideas,
or even generating new ideas --we seem to have tons of ideas about where
this work could/would be useful. The problem we currently have is
limiting the scope narrowly enough to do effective work --to chunk the
work up into small enough pieces to make it tractable.

I.e., we are in danger of biting off more than we can chew, so we need
to slice into smaller pieces. Not that we don't want to eat the whole
thing, but we don't want to eat it right this second, and all in one
bite, lest we choke...

:-)

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 24 Dec 2012 16:09:38 +0100

> thing, but we don't want to eat it right this second, and all in one

Thanks, I will never disagree about that, have a happy new year and
christmas to you and all, :-)

AB