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

From: "Robert Moore" <[email-masked]>
Date: Thu, 7 Dec 2000 13:30:29 -0500

Brian,

Part of the confusion here is that QDDIM is *not* a policy model,
nor is it called one:  its full name is "Information Model for
Describing Network Device QoS Mechanisms for Differentiated
Services."  It came about as a result of two different impulses:

1. As a part of the Policy Framework WG's proof-of-concept
   "worked example," where we would show how to apply Core
   Policy to some specific domain.  In this role it is a
   companion document to QPIM (which *is* a policy model),
   to let us illustrate the process by which a high-level
   policy gets mapped to lower-level device configuration.

2. In response to the desire for something more formal than
   "most of the authors overlap" to insure that the DiffServ
   MIB and PIB be consistent with each other.  The Informal
   Model accomplishes this to some extent, but there has
   been interest in something more formal.  This was part of
   the impetus behind NIM, which has now largely transferred
   over to SMIng.  And it's the essence of what we have been
   doing in the Policy Framework WG:  defining information
   models, which are then mapped to data models.  By having
   a common starting point, it's guaranteed that the data
   models will all be consistent with each other.

So that's what QDDIM is:  the information model not for
DiffServ policy, but for representing and configuring DiffServ
mechanisms.  Organizationally, we've got exactly the same
question for information models that we had/have for MIBs,
for PIBs, for LDAP schemas, for SMIng specifications, for...:
who should define them -- the subject matter experts/WG, or a
separate WG of experts in the particular modeling technology?
As you know, there's no agreed-upon answer to this question.

Two additional points:

  - I'm not in any way suggesting that you hold up the
    DiffServ documents -- just that the Diffserv WG
    consider updating then to reflect some of the things
    we did in QDDIM.
  - Given that DiffServ has no business touching the two
    Currently Unused bits, I'd *still* be more comfortable
    with an explicit statement that they're supposed to be
    left alone, rather than leaving it up to DiffServ
    implementers to reach this conclusion.

Regards,
Bob

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

Brian E Carpenter <[email-masked]> on 12/07/2000 12:48:25 PM

To:   Robert Moore/Raleigh/IBM@IBMUS
cc:   "[email-masked]'" <[email-masked]>
Subject:  Re: [Diffserv] Degree of detail in the DiffServ MIB

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

Robert Moore wrote:
>
> 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: "Andrea Westerinen" <[email-masked]>
Date: Thu, 7 Dec 2000 23:00:02 -0800

To comment on "how to do modeling" - modeling works best as a cooperative
effort between the subject matter experts and the modeling experts.  It
requires use cases and clearly defined "goals."  For example, the goal of
QDDIM is to model "meters, markers, droppers, ... that participate in
conditioning traffic." BTW, I thought that the informal model was very
helpful in describing what happens in "conditioning traffic".  An
information model should do the same thing - only more "formally."  Bob
basically says this in his mail, below.

Another advantage of having an information model is that you can use the
model to organize the disparate data that comes from different
MIBs/PIBs/....  The model puts the pieces in the right places and creates
"the big picture."  This is very valuable for a customer trying to do
"network management" as opposed to only looking at "diffserv managment."

Modeling assumes that there are similar concepts (systems/devices with
services and interfaces) in all networking areas - and these "superclasses"
should be defined and reused.  Then, there are specific differences in
specific domains (for example, meter and marker services versus IPsec
protocol services).  The modelers are there to help in the reuse and the
organization of the classes.  Often, questions that the modelers ask clarify
the different assumptions and opinions of the subject matter experts.

Note that the modeling process is also iterative (as all I-Ds seem to be
:-).  The modelers work with the experts and then jointly create a first
pass definition - from there, you iterate until the model covers what is
needed, and can be explained (and not apologized for :-).

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Robert Moore
Sent: Thursday, December 07, 2000 10:30 AM
To: Brian E Carpenter
Cc: [email-masked]'
Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB

Brian,

Two additional points:

Regards,
Bob

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

Bob,

  Brian

<snip>