Re: [i2rs] I2RS charter

[Abdussalam Baryun <[e-mail]>]

Thanks Adrian,

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

On 12/21/12, 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.

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.

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

AB> replace: between with among

>
> 2. Include Control Plane Protocols
> 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.

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

AB> Amend> The routing system also includes the operational protocols
that are within control plane 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

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

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

agree

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

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.

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

+1 for the above,

> ==
>
> I have made these changes and updated the draft charter at
> 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
> please review and comment heartily.
>
> Thanks,
> Adrian
>

Thanking you

AB

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