Subject: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms

From: Alia Atlas <[email-masked]>
Date: Thu, 12 Sep 2013 10:55:38 -0400

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)

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 12 Sep 2013 21:41:25 -0700

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 <[email-masked]> wrote:

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

---

From: Russ White <[email-masked]>
Date: Fri, 13 Sep 2013 07:50:36 -0700

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

<><
[email-masked]
?@?.com (engineer without a portfolio)

---

From: Alia Atlas <[email-masked]>
Date: Fri, 13 Sep 2013 11:13:56 -0400

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

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 13 Sep 2013 09:58:55 -0700

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 <[email-masked]> 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
>
> <><
> [email-masked]

---

From: "Russ White" <[email-masked]>
Date: Mon, 16 Sep 2013 09:15:04 -0400

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

> 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

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 17 Sep 2013 11:20:24 -0700

On Mon, Sep 16, 2013 at 6:15 AM, Russ White <[email-masked]> wrote:

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

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

- Sri