Subject: Re: [i2rs] I2RS charter

From: Alia Atlas <[email-masked]>
Date: Wed, 2 Jan 2013 15:27:32 -0500

Hi Adrian,

I have a few belated comments on the proposed charter, from what is today
at https://datatracker.ietf.org/doc/charter-ietf-i2rs/, - as follows:

" 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."

I think this is trying to describe what we mean by "a routing system" - but
I feel like it is missing most of the point and details - we're not
concerned about the data-forwarding interfaces, except in as much as they
are part of the forwarding plane to be programmed and provide the outgoing
interfaces to be used in a route or path.  Feel free, of course, to bash
it, but I'd like to propose replacing the entire paragraph with the
following:

"In a routing network, the routing system is responsible for
determining how data packets should be forwarded and communicating
that to the relevant forwarding or data plane.  The dispersal of both
the relevant information for this determination and the resulting
routes or paths is part of the routing system.  The relevant
forwarding or data plane need not be co-located with the portion of
the routing system that determines the routes.  However, a routing
system is frequently co-located in a network element with a forwarding
or data plane that contains one or more interface over which data
traffic is forwarded.  Thus, the routing system includes control plane
protocols that compute routes and paths for data packets."

The second paragraph starts with:

"I2RS facilitates real-time or event driven interaction with the routing
system through a

 collection of control or management interfaces."

While the type of interface is, I think, clear and beaten to death, I'd
like to jump further on it
by suggesting adding "protocol-based" to the list of possible descriptors.
 That would make it:

"I2RS facilitates real-time or event driven interaction with the routing
system through a

 collection of control or management protocol-based interfaces."

Then, in the third paragraph, we can refer back to those protocol-based
interfaces - changing from:

"The I2RS working group works to develop a framework and architecture

that will enable specific use cases, and lead to an understanding of
theinformational models and requirements for encodings and protocols."

to

"The I2RS working group works to develop a framework and architecture

that will enable specific use cases, and lead to an understanding of
theinformational models and requirements for encodings and protocols
of the control and management protocol-based interfaces."

I think that the latter two changes help connect the charter more clearly
with a bit of the clarity around interfaces that was desired.

Thoughts and opinions?
Alia

On Fri, Dec 21, 2012 at 2:35 PM, Adrian Farrel <[email-masked]> wrote:

> 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
>
>
>
>
>
>
>
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 3 Jan 2013 22:53:36 +0100

I agree with your concerns and suggestions. also my opinion is that
we're still interested to more opinions and discuss the charter
because it is important but also interested to submit the charter not
later than this month, furthermore, my concerns are that we
define/agree apon some objectives and terminologies of this group's
documents and discussions, as some one mentioned  *we are in danger of
biting off more than we can chew*. The charter gives us aim and
objectives and think it covers them and to includ Ali's suggestions to
make them more clear or easy to read.

AB

---

From: Thomas Narten <[email-masked]>
Date: Thu, 03 Jan 2013 17:14:49 -0500

> " 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."

I also find the above text unclear/confusing. Alia and I had an
offline exchange, which resulted in the following suggestion:

     In a network, the routing system is the collection of entities,
     protocols and processes that collectively build the forwarding
     tables that are exported into the entities that constitute the
     network's fowarding plane.

This attempts to say what the "routing system" in general terms while
also being clear about the separation of the data/forwarding plane
from the routing system. I2RS is presumably focussed on the latter.

I also don't think its helpful to talk about "The routing system may
be further divided to be an interface over which data traffic is
forwarded". That doesn't seem accurate, as network interfaces
typically just process packets, and I have a hard time seeing a single
interface being considered a "routing system".

> "I2RS facilitates real-time or event driven interaction with the
> routing system through a collection of control or management
> interfaces."

> While the type of interface is, I think, clear and beaten to death,
> I'd like to jump further on it by suggesting adding "protocol-based"
> to the list of possible descriptors.  That would make it:

> "I2RS facilitates real-time or event driven interaction with the
> routing system through a collection of control or management
> protocol-based interfaces."

I'm OK with this change, but the bigger question I have when reading
the charter (at a general level), is how this "management interface"
differs from what we already have today. E.g., config files. I suspect
one answer is "you can't do what we want to do through the existing
config file mechanisms", but that's only partly helpful and begs the
question of just what is something this effort is intended to do that
can't already be done today. The charter itself doesn't say anything
like that. It's just silent about why what I2RS is trying to do can't
be done today. Indeed, there is no hint at all about how this might be
done (and the BOF had lots of questions along the lines of "why can't
you use <insert favorite protocol> to do this today?"

I'm not sure what to suggest here, but my own sense is that an outside
reader looking at this charter will have a hard time understanding
just what the scope of this effort is and what problem it is trying to
solve.

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 4 Jan 2013 08:24:45 +0100

I don't think the questions are needed or amendments are necessary.
Your right that is seemed to me the same if I forgoten the documents,
however, some comment in line :)

> from the routing system. I2RS is presumably focussed on the latter.

I don't think the charter should explain much about I2RS definitions,
I prefered not to define but to state the charter aim and objectives.
> interface being considered a "routing system".

You misunderstood because you did not read the documents, all explained there.
> can't already be done today.

We know every thing could/can be done in past/present/future, but the
question is was it standard by IETF, if not then I think it answers
your question and the effort should be done.

> The charter itself doesn't say anything

we cannot do any thing without a WG and we need a charter to have authorisation.
> just what the scope of this effort is and what problem it is trying to

I think I like your idea that *what problem trying to solve* which is
a good to mention in the charter. May be some times there is no
problem but there is ideas to make better services. The case problems
are in ID started as work-in-progress.

