Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB

From: "Robert Moore" <[email-masked]>
Date: Thu, 7 Dec 2000 12:21:24 -0500

Brian,

I think that the WG question is a red herring here.  The
important question is whether the MIB and PIB need to have
this level of detail.  Whether they include it directly,
or import it by reference from a document like QDDIM, is a
secondary question.

So why *wouldn't* you want this level of detail in the MIB
and the PIB?  I don't think it's because you want to leave
vendors room to innovate in how they do DSCP marking.  The
only other argument I can think of is that the detail is
unnecessary, i.e., that everybody will implement it
correctly, even without the additional detail.  Since we've
had cases in the past where "obvious" things were
interpreted, and thus implemented, in unexpected ways,
my inclination is to err on the side of too much detail
rather than too little.  The additional detail doesn't hurt
anything, and it might help.

Regards,
Bob

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

Brian E Carpenter <[email-masked]>@ietf.org on 12/07/2000 11:12:11
AM

Sent by:  [email-masked]

To:   "[email-masked]'" <[email-masked]>
cc:
Subject:  Re: [Diffserv] Degree of detail in the DiffServ MIB

I'd like opinions from diffservers whether the Policy WG is or is not
getting into too much detail in this case.

   Brian

Robert Moore wrote:
>
> Here is the DiffServ MIB's text describing the DSCP Mark Action Table:
>
> 3.4.1.  DSCP Mark Action Table
>
>    This Action is applied to traffic in order to mark it with a Diffserv
>    Codepoint (DSCP) value, specified in the diffServDscpMarkActTable.
Other
>    marking actions might be specified elsewhere - these are outside the
>    scope of this MIB.
>
> And here is the text from QDDIM describing the property in
> a DSCP marker that holds the DSCP value:
>
> 4.4.16.1 The Property DSCPValue
>
>   This property is an unsigned 8-bit integer, representing a value to be
>   used for marking the DSCP within the DS field in an IPv4 or IPv6 packet
>   header.  Since the DSCP consists of 6 bits, the values for this
property
>   are limited to the range 0..63.  When the DSCP is marked, the remaining
>   two bit in the DS field are left unchanged.
>
> Clearly there is an additional detail in the QDDIM version:
> the statement that the remaining two bits are left unchanged.
> (The range limitation 0..63 is handled in the MIB by the
> Dscp Textual Convention (-1 | 0..63), combined with the
> description text for the object, saying that the value -1
> is not allowed.)  In the ordinary Policy Framework treatment
> ("ordinary" based on one partially completed example of PCIM
> and PCLS, but never mind that:-), this level of detail would
> be documented in the Information Model (QDDIM in this case),
> and then incorporated by reference into the Data Models (the
> MIB and the PIB) derived from it.  But in this case the Data
> Models are much more mature, and thus closer to completion,
> than the QDDIM.  The only remaining alternatives are either
> not to have the detail at all in the MIB and PIB, or else to
> copy the QDDIM text into them.  I vote for copying the text
> in, because of past history of cases in which "everybody knows
> what that means" being exposed as cases in which different
> people "know" different things.
>
> I don't have a complete list, but I'm sure this is not the
> only instance where the QDDIM has more detail than the two
> diffserv Data Models.
>
> 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

_______________________________________________
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: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Dec 2000 11:48:25 -0600

Bob,

My question is explicitly about the level of detail in QDDIM.
I don't understand why something called a policy model would
even attempt to model or describe these details. It's a WG question
because it creates a level of dependency of Policy documents
on Diffserv documents that concerns me. I don't want to hear that
we need to hold up Diffserv documents because of this dependency.

It's intentional that we say nothing whatever about the Currently 
Unused bits in DiffServ documents. They don't belong to DiffServ so
we should say nothing about them. 

  Brian

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 7 Dec 2000 11:04:34 -0800 (PST)

I think the issue here is authoritative versus informational.  The QDIM
is obviously not authoritative on the definition of the DSCP field, but
I think it could well be helpful for it to supply additional information.
So, could the issue be resolve editorially, by having the QDDIM document
refer to the source of the authoritative definition, as well as providing
the additional information ??

Keith.

---

From: John Schnizlein <[email-masked]>
Date: Thu, 07 Dec 2000 14:17:34 -0500

There is a general problem with the degree of detail in
various models for diffserv. Beyond the specification in
RFC 2427, these details interfere with the creative
flexibility in composing the blocks of functionality. [A1]
For example, models appear to limit queuing and marking
to various stages in the treatment of a packet. [Q3]

It is useful to reflect principles from RFC 2474, such as
the prohibition on masking DSCPs, in information models.
At least DSCP mask values should not occur in these models.

I see no reason to specify beyond the 64 possible integer
values of a DSCP in the MIB or PIB [Q1]. In this particular
case, the risk of implementers getting it wrong is small. [A2]

The additional dependency of MIB or PIB documents on a QDDIM
document (for information limited to what is in RFC 2474) 
would be bad [Q2].

Additional details in these models, especially if they are to
be translated into management functions, are dangerous [A3]
because they imply limitations on the use of diffserv concepts
that are not intended in the standard. Especially as the
information models, and data models derived from them, are
translated into various database schema automatically, there
is a risk that the non-standard details in the model become
de facto parts of the standard.

John

At 12:21 PM 12/07/2000 -0500, Robert Moore wrote:
>
>The important question is whether the MIB and PIB need to 
>have this level of detail.                            ---> Q1
>Whether they include it directly, or import it by reference 
>from a document like QDDIM, is a secondary question.  ---> Q2
>
>So why *wouldn't* you want this level of detail in the 
>MIB and the PIB?                                      ---> Q3
>I don't think it's because you want to leave
>vendors room to innovate in how they do DSCP marking. ---> A1
>The only other argument I can think of is that the detail 
>is unnecessary, i.e., that everybody will implement it
>correctly, even without the additional detail.        ---> A2
>Since we've had cases in the past where "obvious" things 
>were interpreted, and thus implemented, in unexpected ways,
>anything, and it might help.                          ---> A3
>...
>Brian E Carpenter on 12/07/2000 11:12:11 AM
>

---

From: Andrew Smith <[email-masked]>
Date: Thu, 07 Dec 2000 10:47:26 -0800

I guess I'm a Diffserver, not a Policier. I think that the QDDIM text is too 
specific - this is a good example of a case where importing by reference rather 
than by value is a good thing. If you make sure that the reference is precise 
enough (e.g. find the right paragraph in the appropriate DS base RFC - BTW, that 
would be a good "REFERENCE" clause addition to the Dscp TC in the MIB) then 
you've done sufficient. In particular, the CU bits should not be referenced at all.

I sympathise with the desire to include more detailed information, particularly 
in a machine-parsable form (e.g. a DESCRIPTION clause in a MIB), but that does a 
disservice when it can easily become out of date and yet it remains built in to 
the "Help" files of a management tool, for example.

Andrew Smith