Subject: RE: [ipcdn] RE: Tos field - SubMgt and other IPCDN MIBs

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 5 Mar 2003 17:36:59 +0100

Inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: woensdag 26 februari 2003 14:28
> To: [email-masked]
> Cc: [email-masked]; Erik Nordmark (E-mail); [email-masked];
> Thomas Narten (E-mail)
> Subject: RE: [ipcdn] RE: Tos field - SubMgt and other IPCDN MIBs
> 
> Colleagues:
> 
> Page 3 of RFC  3260 seems to consign the last remnants of "TOS byte" to the
> dustbin of history. Consequently, per Erik & Bert's point, I'm proposing to
> change docsSubMgtPktFilterTosValue and docsSubMgtPktFilterTosMask from type
> OCTET STRING (SIZE(1)) to be:
> 
> docsSubMgtPktFilterDscpValue
>     SYNTAX Dscp          -- 0..63    RFC 3289: DIFFSERV-DSCP-TC
> docsSubMgtPktFilterDscpMask
>     SYNTAX Dscp
> 
So... you DO understand that this is a change on the wire, right?
For MIB modules that are new (or get rerooted) that is fine.
For modules that recycle or advance, that is a nono.

> That is, these are now 6-bit fields instead of 8 bits. The Mask is a slight
> misuse of the 'Dscp' Textual Convention, but I think it's intuitive enough.
> 
I still do not undertstand why you need the mask for DSCP.
Maybe you explained during the interim,... I either forgot or
I missed it. 

Are you also aware of the DscpOrAny TC?

> For consistency across IPCDN, there are several other MIBs 
> which may want to consider similar changes:
> 
> Docsis device MIB:
>     docsDevFilterIpTos/Mask, docsDevFilterTosTable, ...
> 
So this is in a MIB module where you would have to deprecate
the objects and define new ones.

Bert
> QoS MIB
>            docsQosPktClassIpTosLow
>            docsQosPktClassIpTosHigh
>            docsQosPktClassIpTosMask
> 
> PacketCable event management MTA MIB
>        (introduced in glossary; doesn't appear to be used)
> 
> PacketCable Signaling MIB
>      pktcSigDefCallSigTos
>      pktcSigDefMediaStreamTos
> 
> (I didn't look at the cablehome mibs)
> 
> Comments? Suggestions?
> 
> - Wilson
> 
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: [email-masked]
Date: Wed, 5 Mar 2003 11:31:31 -0500

>wilson> inline

                      "Wijnen, Bert                                                                                 
                      (Bert)"                  To:       [email-masked], [email-masked]                   
                      <[email-masked]        cc:       [email-masked], "Erik Nordmark (E-mail)"               
                      om>                       <[email-masked]>, [email-masked], "Thomas Narten       
                                                (E-mail)" <[email-masked]>                                       
                      03/05/03 11:36 AM        Subject:  RE: [ipcdn] RE: Tos field - SubMgt and other IPCDN MIBs    

Inline

>wilson> yes, submgt(-10) is unrooted at present anyway. Other mibs will
have to consider this.

>wilson> The mask could be used to select various AF classes, for example.
It is also likely that some deployments are still using a non-diffserv
meaning for this byte (Cisco's NetFlow?). Restricting such ad-hoc use to 6
bits doesn't seem onerous to me in order to match IETF direction, but
removing the mask would be removing significant flexibility. Using
DscpOrAny *with* the Mask sounds like sure confusion.

Bert

---

From: Michael StJohns <[email-masked]>
Date: Fri, 07 Mar 2003 08:03:49 -0500

>Inline

Given the long history of mucking with the TOS field, it makes little if 
any sense to try and define that field in terms of the current fad.  Leave 
the field/mask as it is/was rather than trying to make it work specifically 
for the flavor of the day.

Mike