Hello Ferdi, We have following text in section 3 of the draft:
" A meter qualifies if the traffic arrival rate is based on agreed upon rate and variability. A meter is generically modeled as qualifying rate and variability defined as a token bucket. Single rate meter [RFC2697<https://tools.ietf.org/html/rfc2697>] can be defined as two such token buckets with first defining the rate and committed burst and excess burst for second bucket. “ I think it covers quite what you are suggesting. “Overflow” is implied by the algorithm. Regards, Aseem From: FERDINAND Pienaar <pienaar.ferdin...@alcatel-sbell.com.cn<mailto:pienaar.ferdin...@alcatel-sbell.com.cn>> Date: Tuesday, June 30, 2015 at 5:59 PM To: "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] three color meters in diffserv model 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:asech...@cisco.com] Sent: Wednesday, July 01, 2015 04:47 To: FERDINAND Pienaar; netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] three color meters in diffserv model 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" <pienaar.ferdin...@alcatel-sbell.com.cn<mailto:pienaar.ferdin...@alcatel-sbell.com.cn>> 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 >netmod@ietf.org<mailto:netmod@ietf.org> >https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
