Subject: RE: [ipcdn] RE: Tos field - draft-ietf-ipcdn-subscriber-mib-09.tx t

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 20 Feb 2003 23:20:34 +0100

I think the suggestion from Erik seemed more to be
to use the Dscp or DscpOrAny TC from RFC3289.

Thanks,
Bert 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: donderdag 20 februari 2003 20:40
> To: [email-masked]
> Cc: [email-masked]; Erik Nordmark (E-mail); Ipcdn (E-mail);
> [email-masked]; Thomas Narten (E-mail)
> Subject: Re: [ipcdn] RE: Tos field -
> draft-ietf-ipcdn-subscriber-mib-09.txt
> 
> 
> 
> What is the sense of the working group?
> 
> Both the IPv6 Traffic Class octet and the old IPv4 ToS byte 
> are currently
> defined as a 6-bit DSCP plus a 2-bit ECN. As a practical 
> matter, there are
> still other network devices out there which use arbitrary 8-bit 'ToS'
> values.
> 
> The TosMask already allows us to exclude the ECN bits if 
> desired (although
> not automatically).
> 
> A minimal change would add references to IPv6 Traffic Class in the
> description.
> 
> Or we can go further to explicitly state that the low-order 
> ECN bits will
> be treated as zero.
> 
> - Wilson
> 
> 
> 
>                                                               
>                                                             
>                       "Wijnen, Bert                           
>                                                             
>                       (Bert)"                  To:       
> "Ipcdn (E-mail)" <[email-masked]>                                
>                       <[email-masked]        cc:       
> [email-masked], "Erik Nordmark (E-mail)"                     
>                       om>                       
> <[email-masked]>, "Thomas Narten (E-mail)" 
> <[email-masked]>     
>                       Sent by:                 Subject:  
> [ipcdn] RE: Tos field - draft-ietf-ipcdn-subscriber-mib-09.txt   
>                       ipcdn-admin@ietf.                       
>                                                             
>                       org                                     
>                                                             
>                                                               
>                                                             
>                                                               
>                                                             
>                       02/20/03 12:43 PM                       
>                                                             
>                                                               
>                                                             
>                                                               
>                                                             
> 
> 
> 
> 
> I asked this question (at the bottom of this email)
> to a few experts, and Erik cam back with this answer.
> So can you please evaluate this issue and respond.
> 
> Bert
> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: donderdag 20 februari 2003 14:58
> To: Wijnen, Bert (Bert)
> Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy 
> Bush (E-mail)
> Subject: Re: Tos field
> 
> 
> > Now... this is IPv4 only... So I wonder
> > - should they say something about that?
> > - should they deal with IPv6 traffic class as well, or at least
> >   mention it? They do deal with IPv6 packets, so it seems strange
> >   to not make clear that ToS filed is is IPv4 only, no?
> >   Their RFC2669 talks about Tos as well.. so maybe they just
> >   inherited it.
> 
> If the MIB does v4 and v6 it would make sense to calls this
> DSCP and have it apply across both.
> Also, I think it should be explicitly restricted to the DSCP bits and
> not be able to filter on the ECN bits - too high risk that 
> somebody could
> accidentially break ECN.
> 
> I hope they are not assuming the old IPv4 ToS definitions.
> 
>   Erik
> > -----Original Message-----
> > From: Wijnen, Bert (Bert)
> > Sent: dinsdag 18 februari 2003 13:02
> > To: Thomas Narten (E-mail); Erik Nordmark (E-mail)
> > Cc: Randy Bush (E-mail)
> > Subject: Tos field
> >
> > The draft-ietf-ipcdn-subscriber-mib-09.txt
> > (which should show up today, but revision 8 has the same)
> > has these definitions (around page 14/15):
> >
> >    docsSubMgtPktFilterTosValue OBJECT-TYPE
> >        SYNTAX      OCTET STRING (SIZE(1))
> >        MAX-ACCESS  read-create
> >        STATUS      current
> >        DESCRIPTION
> >            "The TOS value to match in the IP packet."
> >        DEFVAL { '00'h }
> >        ::= { docsSubMgtPktFilterEntry 9 }
> >
> >    docsSubMgtPktFilterTosMask OBJECT-TYPE
> >        SYNTAX      OCTET STRING(SIZE(1))
> >        MAX-ACCESS  read-create
> >        STATUS      current
> >        DESCRIPTION
> >            "The mask to apply against the TOS value to be 
> matched in the
> >        IP packet.  The default for both these objects taken together
> >        matches all TOS values. A packet matches this filter if the
> >        following is true:
> >            AND (FilterTosValue, FilterTosMask) ==
> >            AND (Packet TOS Value, FilterTosMask)."
> >        DEFVAL { '00'h }
> >        ::= { docsSubMgtPktFilterEntry 10 }
> >
> > Now... this is IPv4 only... So I wonder
> > - should they say something about that?
> > - should they deal with IPv6 traffic class as well, or at least
> >   mention it? They do deal with IPv6 packets, so it seems strange
> >   to not make clear that ToS filed is is IPv4 only, no?
> >   Their RFC2669 talks about Tos as well.. so maybe they just
> >   inherited it.
> >
> > Something that botters me now that I investigated it somewhat:
> > - RFC2096 has it defined as an Integer32
> >    ipCidrRouteTos OBJECT-TYPE
> >        SYNTAX   Integer32
> > - RFC2669 defines it as OCTET-STRING SIZE(1)
> >    docsDevFilterIpTos  OBJECT-TYP
> >        SYNTAX      OCTET STRING ( SIZE (1))
> >   So does this new docsSubMIB draft
> > - RFC1850 defines a TC for it
> >     TOSType ::= TEXTUAL-CONVENTION
> >         SYNTAX      Integer32 (0..30)
> > - RFC2925 says:
> >     pingCtlDSField OBJECT-TYPE
> >         SYNTAX      Unsigned32 (0..255)
> >     DESCRIPTION
> >         "Specifies the value to store in the Differentiated
> >         Services (DS) Field in the IP packet used to
> >         encapsulate the ping probe.  The DS Field is defined
> >         as the Type of Service (TOS) octet in a IPv4 header
> >         or as the Traffic Class octet in a IPv6 header.
> > - RFC2584 does things totally different again.. but it is
> >   SAN APPN, so I won't bother anymore (I think)
> > - RFC3289 defines a Dscp and DscpOrAny TC which I think for
> >   IPv4 also travels in the ToS field, does it not?
> >   Dscp ::= TEXTUAL-CONVENTION
> >     DISPLAY-HINT "d"
> >     STATUS   current
> >     DESCRIPTION
> >        "A Differentiated Services Code-Point that may be used for
> >        marking a traffic stream."
> >     REFERENCE
> >         "RFC 2474, RFC 2780"
> >     SYNTAX   Integer32 (0..63)
> >
> >   DscpOrAny ::= TEXTUAL-CONVENTION
> >     DISPLAY-HINT "d"
> >     STATUS   current
> >     DESCRIPTION
> >        "The IP header Differentiated Services Code-Point that may be
> >        used for discriminating among traffic streams. The 
> value -1 is
> >        used to indicate a wild card i.e. any value."
> >     REFERENCE
> >         "RFC 2474, RFC 2780"
> >     SYNTAX   Integer32 (-1 | 0..63)
> >
> >
> > Oh well... we know how to get ourselves in a mess.
> >
> > Thanks,
> > Bert
> >
> _______________________________________________
> IPCDN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 
> 
> 
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn