Subject: [Diffserv] Any more MIB-11 issues?

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Aug 2001 12:30:39 -0500

It's getting close to the time when we will summarise all the new issues raised
on MIB-11 and attempt to get consensus on them. So if you have any more issues
please let us have them immediately.

http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-11.txt

  Brian Carpenter
  diffserv co-chair

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Tom Irwin <[email-masked]>
Date: Fri, 24 Aug 2001 13:51:53 -0500

Brian:

1.  Is the diffServMib MODULE-IDENTITY" going to be corrected?
    The "::= { mib-2 1 }" value overlaps with the MIB II "system" 
    group OID.

2.  I still need to know how to handle my previous MIB-11 Issue that is
    repeated below.  We want to implemented the IETF standards based
    DiffServ MIB on silicon coming from multiple vendors.  This type
    of issue occurs when the implementations do not have all of the
    data path elements at both ingress and egress.  For example:
      a) INGRESS: Many silicon implementations do not queue at ingress.
         Since classification happens at ingress, the egress queue
         assignments (e.g., traffic class queues for the AF PHB) must
         also be made at ingress.

      b) EGRESS: Many silicon implementations do not have classifiers
         at egress, but still have the need to set up the scheduling
         method and to set queue priorities and weights.  How can
         the data path table to point to multiple queues?

Thank you,
Tom Irwin

The DiffServ model clearly states in section 3.2 (see figure 2) that it
is not mandatory that all functional data path elements (classify,
meter, action, queuing) be implemented at both ingress and egress.

We have an Ethernet DiffServ router that has classifiers and meters for
ingress and not for egress.  Each egress port does have four traffic
queues.

The draft DiffServ MIB diffServDataPathTable allows for a given ifIndex
(i.e., port) and traffic direction (ingress or egress) the ability to
point to a single data path element.

Question:  Without an egress classifier or meter, how can the
diffServDataPathTable be used to point to all four egress queues?  This
is necessary to set up the WRR weights using the
diffServAssuredRateTable.

---

From: Fred Baker <[email-masked]>
Date: Mon, 27 Aug 2001 13:46:55 -0700

>     The "::= { mib-2 1 }" value overlaps with the MIB II "system"

yes, when we go to IANA.

>          assignments (e.g., traffic class queues for the AF PHB) must

The MIB doesn't require classification at ingress. That is an option.

Our (Cisco's) implementation classifies either at ingress or egress.

It doesn't make sense to select your egress queue at ingress. Let me give 
you a case. Companies A and B each have purchased some form of SLA with 
your favorite ISP, and the router comes from the ISP. These are *different* 
SLAs. Company A's SLA says that it may send a certain amount of DSCP 88 
traffic to the ISP, but Company B's SLA doesn't mention DSCP 88 traffic - 
that simply goes into a general queue. Without having made the forwarding 
decision that makes the set of queues available to dump traffic into known, 
how can ingress classification select the egress queue?

What you can do, however, is remember that the traffic is in class <this>, 
and configure the egress interface to put class <this> into one queue or 
another, or drop it.

>          the data path table to point to multiple queues?

I thought that was what this was all about...

>ingress and not for egress.  Each egress port does have four traffic

therefore you cannot support different SLAs on different interfaces...

Instead of asking open-ended questions, maybe you would like to make a proposal?