Re: [i2rs] I2RS charter

[Alia Atlas <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>