However, I think the scope is there clear but note mentioned as
*scope* (i.e. I named it the charter aim) please read:

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 by
notification)  from the routing system while retaining data
consistency and coherency across the routers and routing
infrastructure, and among multiple interactions with the routing
system.

Maybe it will be nice to indicate that as: I2RS scope is ......etc.

AB

---

From: Thomas Narten <[email-masked]>
Date: Fri, 04 Jan 2013 09:02:49 -0500

> I prefered not to define but to state the charter aim and

But the proposed charter already has such definitions. The above is an
attempt at clarifying that terminology.

> You misunderstood because you did not read the documents, all

Well, if you have to go read documents to understand the charter, that
is not ideal. Other charters that depend on documents then tend to at
least cite what those documents are. Exactly which of the dozen+
documents with -irs- in the title contain the relevant text? And are
they consistent with each other? (Rather doubtful.)

> we cannot do any thing without a WG and we need a charter to have

My comments are not about objecting to the formation of a WG, but in
making the charter clear.

> infrastructure, and among multiple interactions with the routing

The part about "retaining data consistency and coherency" is pretty
vague and open ended to me. Just what is this supposed to mean?

What might help is to had a couple of "for example" type statements,
so folk reading the charter have an idea of what sorts of things
people have in mind. And note an example is only an
example. Mentioning an example doesn't restrict the charter to just
that example, but examples can help give people a more concrete idea
of what is envisioned. As it is now, the reader pretty much has to
guess.

Thomas

---

From: Alia Atlas <[email-masked]>
Date: Fri, 4 Jan 2013 10:48:27 -0500

Thomas,

Responses in-line

> Alia Atlas <[email-masked]> writes:
...

> just what the scope of this effort is and what problem it is trying to

 There are a couple things going on here.   First, it is entirely possible
that
the needs of I2RS could be met by extending <pick your favorite protocol
and data model language>; however, we don't want to pre-judge whether that
will be the case before the requirements and use-cases are clearly agreed
upon.

Second, the type of programmatic interface we are looking for is:
   a) "streaming" or "asynchronous" - it is possible to have many different
operations simultaneously being worked upon - from the same and different
clients.
   b)  bi-directional:  clients can register for significant events and
request information.  There is the possibility that an I2RS agent may
solicit work/direction from one or more clients as well.
   c) low-overhead and fast:  An I2RS client may have hundreds or thousands
of IRS agents that need to be occasionally communicated with - and
similarly an IRS agent may get operations from many I2RS clients.  In such
a situation, there's little need to keep alive a communication channel.
 Avoiding capability negotiation/learning every time a client reconnects is
preferable.
  d) multi-channel:  Let's acknowledge that routing elements are
multi-processor - whether that means the  control plane or the forwarding
plane - and have an interface that easily allows transmission of lots of
data from multiple processors without having to go through a particular
bottleneck.  For instance, if an I2RS client requests counter data -
potentially lots - it'd be better to have that deliverable directly from
the local line processor.

But those are my initial ideas - and what we resolve to depends on the
use-cases and WG.  So, I don't see them as belonging in the charter.

So - there are multiple aspects that I2RS is looking to handle:
   a) "application-friendly" or "machine-to-machine focused" programmatic
interfaces
   b) address the feedback loop - so that an IRS client easily has the
information to make decisions
   c) standard data models to ease application development

If you have thoughts on how to fairly describe that in the charter, they'd
certainly be welcome.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 4 Jan 2013 10:58:30 -0500

Thomas,

...

> they consistent with each other? (Rather doubtful.)

[Alia]  We did try for consistency & start from the same general idea and
the
problem-statement & framework drafts - but the work is just starting...
 ...

> vague and open ended to me. Just what is this supposed to mean?

[Alia] I read it as "don't break routing" while allowing multiple inputs
from
different applications.

> of what is envisioned. As it is now, the reader pretty much has to

[Alia]  The list of use-cases mentioned in the charter is intended to give
some more
concrete ideas as well as guide/constrain the WG.

Alia

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 4 Jan 2013 17:01:55 +0100

Hi Thomas,

I agree that your suggestion of examples in charter will help and make
it clear to others,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 4 Jan 2013 17:15:45 +0100

Hi Alia and Adrian,

I agree with Thomas that the I2RS scope should be clear to any reader,
comment in line;

> [Alia] I read it as "don't break routing" while allowing multiple inputs

exactly, I recommend to add in paragraph your reading to explain the
last items in scope paragraph,

AB

---

From: Russ White <[email-masked]>
Date: Sun, 06 Jan 2013 09:48:57 -0500

> protocols that compute routes and paths for data packets."

I would propose putting this in a bulleted list, rather than in
paragraph form --it would make for easier reading.

==
In a routed network, the routing system:

- Distributes topology and other state (network metadata)
- Uses this network metadata to determine the best path to each given
reachable destination attached to the network
- Communicates these decisions to the forwarding plane of each
forwarding device in the network

While processes participating in the routing system are often colocated
with the with local forwarding elements, this isn't a necessary condition.

Thus, the routing system includes control plane protocols that compute
routes and paths for data packets, wherever the processes implementing
those protocols may be running.
==

Does this help clarify any?

> by suggesting adding "protocol-based" to the list of possible
> descriptors.  That would make it:

Hmmm... Are you trying to further the distance between forwarding and
control interfaces here?

> that will enable specific use cases, and lead to an understanding of theinformational models and requirements for encodings and protocols of the control and management protocol-based interfaces."

This does help connect the charter to the work at hand better...

:-)

Russ

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