Dear Suan Hares, Thanks to your response. As your request, I summarized additional comments as following below; The following material is just easy example but I hope it is useful for you and I hope you revise it more helpful for readers. "The ability to create a classification rules to recognize the routes installed in the local RIB of each forwarding device. This must include the destination prefix and the source prefix." "The ability to create a scheduling and queueing profile including a specific scheduler (strict priority, WRR, or WFQ) or a hierarchical scheduling mechanism using the configured classification rules to ensure high-priority traffic to be transmitted from queues than lower priority traffic." "The ability to apply the classification rule to an inbound interface of each forwarding device and the scheduling and queue control profile to an outbound interface of each forwarding device."
Thank you for your response again. Becuase of other business, I cannot participate to this IETF meeting but I want to continue to touch with you and discuss some of more useful use cases from provider perspective. best regards, Kwang-koog Lee (KT) On Wed, Feb 19, 2014 at 1:21 PM, Susan Hares <[email protected]> wrote: > KwangKoog: > > > > > > Along with Russ White, I want to thank you for pointing out these > additions the white draft that align with sect 5.4.4 policy. I am working > on some revisions to the draft for re-posting after IETF. > > > > Did you have any suggested text? > > > > Thank you, > > > > Sue Hares > > > > *From:* i2rs [mailto:[email protected]] *On Behalf Of *KwangKoog Lee > *Sent:* Wednesday, January 29, 2014 8:38 AM > *To:* [email protected] > *Subject:* [i2rs] question to draft-white-i2rs-use-case-01 > > > > Dear authors, > > > > I read the use case document again and overally I think this document well > worked out. > > There are a few comments below; > > > > 1) Why the updated version removes previously described two use cases > (MPLS and optimal exit)? > > > > 2) In Sec. 5, authors explained preemption on network bandwidth is > necessary for urgent movement of information from failed data center to > safe data center. But, the summary of I2RS capability and interactions has > not any detail capability about this. According to Sec 5.4.4 policy and QoS > mechanism of the architure document, I suggest that some statements about > queue control capability (priority queueing or other well-known scheduling > mechanisms, rate limit, etc ...) should be written in the summary. > > > > best regards, > > Kwang-koog Lee (KT) >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
