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

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 7 Dec 2000 18:36:54 -0500

Hmm. So with my DiffServ hat on, I find myself agreeing and disagreeing with
Brian and Andrew. I would agree that any Policy work (QDIM or not) is
obliged to be consistent with the Informal Model. Further, non-DS works
should not dictate the DS specific contents of DS works (in this case the
MIB).

I disagree with Brian and Andrew that the text is too specific. Here is the
text again and we can go through it line for line:

(1)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. (2)Since the DSCP consists of 6 bits, the values for this property
are limited to the range 0..63. (3)When the DSCP is marked, the remaining
two bit in the DS field are left unchanged.

Sentence 1 is a no brainer. For sentence 2, I would say that a currently
valid range for a DSCP is 0-63. This is clearly stated in 2474:

"Six bits of the DS field are used as a codepoint (DSCP) to select the PHB a
packet experienes at each node."

Sentence 3 is also entirely consistent with 2474:

"The value of the CU bits are ignored by differentiated services-compliant
nodes when determining the per-hop behavior to apply to a received packet."

I frankly don't see anything wrong with this text. I would view Bob's
comment as a suggestion to the MIB and PIB. However, I don't see it as a big
deal if the MIB text is not changed. The MIB explicitly mentions the DSCP,
which is in turn explicitly defined in 2474 as a 6 bit field.

regards,

-Walter

> -----Original Message-----
> From: Andrew Smith [mailto:[email-masked]]
> Sent: Thursday, December 07, 2000 1:47 PM
> To: Brian E Carpenter
> Cc: Robert Moore; [email-masked]'
> Subject: Re: [Diffserv] Degree of detail in the DiffServ MIB
> 
> 
> 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
> 
> Brian E Carpenter wrote:
> 
> > 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.h
tml
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

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