Subject: [Diffserv] DiffServ MIB: Whazzup with StaticRowPointer?

From: "Robert Moore" <[email-masked]>
Date: Tue, 6 Feb 2001 12:26:25 -0500

(For you non-Americans, that's "What's up...," as depicted
in an inescapable series of beer commercials currently
showing on American sports telecasts.)  If I look in
the -07 version of the DiffServ MIB, I find that the
StaticRowPointer TC is still there.  This TC was introduced
to formalize and generalize the distinction between the
"Next" and "Specific" pointers in the DiffServ MIB.  In
San Diego, however, Keith McCloghrie suggested that the
StaticRowPointer TC is the wrong way to approach the
problem it is trying to solve.  Instead, there needs to
be a TC like RowStatus or StorageType, that applies to
an object in the conceptual row being pointed to, rather
than a TC like StaticRowPointer applied to the object
doing the pointing.  Kwok and I both acknowledged that
Keith's approach may very well be better than
StaticRowPointer.

Now we're about to go to WG last call on a DiffServ MIB
that, through inertia, continues to rely on the
StaticRowPointer TC that Keith has brought into question.
So what should go forward as the DiffServ MIB:

a. The current version, with StaticRowPointer?
b. A version that removes StaticRowPointer, and makes no
   attempt to formalize the distinction between "Next"
   pointers and "Specific" pointers?
c. A version that formalizes the distinction between
   "Next" rows (that's rows, not pointers) and "Specific"
   rows along the lines that Keith has sketched?

(b) is the conservative choice here, but it requires
additional work from the MIB editors.  (c) is an option
only if someone (presumably Keith) provides a write-up of
the alternative proposal.  (a) will happen by default
unless somebody does something.

Are the WG, and the SNMP community in general, comfortable
enough with StaticRowPointer to let the MIB go down
path (a)?  I'm not really comfortable with (a) myself,
but I'll confess that I'm also not prepared to sign up for
any of the work necessary to get us to (b) or (c).

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

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

---

From: Fred Baker <[email-masked]>
Date: Thu, 08 Feb 2001 08:38:18 -0800

>    rows along the lines that Keith has sketched?

I was detained by other duties at that particular point in the meeting, and 
didn't hear Keith's comments. As I understood the matter, Kwok was there 
and picked up the comments. He and I spent about four hours together over 
Wednesday and Thursday applying comments. Sounds like we may have missed one.

Personally, I don't see a strong difference between a use of a pointer 
described in a DESCRIPTION in a variable and the same thing described in a 
a DESCRIPTION in TC. I'll do it one way, or I'll do it in another. I use 
TC's primarily to organize things that are similar, and perhaps this 
qualifies. But I do believe that we're on a style issue, and at some point 
we need to draw the line on style issues.

So here's the deal. Send me text, and I will edit it into draft -08.

At 12:26 PM 2/6/2001 -0500, Robert Moore wrote:
>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Rajeev Manur" <[email-masked]>
Date: Tue, 13 Feb 2001 11:42:33 -0800

I see that MPLS-DS draft has defined the EXP -> 802.1p mapping for pkts
going out on ethernet/LAN interfaces. I did'nt find a similar DSCP -> 802.1p
mapping define in the IP-DS RFCs/drafts. I fail to understand why do we
treat them differently..

Can anyone throw more light on this ?? Thanks

with regards,
Rajeev

---

From: Andrew Smith <[email-masked]>
Date: Tue, 13 Feb 2001 13:11:52 -0800

I was surprised about this too: when Diffserv discussed the DSCP->802.1p mapping 
(or, to be precise, the PHB->802.1p mapping) there was vocal argument to leave 
that alone as something that users would want to configure locally. I'm quite 
surprised that the MPLS WG, with largely the same folks contributing to the 
work, has decided to do the opposite.

Note that 802.1p (full reference below) only dictates the *default* queueing 
behaviour of 802.1 switches as what I call "strict priority with a few warts" 
(the class priority order is 1,2,0,3,4,5,6,7) most switches today allow 
reconfiguration for other scheduling algorithms. So it would seem to me quite 
inappropriate for IETF to define standard mappings - perhaps some standard 
defaults would be OK but that's quite a different thing (I guess I now need to 
read the draft in question in more detail :-().

Andrew

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Feb 2001 15:57:56 -0600

Specifying how PHBs are mapped to naive hardware mechanisms such
as priority is definitely out of scope for diffserv. For intserv,
the equivalent topic was handled by the ISSLL WG. There is no
DSSLL WG.

   Brian

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 14 Feb 2001 08:49:32 +0200 (EET)

> the equivalent topic was handled by the ISSLL WG. There is no

mapping diffserv to strict priority is not even interesting.  your
conclusion is still, since ethernet switch vendors have already figured
out how to map diffserv to ethernet by using their own brains and thus
don't need guidance from the diffserv working group for that.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 14 Feb 2001 08:45:17 +0200 (EET)

andrew,

mapping of an ip dscp to 802.1q user priority field should be identical
(i.e. user configurable in the same way) as mapping of the dscp to mpls
exp field.  all modern ethernet switches have that kind of
capability. the switches that i have been interested in have also
implemented policing, a number of wfqs, red, traffic shaping, etc.,
i.e., all the same stuff than a diffserv router would need to implement.

it is thus fortunate that the switch vendors have used their own brains no
matter what ietf has said or left without saying.

-- juha