Subject: [ipcdn] Status - draft-ietf-ipcdn-subscriber-mib-10.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 2 Apr 2003 16:45:35 +0200

Should I consider revision 10 as the final document for
my very last check before you pass it to your AD for 
IETF Last Call? Has the WG approved this doc?

Maybe I missed some email about this.
Checking my todo-list right now

Thanks,
Bert 

> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: donderdag 20 februari 2003 23:21
> To: [email-masked]; [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
> 
> 
> 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

---

From: [email-masked]
Date: Wed, 2 Apr 2003 09:59:29 -0500

I think the WG consensus is to remove the masked DSCP, and use the
DscpOrAny TC.

Rich has also asked me to look at RFC 3289 for potential overlap. I haven't
gotten to this yet.

- Wilson

                      "Wijnen, Bert                                                                                                 
                      (Bert)"                  To:       "[email-masked]'" <[email-masked]>,                   
                      <[email-masked]         "[email-masked]'" <[email-masked]>                                                 
                      om>                      cc:       "[email-masked]'" <[email-masked]>, "'Erik Nordmark (E-mail)'"    
                                                <[email-masked]>, "'Ipcdn (E-mail)'" <[email-masked]>,                       
                      04/02/03 09:45 AM         "[email-masked]'" <[email-masked]>, "'Thomas Narten (E-mail)'"         
                                                <[email-masked]>                                                                 
                                               Subject:  Status - draft-ietf-ipcdn-subscriber-mib-10.txt                            

Thanks,
Bert

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 2 Apr 2003 15:57:51 -0700

Wilson and Bert,

One immediate issue I found, in trying to re-use the DiffServ MIB for the
DOCSIS Subscriber Management functionality, was in the structure of the Data
Path table, which is the initial table for packet classification.

The Data Path Table is the first lookup table in the DiffServ MIB, and it
uses ifIndex and ifDirection as the initial parameters to match. Upon a
match, the typical next table is the Classifier Table (although the entry
may point to other Tables in the MIB).

In the Subscriber Management MIB, the first lookup table is
docsSubMgtCmFilterTable, which uses the particular cable modem, upstream or
downstream direction (similar to ifDirection), and CM versus CPE (CPEs are
behind the CMs on the subscriber home network) source/target to map to a
filter-group. The filter-group points to a set of rows in the
docsSubMgtPktFilterTable for packet classification. The four subscriber
management filter-groups are configured through the DOCSIS 1.1/2.0 CM
registration processes.

The two gaps I see in DiffServ MIB functionality are:
1. The DiffServ MIB assumes that a uniform set of classifiers are applied to
all traffic flowing over a particular interface, because in the general
network case, one cannot differentiate traffic except by classification. The
Subscriber Management MIB assumes that distinct sets of classifiers are
applied to different groups of cable modems that co-exist on the same cable
RF interface, because the DOCSIS registration process aids the CMTS in
differentiating different CM/CPE traffic sources and sinks. Note that there
can be thousands of CMs from different filter-groups co-existing on the same
cable RF interface, so an operator would need to add thousands of Classifier
Table entries to match on specific CM/CPE sources and sinks.
2. The Subscriber Management MIB differentiates between CM source/sink
traffic and CPE source/sink traffic. The CMTS knows the difference between
CMs and CPEs on the same cable RF IP subnet(s) via the DOCSIS registration
process. Using the current DiffServ MIB, making distinctions between CM and
CPE traffic would require many more entries in the Classifier Tables, in
order to enumerate the CM source IP addresses.

It looks like the DiffServ folks were looking to use more generic parameters
than the ifIndex during the development of the MIB. From section 2.2 of RFC
3289:

   Another possible direction of abstraction is one using a concept of
   "roles" (often, but not always, applied to interfaces).  In this
   case, it may be possible to re-use the object definitions in this
   MIB, especially the parameterization tables.  The Data Path table
   will help in the reuse of the data path linkage tables by having the
   interface specific information centralized, allowing easier
   mechanical replacement of ifIndex by some sort of "roleIndex".  This
   work is ongoing.

I don't know how to apply this "ongoing work" to the immediate issues that
are solved by the current Subscriber Management MIB.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 02, 2003 9:59 AM
To: Wijnen, Bert (Bert)
Cc: [email-masked]
Subject: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt

- Wilson

                      "Wijnen, Bert

                      (Bert)"                  To:
"[email-masked]'" <[email-masked]>,                   
                      <[email-masked]         "[email-masked]'"
<[email-masked]>                                                 
                      om>                      cc:
"[email-masked]'" <[email-masked]>, "'Erik Nordmark (E-mail)'"    
                                                <[email-masked]>,
"'Ipcdn (E-mail)'" <[email-masked]>,                       
                      04/02/03 09:45 AM         "[email-masked]'"
<[email-masked]>, "'Thomas Narten (E-mail)'"         
                                                <[email-masked]>

                                               Subject:  Status -
draft-ietf-ipcdn-subscriber-mib-10.txt                            

Thanks,
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 4 Apr 2003 15:12:16 +0200

OK, I have forwarded your evaluation text to the DIFFSERV mailing
list and also to the SNMPCONF WG mailing list. They have a document
draft-ietf-snmpconf-diffpolicy-05.txt that uses role-based
concepts to work with the diffserv MIB. I did not yet check the
details, but some of you migth want to check.

In any event, if you could reuse all or parts of the diffserv mib
or of the draft-ietf-snmpconf-diffpolicy-05.txt, that would be
really great.

My initial (less ambitious) question was if you could use the
Dscp and DscpOrAny Textual Conventions out of RFC3289 instead
of using old ToS byte stuff.

Thanks,
Bert 

> From: Woundy, Richard [mailto:[email-masked]]
> Sent: donderdag 3 april 2003 0:58
> To: [email-masked]'; Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: RE: [ipcdn] Re: Status -

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 4 Apr 2003 08:41:27 -0700

Thanks, Bert.

I believe that we are committed to using the Dscp and DscpOrAny TCs for this
draft.

I will try to review draft-ietf-snmpconf-diffpolicy-05.txt sometime in the
next week, for its applicability to the Subscriber Management MIB problem
space.

-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Friday, April 04, 2003 8:12 AM
To: Woundy, Richard; [email-masked]'; Wijnen, Bert (Bert)
Cc: [email-masked]
Subject: RE: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt

Thanks,
Bert