Re: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms
On Mon, Sep 16, 2013 at 6:15 AM, Russ White ru...@riw.us wrote: Characterizing every possible QoS model is practically impossible. Do you have any standard model in mind that would be suitable to use as a base ? I was thinking about something around the diffserv work, possibly RFC4594 figures 3 or 7, perhaps. We might get someone who was more deeply involved in diffserv to give us a better model to work from. Thanks. Will look into this. I would also be interested in hearing feedback on PBR. The 5 tuple based classification seems to be the most basic. But additionally one could use other fields ethernet, MPLS, QoS bits, length, range etc to construct the classification policy. Similar issues for for rewriting packet header fields. If anyone has any specific model they would like to see please send feedback to the list (or the draft authors) with the supporting use-case. This actually goes to the definition of what PBR means. Are we thinking more like an OpenFlow model, where the entire header is used to switch, or are we thinking more like traditional PBR, where we just add source information into the switch path? The difference would be whether or not the QoS bits, for instance, are used to make a switching determination. We have started along the lines of traditional PBR that has been supported by routing-systems. We will look into other models only if there are strong use-cases and a desire in the WG to address them. :-) Russ ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs - Sri ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms
Characterizing every possible QoS model is practically impossible. Do you have any standard model in mind that would be suitable to use as a base ? I was thinking about something around the diffserv work, possibly RFC4594 figures 3 or 7, perhaps. We might get someone who was more deeply involved in diffserv to give us a better model to work from. I would also be interested in hearing feedback on PBR. The 5 tuple based classification seems to be the most basic. But additionally one could use other fields ethernet, MPLS, QoS bits, length, range etc to construct the classification policy. Similar issues for for rewriting packet header fields. If anyone has any specific model they would like to see please send feedback to the list (or the draft authors) with the supporting use-case. This actually goes to the definition of what PBR means. Are we thinking more like an OpenFlow model, where the entire header is used to switch, or are we thinking more like traditional PBR, where we just add source information into the switch path? The difference would be whether or not the QoS bits, for instance, are used to make a switching determination. :-) Russ ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms
Sri, I'm delighted to hear that some thought and progress is going on in this area. I agree that we'll want to have some templates (named objects) available. I don't see trying to standardize all of these mechanisms - though a core set of types (policing, rate-limiting, queuing, etc) certainly make sense. I can see having a template with a type and name - and the application has to understand what it was set up for. One could add to that by specifying a data-model that is used for that template... Possibly we can agree on some basic parameters that are generally supported or accepted as modeling common behavior - and that can be pointed to (or to a proprietary data-model that is more specific). Alia On Fri, Sep 13, 2013 at 12:41 AM, Sriganesh Kini sriganesh.k...@ericsson.com wrote: Hi Alia, As part of of evolving the RIB IM the authors are looking into routing-policies and policy-based-routing (PBR) IMs. As part of the PBR IMs we are discussing whether the QoS IMs (policing, rate-limiting, queueing ... etc) should be in scope and what they should include. As you quoted from the arch doc, these could vary widely across implementations and we are discussing what the core set may be. We have not finalized this yet and it is possible that the QoS IM would be in a separate draft. Also, as part of discussing routing-policies we have considered making templates (named objects) that can be re-used (e.g. across various RIBs). These objects should be at the top-level of the IMs. It would be useful to do this in a manner that is consistent across various IMs. Thanks - Sri On Thu, Sep 12, 2013 at 7:55 AM, Alia Atlas akat...@gmail.com wrote: In draft-ietf-i2rs-architecture-00 Sec 5.4.4: Many network elements have separate policy and QoS mechanisms, including knobs which affect local path computation and queue control capabilities. These capabilities vary widely across implementations, and I2RS cannot model the full range of information collection or manipulation of these attributes. A core set does need to be included in the I2RS data models and in the expected interfaces between the I2RS Agent and the network element, in order to provide basic capabilities and the hooks for future extensibility. [[Editor's note: This requires more discussion in the working group.]] I would like to start that discussion now. Personally, I have not seen or heard much discussion or any information-models around these templates. What do people think is necessary? How should this part of the architecture draft change? Thanks, Alia (WG-Chair hat off) ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms
Russ, Characterizing every possible QoS model is practically impossible. Do you have any standard model in mind that would be suitable to use as a base ? I would also be interested in hearing feedback on PBR. The 5 tuple based classification seems to be the most basic. But additionally one could use other fields ethernet, MPLS, QoS bits, length, range etc to construct the classification policy. Similar issues for for rewriting packet header fields. If anyone has any specific model they would like to see please send feedback to the list (or the draft authors) with the supporting use-case. Thanks - Sri On Fri, Sep 13, 2013 at 7:50 AM, Russ White ru...@riw.us wrote: I'm a little worried about trying to characterize every possible QoS model out there... Seems like we should just stick to some standard model, and let implementors map between that and the reality. :-) Russ ru...@riw.us ?@?.com (engineer without a portfolio) On Sep 12, 2013, at 7:55 AM, Alia Atlas akat...@gmail.com wrote: In draft-ietf-i2rs-architecture-00 Sec 5.4.4: Many network elements have separate policy and QoS mechanisms, including knobs which affect local path computation and queue control capabilities. These capabilities vary widely across implementations, and I2RS cannot model the full range of information collection or manipulation of these attributes. A core set does need to be included in the I2RS data models and in the expected interfaces between the I2RS Agent and the network element, in order to provide basic capabilities and the hooks for future extensibility. [[Editor's note: This requires more discussion in the working group.]] I would like to start that discussion now. Personally, I have not seen or heard much discussion or any information-models around these templates. What do people think is necessary? How should this part of the architecture draft change? Thanks, Alia (WG-Chair hat off) ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
