Re: [i2rs] I2RS charter

[Abdussalam Baryun <[e-mail]>]

Hi Russ,

My comments/opinion in line;

On 12/24/12, Russ White <[e-mail]> wrote:
>
>
>> 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
>
> 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.

I agree too,

>
>> NEW
>> - Tightly scoped key use cases for operational use of I2RS. These use
>> cases will
>> include at least:
>
> 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.

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 :)

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

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