Re: [i2rs] I2RS charter

[Abdussalam Baryun <[e-mail]>]

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


On 1/2/13, Alia Atlas <[e-mail]> wrote:
> 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
>>
>