Subject: [netmod] three color meters in diffserv model

From: FERDINAND Pienaar <[email-masked]>
Date: Tue, 30 Jun 2015 04:30:55 +0000

Hello

I think I see how container meter-cfg is intended to allow configuration of RFC 2697 and 2698 style meters (by linking two meters in the meter-list via the pointer next-meter-id). But it seems to me that a way to indicate overflow from one bucket to another during token update is needed. In RFC 2697, bucket E is incremented only if bucket C is full, i.e. C overflows into E. In RFC 2698, buckets C and P are updated independently.

The Metro Ethernet Forum's Bandwidth Profile Algorithm explicitly supports configuring this type of coupling, via parameter CF, "coupling flag".

It's not clear to me how RFC 2697 can be supported by concatenating the meters in the YANG model, unless there is a way to indicate overflow between them.

Ferdi Pienaar
Alcatel Shanghai-Bell

---

From: "Aseem Choudhary (asechoud)" <[email-masked]>
Date: Tue, 30 Jun 2015 20:46:44 +0000

Hello Ferdi,

Thanks for your question!

Single Rate Three Color Marking can be supported by configuring two
meters, one with rate and burst, second with just burst.

³Coupling flag² functionality, which is more effective in color aware
mode, is not defined by any of diffserv RFC¹s, and hence not included in
the current model.

This functionality can be added as separate augmentation ³mef² module to
base diffserv module.

Regards,
Aseem

On 6/29/15, 9:30 PM, "FERDINAND Pienaar"
<[email-masked]> wrote:

>Hello
>
>I think I see how container meter-cfg is intended to allow configuration
>of RFC 2697 and 2698 style meters (by linking two meters in the
>meter-list via the pointer next-meter-id). But it seems to me that a way
>to indicate overflow from one bucket to another during token update is
>needed. In RFC 2697, bucket E is incremented only if bucket C is full,
>i.e. C overflows into E. In RFC 2698, buckets C and P are updated
>independently.
>
>The Metro Ethernet Forum's Bandwidth Profile Algorithm explicitly
>supports configuring this type of coupling, via parameter CF, "coupling
>flag".
>
>It's not clear to me how RFC 2697 can be supported by concatenating the
>meters in the YANG model, unless there is a way to indicate overflow
>between them.
>
>Ferdi Pienaar
>Alcatel Shanghai-Bell
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: FERDINAND Pienaar <[email-masked]>
Date: Wed, 1 Jul 2015 00:59:53 +0000

Hello Aseem

Thanks for your answer! If I understand correctly, the absence of the leaf meter-rate has special meaning: the bucket gets tokens by overflow from another bucket. So for RFC 2697, bucket C is has rate CIR, and its fail-action next-meter-id points to bucket E. Bucket E has no leaf meter-rate, so its token increment comes from bucket C's overflow.

How is it determined where a bucket's overflow goes? I'm assuming it is to the bucket pointed to by the next-meter-id in its fail-action (if the target has no rate), but this is not obvious to me -- doesn't this whole mechanism deserve a mention in the description of the meter-rate and/or fail-action? Or maybe it's simpler than that, and token overflow is implied only for a list with two meters, one with a meter rate and the other without?

Regards

Ferdi

-----Original Message-----
From: Aseem Choudhary (asechoud) [mailto:[email-masked]]
Sent: Wednesday, July 01, 2015 04:47
To: FERDINAND Pienaar; [email-masked]
Subject: Re: [netmod] three color meters in diffserv model

Hello Ferdi,

Single Rate Three Color Marking can be supported by configuring two meters, one with rate and burst, second with just burst.

³Coupling flag² functionality, which is more effective in color aware mode, is not defined by any of diffserv RFC¹s, and hence not included in the current model.

This functionality can be added as separate augmentation ³mef² module to base diffserv module.

Regards,

Aseem

>I think I see how container meter-cfg is intended to allow

>configuration of RFC 2697 and 2698 style meters (by linking two meters

>in the meter-list via the pointer next-meter-id). But it seems to me

>that a way to indicate overflow from one bucket to another during token

>update is needed. In RFC 2697, bucket E is incremented only if bucket C

>is full, i.e. C overflows into E. In RFC 2698, buckets C and P are

>updated independently.

>[email-masked]<mailto:[email-masked]>