From mailnull@www1.ietf.org Tue Apr 1 09:54:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15601 for ; Tue, 1 Apr 2003 09:54:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31FIUJ26679 for ipcdn-archive@odin.ietf.org; Tue, 1 Apr 2003 10:18:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FISK26671; Tue, 1 Apr 2003 10:18:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FHwK26602 for ; Tue, 1 Apr 2003 10:17:58 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15587 for ; Tue, 1 Apr 2003 09:53:40 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h31EtDRR020002 for ; Tue, 1 Apr 2003 07:55:13 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA03000 for ; Tue, 1 Apr 2003 07:56:05 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 1 Apr 2003 09:56:05 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9CAB7158@ma07exm01.dma.isg.mot.com> From: Patrick Michael-LZZ007 To: "'Woundy, Richard'" , "IPCDN WG (E-mail)" , "DOCSIS OSS (E-mail)" Cc: Greg White , Eduardo Cardona , "Michael W. Patrick (E-mail)" , Murwin William-LWM008 Date: Tue, 1 Apr 2003 09:55:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , I agree we should modify the wording, but not in order to support an "any" VLAN ID match. The MIB needs to reflect the semantics of the RFI spec. The spec's wording is (from SPI-RFIv1.1-I05): "The value of the field specify [sic] the matching value for the IEEE 802.1Q vlan_id bits." There is no mention that the value must be nonzero in order to match. The assumption must be that a classifier with a 22/23.11.2 parameter value of 0 would match a tagged frame with a VLAN ID of zero. This is contrary to the current -07 mib description, which states: " If this object's value is nonzero, tagged packets must have a VLAN Identifier that matches the value in order to match the rule." In other words, the MIB word requires a nonzero value in order to be matched, which is contrary to the spec. I would propose that we simply remove the wording from the MIB description "If this object's value is nonzero". As for an "any" VLAN encoding, the assumption there is that we need to allow a packet classifier to match any 802.1Q tagged packet, regardless of its VLAN Id value. While this is admittedly useful, I don't see where the RFI spec requires that operation, and I'm not sure that either CMs or CMTSs have implemented it. If I've missed an ECN to this effect, I apologize. Since I'm recommending that we NOT add a "-1" for an "any" VLANid match, I recommend that we keep the current syntax, and NOT use the VlanIdOrAny TC. Does -mike -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Monday, March 31, 2003 9:59 PM To: IPCDN WG (E-mail); DOCSIS OSS (E-mail) Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Folks, I am concerned about the lack of resolution to this issue of a "default VLAN ID" for the DOCSIS QoS MIB. Besides my concern about using a different VLAN ID definition than other IETF MIBs, my concern centers on this comment from Les Bell of 3Com: >We should not use the value 0 to indicate "any" VLAN, as this may be >used by 802.1D Bridges that support Priority Tagging, but do not >support 802.1Q VLANs. In a later email, as IETF MIB folks suggested using 4095 as the "wildcard" VLAN ID, Les' reaction was: >I have asked for the opinion of the IEEE 802.1 Task Force Chair, Mick >Seaman, on this proposal. He believes that the use of 4095 as a >wildcard VLAN-ID would be okay, but he wants to discuss it formally at >the IEEE 802 meeting in Dallas (week commencing March 9). I will be >attending this meeting. I am going to try to find out the reaction of the IEEE to this proposal. The latest proposed IETF TEXTUAL CONVENTION for a VLAN ID (with wildcard support) is: VlanIdOrAny ::= TEXTUAL CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 1..4094) I cannot find anything in the DOCSIS specifications, outside of the DOCSIS QoS MIB, that uses 0 as a special VLAN ID. -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, February 13, 2003 3:37 PM To: Greg White; Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt Inline > -----Original Message----- > From: Greg White [mailto:g.white@CableLabs.com] > Sent: donderdag 13 februari 2003 20:07 > To: Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > It is important that the range for docsQosPktClassVlanId include the > value 0: > > If the referenced parameter is not present in the > classifier, the value of this object is reported > as 0. > Well, yours also goes up to (and inclusive) 4095 while bridgemib only goes up to (and inclusive 4094). If zero is not a valid VLAN ID and you want to niclude it as not present, then maybe yours should be renamed to docsQosPktClassVlanIdOrNone or some such Bert > -Greg > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, February 13, 2003 11:44 AM > To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > Eduardo writes: > > > > FYI > > Could be in other places but a starting point. > > > > draft-ietf-bridge-bridgemib-01.txt > > > > VlanId ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The 12-bit VLAN ID used in the VLAN Tag header." > > SYNTAX INTEGER (1..4094) > > > And so... why does yours differ > docsQosPktClassVlanId OBJECT-TYPE > SYNTAX Integer32 (0..4095) > MAX-ACCESS read-only > STATUS current > > I am not claiming that one is better than the other. > But I always wonder why they are different. > Best to try and get in touch with the bridgemib people > > Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Apr 1 11:22:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26012 for ; Tue, 1 Apr 2003 11:22:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31Gk8d27377 for ipcdn-archive@odin.ietf.org; Tue, 1 Apr 2003 11:46:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Gk5K27362; Tue, 1 Apr 2003 11:46:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GjJK27043 for ; Tue, 1 Apr 2003 11:45:19 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25909 for ; Tue, 1 Apr 2003 11:20:58 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h31GNGq9007013; Tue, 1 Apr 2003 09:23:17 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Apr 2003 09:23:16 -0700 Message-ID: Thread-Topic: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID thread-index: AcL4XvLrrkDi4/EKS+a4tfEZOEDSIgAAhF4w From: "Eduardo Cardona" To: "Patrick Michael-LZZ007" , "Woundy, Richard" , "IPCDN WG (E-mail)" , "DOCSIS OSS Majordomo List" Cc: "Greg White" , "Michael W. Patrick (E-mail)" , "Murwin William-LWM008" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31GjJK27044 Subject: [ipcdn] RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I also believe that the wording description is what is needed, In addition, the current description carries the bit conversion (12 bit) from the RFI TLV encoding/ 16 bit tag 12 MSB bits. Since VLAN ID is just a well understood ID integer value mapped to the 12 MSB, I think that is not needed or the TC VlanIdOrAny will cover that by definition when referencing 802.1x. Or that definition should be in the TC itself. Proposed to remove: "Only the least significant 12 bits of this object's value are valid." To keep the most backward compatibility with existing implementations and MIB/RFI spec balance: - not sure if needed since already included in RFI Appendix C.2.1.7.2- "If this field is omitted, then comparison of the IEEE 802.1Q vlan_id bits for this entry is irrelevant." -> regardless of the MIB reported value. Proposed: ( -1 | 4095) TBD by IETF If the referenced parameter is not present in the classifier, the value of this object is reported as a VlanIdorAny Wildcard value (-1 | 4095.) and ignored when matching the Ethernet frame. Original: docsQosPktClassVlanId OBJECT-TYPE SYNTAX Integer32 (0..4095) MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Q tag header. If this object's value is nonzero, tagged packets must have a VLAN Identifier that matches the value in order to match the rule. Only the least significant 12 bits of this object's value are valid. If the referenced parameter is not present in the classifier, the value of this object is reported as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2" ::= { docsQosPktClassEntry 24 } Proposed: docsQosPktClassVlanId OBJECT-TYPE SYNTAX VlanIdOrAny MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Q tag header. Tagged packets must have a VLAN Identifier that matches the value in order to match the rule. If the referenced parameter is not present in the classifier, the value of this object is reported as the VlanIdorAny wildcard value (-1 | 4095.) and ignored when matching the Ethernet frame. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2" ::= { docsQosPktClassEntry 24 } More clarifications to changes, It is an IETF rule to identify any common object as a whole entity and being normalized to minimize the number of TC used among all IETF Groups. There are some concerns ( not sure how bad would be) for huge Management systems with hundreds of mibs compiled and at the same time hundred of objects with similar behavior using different TCs. Also TCs at some point may have a lot of code behind in operations to follow the their Description rules. For integrators few TC are better. Then, I think the only pendig item is the IETF decision of what is better -1 or 4095 as a valid "wildcard" - IETF- term DOCSIS as you pointed "does not" require wildcarding of the VLAN ID, but not having this parameter in the classifier means ignore it which is a kind of "wildcarding" "orAny" regardless of the mib value. Backward compatibility, Regardless of -1|4905 or 0: As far MSO understand possible side effects in trying to use VLAN ID 0 for a matching classifier, internally all implementations may work fine. The mib difference is noticed by pointing to the old mib DOCS-QOS-MIB or the new one DOCS-QOS-IETF-MIB in the Support systems. I do not think we have other option than be tide to IETF TC if they insist in that. Now, the point in the TC "4095" is should it be -1 or 4095 and it will be an IETF decision where we may be interested. I would think in 4095 as a better "normalized" like an inverse-mask with AND operations, or does any one recognize the mask -1 -1 -1 -1 rather than FF FF FF FF ? But maybe the -1 value is being implemented already in the context of 802.1Q and this group should take the IETF recommendations. Eduardo -----Original Message----- From: Patrick Michael-LZZ007 [mailto:Michael.Patrick@motorola.com] Sent: Tuesday, April 01, 2003 7:56 AM To: 'Woundy, Richard'; IPCDN WG (E-mail); DOCSIS OSS Majordomo List Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID I agree we should modify the wording, but not in order to support an "any" VLAN ID match. The MIB needs to reflect the semantics of the RFI spec. The spec's wording is (from SPI-RFIv1.1-I05): "The value of the field specify [sic] the matching value for the IEEE 802.1Q vlan_id bits." There is no mention that the value must be nonzero in order to match. The assumption must be that a classifier with a 22/23.11.2 parameter value of 0 would match a tagged frame with a VLAN ID of zero. This is contrary to the current -07 mib description, which states: " If this object's value is nonzero, tagged packets must have a VLAN Identifier that matches the value in order to match the rule." In other words, the MIB word requires a nonzero value in order to be matched, which is contrary to the spec. I would propose that we simply remove the wording from the MIB description "If this object's value is nonzero". As for an "any" VLAN encoding, the assumption there is that we need to allow a packet classifier to match any 802.1Q tagged packet, regardless of its VLAN Id value. While this is admittedly useful, I don't see where the RFI spec requires that operation, and I'm not sure that either CMs or CMTSs have implemented it. If I've missed an ECN to this effect, I apologize. Since I'm recommending that we NOT add a "-1" for an "any" VLANid match, I recommend that we keep the current syntax, and NOT use the VlanIdOrAny TC. Does -mike -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Monday, March 31, 2003 9:59 PM To: IPCDN WG (E-mail); DOCSIS OSS (E-mail) Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Folks, I am concerned about the lack of resolution to this issue of a "default VLAN ID" for the DOCSIS QoS MIB. Besides my concern about using a different VLAN ID definition than other IETF MIBs, my concern centers on this comment from Les Bell of 3Com: >We should not use the value 0 to indicate "any" VLAN, as this may be >used by 802.1D Bridges that support Priority Tagging, but do not >support 802.1Q VLANs. In a later email, as IETF MIB folks suggested using 4095 as the "wildcard" VLAN ID, Les' reaction was: >I have asked for the opinion of the IEEE 802.1 Task Force Chair, Mick >Seaman, on this proposal. He believes that the use of 4095 as a >wildcard VLAN-ID would be okay, but he wants to discuss it formally at >the IEEE 802 meeting in Dallas (week commencing March 9). I will be >attending this meeting. I am going to try to find out the reaction of the IEEE to this proposal. The latest proposed IETF TEXTUAL CONVENTION for a VLAN ID (with wildcard support) is: VlanIdOrAny ::= TEXTUAL CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 1..4094) I cannot find anything in the DOCSIS specifications, outside of the DOCSIS QoS MIB, that uses 0 as a special VLAN ID. -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, February 13, 2003 3:37 PM To: Greg White; Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt Inline > -----Original Message----- > From: Greg White [mailto:g.white@CableLabs.com] > Sent: donderdag 13 februari 2003 20:07 > To: Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > It is important that the range for docsQosPktClassVlanId include the > value 0: > > If the referenced parameter is not present in the > classifier, the value of this object is reported > as 0. > Well, yours also goes up to (and inclusive) 4095 while bridgemib only goes up to (and inclusive 4094). If zero is not a valid VLAN ID and you want to niclude it as not present, then maybe yours should be renamed to docsQosPktClassVlanIdOrNone or some such Bert > -Greg > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, February 13, 2003 11:44 AM > To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > Eduardo writes: > > > > FYI > > Could be in other places but a starting point. > > > > draft-ietf-bridge-bridgemib-01.txt > > > > VlanId ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The 12-bit VLAN ID used in the VLAN Tag header." > > SYNTAX INTEGER (1..4094) > > > And so... why does yours differ > docsQosPktClassVlanId OBJECT-TYPE > SYNTAX Integer32 (0..4095) > MAX-ACCESS read-only > STATUS current > > I am not claiming that one is better than the other. > But I always wonder why they are different. > Best to try and get in touch with the bridgemib people > > Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Apr 1 18:22:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21384 for ; Tue, 1 Apr 2003 18:22:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31NkXr31796 for ipcdn-archive@odin.ietf.org; Tue, 1 Apr 2003 18:46:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Nk9K31782; Tue, 1 Apr 2003 18:46:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Nj9K31713 for ; Tue, 1 Apr 2003 18:45:09 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21219 for ; Tue, 1 Apr 2003 18:20:39 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h31NMwq9021915; Tue, 1 Apr 2003 16:22:59 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Apr 2003 16:22:58 -0700 Message-ID: Thread-Topic: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID thread-index: AcL4XvLrrkDi4/EKS+a4tfEZOEDSIgAAhF4wAAqFQtA= From: "Eduardo Cardona" To: "Eduardo Cardona" , "Patrick Michael-LZZ007" , "Woundy, Richard" , "IPCDN WG (E-mail)" , "DOCSIS OSS Majordomo List" Cc: "Greg White" , "Michael W. Patrick (E-mail)" , "Murwin William-LWM008" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31Nj9K31714 Subject: [ipcdn] RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Some extra findings. In Table 9-2 section 9.3.2.3 VID of format Std 802.1Q-1998 * VID value (hexadecimal) -> Meaning/Use * 0 -> The null VLAN ID. Indicates that the tag header contains only user_priority infor- mation; no VLAN identifier is present in the frame. This VID value shall not be configured as a PVID, configured in any Filtering Database entry, or used in any Management operation. * 1 -> The default PVID value used for classifying frames on ingress through a Bridge Port. The PVID value can be changed by management on a per-Port basis. * FFF -> Reserved for implementation use. This VID value shall not be configured as a PVID, configured in any Filtering Database entry, used in any Management oper- ation, or transmitted in a tag header. so I guess the already defined VlanIdOrAny TC is accurate and 0 or 4095 should not be used in any management operation -aka config File/ Mib reporting- (*) The RFI spec may also reflect this constrains for the compound value vlan_id1, vlan_id2 in C.2.1.7.2 to not configure 0 or 4095 in the config file which I refer as a good practice in my previous email : "ignorance accident" of my part Also a paragraph from the same section: "A priority-tagged frame is a tagged frame whose tag header contains a VID value equal to the null VLAN ID." which is covered in TLV definition in IEEE 802.1P User_Priority in RFI C.2.1.7.1 So, with Patricks comments' I guess a closed mib description could be: docsQosPktClassVlanId OBJECT-TYPE SYNTAX VlanIdOrAny MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Q tag header. Tagged packets must have a VLAN Identifier that matches the value in order to match the rule. If the referenced parameter is not present in the classifier, the value of this object is reported as the VlanIdOrAny wildcard value -1 and ignored when matching the Ethernet frame. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2" ::= { docsQosPktClassEntry 24 } VlanIdOrAny ::= TEXTUAL CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 1..4094) -----Original Message----- From: Eduardo Cardona Sent: Tuesday, April 01, 2003 9:23 AM To: Patrick Michael-LZZ007; Woundy, Richard; IPCDN WG (E-mail); DOCSIS OSS Majordomo List Cc: Greg White; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID I also believe that the wording description is what is needed, In addition, the current description carries the bit conversion (12 bit) from the RFI TLV encoding/ 16 bit tag 12 MSB bits. Since VLAN ID is just a well understood ID integer value mapped to the 12 MSB, I think that is not needed or the TC VlanIdOrAny will cover that by definition when referencing 802.1x. Or that definition should be in the TC itself. Proposed to remove: "Only the least significant 12 bits of this object's value are valid." To keep the most backward compatibility with existing implementations and MIB/RFI spec balance: - not sure if needed since already included in RFI Appendix C.2.1.7.2- "If this field is omitted, then comparison of the IEEE 802.1Q vlan_id bits for this entry is irrelevant." -> regardless of the MIB reported value. Proposed: ( -1 | 4095) TBD by IETF If the referenced parameter is not present in the classifier, the value of this object is reported as a VlanIdorAny Wildcard value (-1 | 4095.) and ignored when matching the Ethernet frame. Original: docsQosPktClassVlanId OBJECT-TYPE SYNTAX Integer32 (0..4095) MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Q tag header. If this object's value is nonzero, tagged packets must have a VLAN Identifier that matches the value in order to match the rule. Only the least significant 12 bits of this object's value are valid. If the referenced parameter is not present in the classifier, the value of this object is reported as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2" ::= { docsQosPktClassEntry 24 } Proposed: docsQosPktClassVlanId OBJECT-TYPE SYNTAX VlanIdOrAny MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Q tag header. Tagged packets must have a VLAN Identifier that matches the value in order to match the rule. If the referenced parameter is not present in the classifier, the value of this object is reported as the VlanIdOrAny wildcard value (-1 | 4095.) and ignored when matching the Ethernet frame. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2" ::= { docsQosPktClassEntry 24 } More clarifications to changes, It is an IETF rule to identify any common object as a whole entity and being normalized to minimize the number of TC used among all IETF Groups. There are some concerns ( not sure how bad would be) for huge Management systems with hundreds of mibs compiled and at the same time hundred of objects with similar behavior using different TCs. Also TCs at some point may have a lot of code behind in operations to follow the their Description rules. For integrators few TC are better. Then, I think the only pendig item is the IETF decision of what is better -1 or 4095 as a valid "wildcard" - IETF- term DOCSIS as you pointed "does not" require wildcarding of the VLAN ID, but not having this parameter in the classifier means ignore it which is a kind of "wildcarding" "orAny" regardless of the mib value. Backward compatibility, Regardless of -1|4905 or 0: As far MSO understand possible side effects in trying to use VLAN ID 0 for a matching classifier, internally all implementations may work fine. The mib difference is noticed by pointing to the old mib DOCS-QOS-MIB or the new one DOCS-QOS-IETF-MIB in the Support systems. I do not think we have other option than be tide to IETF TC if they insist in that. Now, the point in the TC "4095" is should it be -1 or 4095 and it will be an IETF decision where we may be interested. I would think in 4095 as a better "normalized" like an inverse-mask with AND operations, or does any one recognize the mask -1 -1 -1 -1 rather than FF FF FF FF ? But maybe the -1 value is being implemented already in the context of 802.1Q and this group should take the IETF recommendations. Eduardo -----Original Message----- From: Patrick Michael-LZZ007 [mailto:Michael.Patrick@motorola.com] Sent: Tuesday, April 01, 2003 7:56 AM To: 'Woundy, Richard'; IPCDN WG (E-mail); DOCSIS OSS Majordomo List Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID I agree we should modify the wording, but not in order to support an "any" VLAN ID match. The MIB needs to reflect the semantics of the RFI spec. The spec's wording is (from SPI-RFIv1.1-I05): "The value of the field specify [sic] the matching value for the IEEE 802.1Q vlan_id bits." There is no mention that the value must be nonzero in order to match. The assumption must be that a classifier with a 22/23.11.2 parameter value of 0 would match a tagged frame with a VLAN ID of zero. This is contrary to the current -07 mib description, which states: " If this object's value is nonzero, tagged packets must have a VLAN Identifier that matches the value in order to match the rule." In other words, the MIB word requires a nonzero value in order to be matched, which is contrary to the spec. I would propose that we simply remove the wording from the MIB description "If this object's value is nonzero". As for an "any" VLAN encoding, the assumption there is that we need to allow a packet classifier to match any 802.1Q tagged packet, regardless of its VLAN Id value. While this is admittedly useful, I don't see where the RFI spec requires that operation, and I'm not sure that either CMs or CMTSs have implemented it. If I've missed an ECN to this effect, I apologize. Since I'm recommending that we NOT add a "-1" for an "any" VLANid match, I recommend that we keep the current syntax, and NOT use the VlanIdOrAny TC. Does -mike -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Monday, March 31, 2003 9:59 PM To: IPCDN WG (E-mail); DOCSIS OSS (E-mail) Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Folks, I am concerned about the lack of resolution to this issue of a "default VLAN ID" for the DOCSIS QoS MIB. Besides my concern about using a different VLAN ID definition than other IETF MIBs, my concern centers on this comment from Les Bell of 3Com: >We should not use the value 0 to indicate "any" VLAN, as this may be >used by 802.1D Bridges that support Priority Tagging, but do not >support 802.1Q VLANs. In a later email, as IETF MIB folks suggested using 4095 as the "wildcard" VLAN ID, Les' reaction was: >I have asked for the opinion of the IEEE 802.1 Task Force Chair, Mick >Seaman, on this proposal. He believes that the use of 4095 as a >wildcard VLAN-ID would be okay, but he wants to discuss it formally at >the IEEE 802 meeting in Dallas (week commencing March 9). I will be >attending this meeting. I am going to try to find out the reaction of the IEEE to this proposal. The latest proposed IETF TEXTUAL CONVENTION for a VLAN ID (with wildcard support) is: VlanIdOrAny ::= TEXTUAL CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 1..4094) I cannot find anything in the DOCSIS specifications, outside of the DOCSIS QoS MIB, that uses 0 as a special VLAN ID. -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, February 13, 2003 3:37 PM To: Greg White; Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt Inline > -----Original Message----- > From: Greg White [mailto:g.white@CableLabs.com] > Sent: donderdag 13 februari 2003 20:07 > To: Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > It is important that the range for docsQosPktClassVlanId include the > value 0: > > If the referenced parameter is not present in the > classifier, the value of this object is reported > as 0. > Well, yours also goes up to (and inclusive) 4095 while bridgemib only goes up to (and inclusive 4094). If zero is not a valid VLAN ID and you want to niclude it as not present, then maybe yours should be renamed to docsQosPktClassVlanIdOrNone or some such Bert > -Greg > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, February 13, 2003 11:44 AM > To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > Eduardo writes: > > > > FYI > > Could be in other places but a starting point. > > > > draft-ietf-bridge-bridgemib-01.txt > > > > VlanId ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The 12-bit VLAN ID used in the VLAN Tag header." > > SYNTAX INTEGER (1..4094) > > > And so... why does yours differ > docsQosPktClassVlanId OBJECT-TYPE > SYNTAX Integer32 (0..4095) > MAX-ACCESS read-only > STATUS current > > I am not claiming that one is better than the other. > But I always wonder why they are different. > Best to try and get in touch with the bridgemib people > > Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Apr 2 09:45:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10942 for ; Wed, 2 Apr 2003 09:45:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32F9pi13856 for ipcdn-archive@odin.ietf.org; Wed, 2 Apr 2003 10:09:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32F9RK13807; Wed, 2 Apr 2003 10:09:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32F86K13696 for ; Wed, 2 Apr 2003 10:08:06 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10868; Wed, 2 Apr 2003 09:43:16 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32Ejii19661; Wed, 2 Apr 2003 09:45:44 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 16:45:43 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501483C58@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Wilson.Sawyer@arrisi.com'" , "'ipcdn@ietf.org'" Cc: "'bwijnen@lucent.com'" , "'Erik Nordmark (E-mail)'" , "'Ipcdn (E-mail)'" , "'ipcdn-admin@ietf.org'" , "'Thomas Narten (E-mail)'" Date: Wed, 2 Apr 2003 16:45:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [ipcdn] Status - draft-ietf-ipcdn-subscriber-mib-10.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , 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: Wilson.Sawyer@arrisi.com; ipcdn@ietf.org > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); Ipcdn (E-mail); > ipcdn-admin@ietf.org; 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: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > Sent: donderdag 20 februari 2003 20:40 > > To: ipcdn@ietf.org > > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); Ipcdn (E-mail); > > ipcdn-admin@ietf.org; 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)" > > > bwijnen@lucent.com, "Erik Nordmark (E-mail)" > > om> > > , "Thomas Narten (E-mail)" > > > > 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:Erik.Nordmark@sun.com] > > 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 > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Apr 2 09:58:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11314 for ; Wed, 2 Apr 2003 09:58:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32FN5R14656 for ipcdn-archive@odin.ietf.org; Wed, 2 Apr 2003 10:23:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32FN1K14645; Wed, 2 Apr 2003 10:23:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32FMEK14601 for ; Wed, 2 Apr 2003 10:22:14 -0500 Received: from titan.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11273 for ; Wed, 2 Apr 2003 09:57:24 -0500 (EST) From: Wilson.Sawyer@arrisi.com To: "Wijnen, Bert (Bert)" Cc: ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Wed, 2 Apr 2003 09:59:29 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 04/02/2003 09:59:32 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , 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: "'Wilson.Sawyer@arrisi.com'" , om> cc: "'bwijnen@lucent.com'" , "'Erik Nordmark (E-mail)'" , "'Ipcdn (E-mail)'" , 04/02/03 09:45 AM "'ipcdn-admin@ietf.org'" , "'Thomas Narten (E-mail)'" Subject: Status - draft-ietf-ipcdn-subscriber-mib-10.txt 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: Wilson.Sawyer@arrisi.com; ipcdn@ietf.org > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); Ipcdn (E-mail); > ipcdn-admin@ietf.org; 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: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > Sent: donderdag 20 februari 2003 20:40 > > To: ipcdn@ietf.org > > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); Ipcdn (E-mail); > > ipcdn-admin@ietf.org; 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)" > > > bwijnen@lucent.com, "Erik Nordmark (E-mail)" > > om> > > , "Thomas Narten (E-mail)" > > > > 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:Erik.Nordmark@sun.com] > > 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 > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Apr 2 10:32:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13928 for ; Wed, 2 Apr 2003 10:32:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32FuxD17599 for ipcdn-archive@odin.ietf.org; Wed, 2 Apr 2003 10:56:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32FuTK17566; Wed, 2 Apr 2003 10:56:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32FosK17079 for ; Wed, 2 Apr 2003 10:50:54 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13659 for ; Wed, 2 Apr 2003 10:26:04 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h32FSVaX013649 for ; Wed, 2 Apr 2003 08:28:32 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA15726; Wed, 2 Apr 2003 08:26:00 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 2 Apr 2003 10:28:30 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9CAB715E@ma07exm01.dma.isg.mot.com> From: Patrick Michael-LZZ007 To: "'Eduardo Cardona'" , "Woundy, Richard" , "IPCDN WG (E-mail)" , DOCSIS OSS Majordomo List , "Woundy, Richard" , "IPCDN WG (E-mail)" , DOCSIS OSS Majordomo List Cc: Greg White , "Michael W. Patrick (E-mail)" , Murwin William-LWM008 Date: Wed, 2 Apr 2003 10:28:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [ipcdn] RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Eduardo, Don't you think it would be confusing to report -1 as "any" for the value when the parameter is omitted? The object is not used for classification in this case, so it doesn't match "any" tagged packet. My whole point in keeping the reporting of the value 0 is to say that we do NOT match "any" tagged VLAN value. -mike -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: Tuesday, April 01, 2003 11:23 AM To: Patrick Michael-LZZ007; Woundy, Richard; IPCDN WG (E-mail); DOCSIS OSS Majordomo List; Patrick Michael-LZZ007; Woundy, Richard; IPCDN WG (E-mail); DOCSIS OSS Majordomo List Cc: Greg White; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID I also believe that the wording description is what is needed, In addition, the current description carries the bit conversion (12 bit) from the RFI TLV encoding/ 16 bit tag 12 MSB bits. Since VLAN ID is just a well understood ID integer value mapped to the 12 MSB, I think that is not needed or the TC VlanIdOrAny will cover that by definition when referencing 802.1x. Or that definition should be in the TC itself. Proposed to remove: "Only the least significant 12 bits of this object's value are valid." To keep the most backward compatibility with existing implementations and MIB/RFI spec balance: - not sure if needed since already included in RFI Appendix C.2.1.7.2- "If this field is omitted, then comparison of the IEEE 802.1Q vlan_id bits for this entry is irrelevant." -> regardless of the MIB reported value. Proposed: ( -1 | 4095) TBD by IETF If the referenced parameter is not present in the classifier, the value of this object is reported as a VlanIdorAny Wildcard value (-1 | 4095.) and ignored when matching the Ethernet frame. Original: docsQosPktClassVlanId OBJECT-TYPE SYNTAX Integer32 (0..4095) MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Q tag header. If this object's value is nonzero, tagged packets must have a VLAN Identifier that matches the value in order to match the rule. Only the least significant 12 bits of this object's value are valid. If the referenced parameter is not present in the classifier, the value of this object is reported as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2" ::= { docsQosPktClassEntry 24 } Proposed: docsQosPktClassVlanId OBJECT-TYPE SYNTAX VlanIdOrAny MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Q tag header. Tagged packets must have a VLAN Identifier that matches the value in order to match the rule. If the referenced parameter is not present in the classifier, the value of this object is reported as the VlanIdorAny wildcard value (-1 | 4095.) and ignored when matching the Ethernet frame. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2" ::= { docsQosPktClassEntry 24 } More clarifications to changes, It is an IETF rule to identify any common object as a whole entity and being normalized to minimize the number of TC used among all IETF Groups. There are some concerns ( not sure how bad would be) for huge Management systems with hundreds of mibs compiled and at the same time hundred of objects with similar behavior using different TCs. Also TCs at some point may have a lot of code behind in operations to follow the their Description rules. For integrators few TC are better. Then, I think the only pendig item is the IETF decision of what is better -1 or 4095 as a valid "wildcard" - IETF- term DOCSIS as you pointed "does not" require wildcarding of the VLAN ID, but not having this parameter in the classifier means ignore it which is a kind of "wildcarding" "orAny" regardless of the mib value. Backward compatibility, Regardless of -1|4905 or 0: As far MSO understand possible side effects in trying to use VLAN ID 0 for a matching classifier, internally all implementations may work fine. The mib difference is noticed by pointing to the old mib DOCS-QOS-MIB or the new one DOCS-QOS-IETF-MIB in the Support systems. I do not think we have other option than be tide to IETF TC if they insist in that. Now, the point in the TC "4095" is should it be -1 or 4095 and it will be an IETF decision where we may be interested. I would think in 4095 as a better "normalized" like an inverse-mask with AND operations, or does any one recognize the mask -1 -1 -1 -1 rather than FF FF FF FF ? But maybe the -1 value is being implemented already in the context of 802.1Q and this group should take the IETF recommendations. Eduardo -----Original Message----- From: Patrick Michael-LZZ007 [mailto:Michael.Patrick@motorola.com] Sent: Tuesday, April 01, 2003 7:56 AM To: 'Woundy, Richard'; IPCDN WG (E-mail); DOCSIS OSS Majordomo List Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID I agree we should modify the wording, but not in order to support an "any" VLAN ID match. The MIB needs to reflect the semantics of the RFI spec. The spec's wording is (from SPI-RFIv1.1-I05): "The value of the field specify [sic] the matching value for the IEEE 802.1Q vlan_id bits." There is no mention that the value must be nonzero in order to match. The assumption must be that a classifier with a 22/23.11.2 parameter value of 0 would match a tagged frame with a VLAN ID of zero. This is contrary to the current -07 mib description, which states: " If this object's value is nonzero, tagged packets must have a VLAN Identifier that matches the value in order to match the rule." In other words, the MIB word requires a nonzero value in order to be matched, which is contrary to the spec. I would propose that we simply remove the wording from the MIB description "If this object's value is nonzero". As for an "any" VLAN encoding, the assumption there is that we need to allow a packet classifier to match any 802.1Q tagged packet, regardless of its VLAN Id value. While this is admittedly useful, I don't see where the RFI spec requires that operation, and I'm not sure that either CMs or CMTSs have implemented it. If I've missed an ECN to this effect, I apologize. Since I'm recommending that we NOT add a "-1" for an "any" VLANid match, I recommend that we keep the current syntax, and NOT use the VlanIdOrAny TC. Does -mike -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Monday, March 31, 2003 9:59 PM To: IPCDN WG (E-mail); DOCSIS OSS (E-mail) Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Folks, I am concerned about the lack of resolution to this issue of a "default VLAN ID" for the DOCSIS QoS MIB. Besides my concern about using a different VLAN ID definition than other IETF MIBs, my concern centers on this comment from Les Bell of 3Com: >We should not use the value 0 to indicate "any" VLAN, as this may be >used by 802.1D Bridges that support Priority Tagging, but do not >support 802.1Q VLANs. In a later email, as IETF MIB folks suggested using 4095 as the "wildcard" VLAN ID, Les' reaction was: >I have asked for the opinion of the IEEE 802.1 Task Force Chair, Mick >Seaman, on this proposal. He believes that the use of 4095 as a >wildcard VLAN-ID would be okay, but he wants to discuss it formally at >the IEEE 802 meeting in Dallas (week commencing March 9). I will be >attending this meeting. I am going to try to find out the reaction of the IEEE to this proposal. The latest proposed IETF TEXTUAL CONVENTION for a VLAN ID (with wildcard support) is: VlanIdOrAny ::= TEXTUAL CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 1..4094) I cannot find anything in the DOCSIS specifications, outside of the DOCSIS QoS MIB, that uses 0 as a special VLAN ID. -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, February 13, 2003 3:37 PM To: Greg White; Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt Inline > -----Original Message----- > From: Greg White [mailto:g.white@CableLabs.com] > Sent: donderdag 13 februari 2003 20:07 > To: Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > It is important that the range for docsQosPktClassVlanId include the > value 0: > > If the referenced parameter is not present in the > classifier, the value of this object is reported > as 0. > Well, yours also goes up to (and inclusive) 4095 while bridgemib only goes up to (and inclusive 4094). If zero is not a valid VLAN ID and you want to niclude it as not present, then maybe yours should be renamed to docsQosPktClassVlanIdOrNone or some such Bert > -Greg > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, February 13, 2003 11:44 AM > To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > Eduardo writes: > > > > FYI > > Could be in other places but a starting point. > > > > draft-ietf-bridge-bridgemib-01.txt > > > > VlanId ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The 12-bit VLAN ID used in the VLAN Tag header." > > SYNTAX INTEGER (1..4094) > > > And so... why does yours differ > docsQosPktClassVlanId OBJECT-TYPE > SYNTAX Integer32 (0..4095) > MAX-ACCESS read-only > STATUS current > > I am not claiming that one is better than the other. > But I always wonder why they are different. > Best to try and get in touch with the bridgemib people > > Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Apr 2 11:48:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17605 for ; Wed, 2 Apr 2003 11:48:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32HDEC26169 for ipcdn-archive@odin.ietf.org; Wed, 2 Apr 2003 12:13:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32HD9K26154; Wed, 2 Apr 2003 12:13:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32HCXK26102 for ; Wed, 2 Apr 2003 12:12:33 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17544 for ; Wed, 2 Apr 2003 11:47:42 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h32Go1q9021506; Wed, 2 Apr 2003 09:50:02 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Apr 2003 09:50:01 -0700 Message-ID: Thread-Topic: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID thread-index: AcL5LIayG4k38fhlQkiwWzMd+JDPTgAAa8Xw From: "Eduardo Cardona" To: "Patrick Michael-LZZ007" , "Woundy, Richard" , "IPCDN WG (E-mail)" , "DOCSIS OSS Majordomo List" , "Woundy, Richard" , "IPCDN WG (E-mail)" , "DOCSIS OSS Majordomo List" Cc: "Greg White" , "Michael W. Patrick (E-mail)" , "Murwin William-LWM008" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h32HCXK26103 Subject: [ipcdn] RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Mike, Personally I also believe that, but this is also the land of other IETF,IEEE groups. The same rationale applied to those groups (non-DOCSIS); showing '0' is confusing for them since it is an invalid value according to their spec (802.1Q).. Those guys would like to have in our side a correct 802.1Q interpretation. The new guidelines from the ops ietf group are making slight changes in how MSOs operates DOCS-XXX-MIB vs the new DOCS-XXX-IETF-MIB modules : In general, I do not think current proposed drafts for RFC are the places to have them due time constrains and some drafts have no previous RFCs : SubMgt, BPI2, QOS Different approaches to clarify those "differences" may be added in OSSI spec or a remote option as informational RFC. Eduardo -----Original Message----- From: Patrick Michael-LZZ007 [mailto:Michael.Patrick@motorola.com] Sent: Wednesday, April 02, 2003 8:28 AM To: Eduardo Cardona; Woundy, Richard; IPCDN WG (E-mail); DOCSIS OSS Majordomo List; Woundy, Richard; IPCDN WG (E-mail); DOCSIS OSS Majordomo List Cc: Greg White; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Eduardo, Don't you think it would be confusing to report -1 as "any" for the value when the parameter is omitted? The object is not used for classification in this case, so it doesn't match "any" tagged packet. My whole point in keeping the reporting of the value 0 is to say that we do NOT match "any" tagged VLAN value. -mike -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: Tuesday, April 01, 2003 11:23 AM To: Patrick Michael-LZZ007; Woundy, Richard; IPCDN WG (E-mail); DOCSIS OSS Majordomo List; Patrick Michael-LZZ007; Woundy, Richard; IPCDN WG (E-mail); DOCSIS OSS Majordomo List Cc: Greg White; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID I also believe that the wording description is what is needed, In addition, the current description carries the bit conversion (12 bit) from the RFI TLV encoding/ 16 bit tag 12 MSB bits. Since VLAN ID is just a well understood ID integer value mapped to the 12 MSB, I think that is not needed or the TC VlanIdOrAny will cover that by definition when referencing 802.1x. Or that definition should be in the TC itself. Proposed to remove: "Only the least significant 12 bits of this object's value are valid." To keep the most backward compatibility with existing implementations and MIB/RFI spec balance: - not sure if needed since already included in RFI Appendix C.2.1.7.2- "If this field is omitted, then comparison of the IEEE 802.1Q vlan_id bits for this entry is irrelevant." -> regardless of the MIB reported value. Proposed: ( -1 | 4095) TBD by IETF If the referenced parameter is not present in the classifier, the value of this object is reported as a VlanIdorAny Wildcard value (-1 | 4095.) and ignored when matching the Ethernet frame. Original: docsQosPktClassVlanId OBJECT-TYPE SYNTAX Integer32 (0..4095) MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Q tag header. If this object's value is nonzero, tagged packets must have a VLAN Identifier that matches the value in order to match the rule. Only the least significant 12 bits of this object's value are valid. If the referenced parameter is not present in the classifier, the value of this object is reported as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2" ::= { docsQosPktClassEntry 24 } Proposed: docsQosPktClassVlanId OBJECT-TYPE SYNTAX VlanIdOrAny MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Q tag header. Tagged packets must have a VLAN Identifier that matches the value in order to match the rule. If the referenced parameter is not present in the classifier, the value of this object is reported as the VlanIdorAny wildcard value (-1 | 4095.) and ignored when matching the Ethernet frame. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2" ::= { docsQosPktClassEntry 24 } More clarifications to changes, It is an IETF rule to identify any common object as a whole entity and being normalized to minimize the number of TC used among all IETF Groups. There are some concerns ( not sure how bad would be) for huge Management systems with hundreds of mibs compiled and at the same time hundred of objects with similar behavior using different TCs. Also TCs at some point may have a lot of code behind in operations to follow the their Description rules. For integrators few TC are better. Then, I think the only pendig item is the IETF decision of what is better -1 or 4095 as a valid "wildcard" - IETF- term DOCSIS as you pointed "does not" require wildcarding of the VLAN ID, but not having this parameter in the classifier means ignore it which is a kind of "wildcarding" "orAny" regardless of the mib value. Backward compatibility, Regardless of -1|4905 or 0: As far MSO understand possible side effects in trying to use VLAN ID 0 for a matching classifier, internally all implementations may work fine. The mib difference is noticed by pointing to the old mib DOCS-QOS-MIB or the new one DOCS-QOS-IETF-MIB in the Support systems. I do not think we have other option than be tide to IETF TC if they insist in that. Now, the point in the TC "4095" is should it be -1 or 4095 and it will be an IETF decision where we may be interested. I would think in 4095 as a better "normalized" like an inverse-mask with AND operations, or does any one recognize the mask -1 -1 -1 -1 rather than FF FF FF FF ? But maybe the -1 value is being implemented already in the context of 802.1Q and this group should take the IETF recommendations. Eduardo -----Original Message----- From: Patrick Michael-LZZ007 [mailto:Michael.Patrick@motorola.com] Sent: Tuesday, April 01, 2003 7:56 AM To: 'Woundy, Richard'; IPCDN WG (E-mail); DOCSIS OSS Majordomo List Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID I agree we should modify the wording, but not in order to support an "any" VLAN ID match. The MIB needs to reflect the semantics of the RFI spec. The spec's wording is (from SPI-RFIv1.1-I05): "The value of the field specify [sic] the matching value for the IEEE 802.1Q vlan_id bits." There is no mention that the value must be nonzero in order to match. The assumption must be that a classifier with a 22/23.11.2 parameter value of 0 would match a tagged frame with a VLAN ID of zero. This is contrary to the current -07 mib description, which states: " If this object's value is nonzero, tagged packets must have a VLAN Identifier that matches the value in order to match the rule." In other words, the MIB word requires a nonzero value in order to be matched, which is contrary to the spec. I would propose that we simply remove the wording from the MIB description "If this object's value is nonzero". As for an "any" VLAN encoding, the assumption there is that we need to allow a packet classifier to match any 802.1Q tagged packet, regardless of its VLAN Id value. While this is admittedly useful, I don't see where the RFI spec requires that operation, and I'm not sure that either CMs or CMTSs have implemented it. If I've missed an ECN to this effect, I apologize. Since I'm recommending that we NOT add a "-1" for an "any" VLANid match, I recommend that we keep the current syntax, and NOT use the VlanIdOrAny TC. Does -mike -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Monday, March 31, 2003 9:59 PM To: IPCDN WG (E-mail); DOCSIS OSS (E-mail) Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin William-LWM008 Subject: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Folks, I am concerned about the lack of resolution to this issue of a "default VLAN ID" for the DOCSIS QoS MIB. Besides my concern about using a different VLAN ID definition than other IETF MIBs, my concern centers on this comment from Les Bell of 3Com: >We should not use the value 0 to indicate "any" VLAN, as this may be >used by 802.1D Bridges that support Priority Tagging, but do not >support 802.1Q VLANs. In a later email, as IETF MIB folks suggested using 4095 as the "wildcard" VLAN ID, Les' reaction was: >I have asked for the opinion of the IEEE 802.1 Task Force Chair, Mick >Seaman, on this proposal. He believes that the use of 4095 as a >wildcard VLAN-ID would be okay, but he wants to discuss it formally at >the IEEE 802 meeting in Dallas (week commencing March 9). I will be >attending this meeting. I am going to try to find out the reaction of the IEEE to this proposal. The latest proposed IETF TEXTUAL CONVENTION for a VLAN ID (with wildcard support) is: VlanIdOrAny ::= TEXTUAL CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 1..4094) I cannot find anything in the DOCSIS specifications, outside of the DOCSIS QoS MIB, that uses 0 as a special VLAN ID. -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, February 13, 2003 3:37 PM To: Greg White; Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt Inline > -----Original Message----- > From: Greg White [mailto:g.white@CableLabs.com] > Sent: donderdag 13 februari 2003 20:07 > To: Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > It is important that the range for docsQosPktClassVlanId include the > value 0: > > If the referenced parameter is not present in the > classifier, the value of this object is reported > as 0. > Well, yours also goes up to (and inclusive) 4095 while bridgemib only goes up to (and inclusive 4094). If zero is not a valid VLAN ID and you want to niclude it as not present, then maybe yours should be renamed to docsQosPktClassVlanIdOrNone or some such Bert > -Greg > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, February 13, 2003 11:44 AM > To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > Eduardo writes: > > > > FYI > > Could be in other places but a starting point. > > > > draft-ietf-bridge-bridgemib-01.txt > > > > VlanId ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The 12-bit VLAN ID used in the VLAN Tag header." > > SYNTAX INTEGER (1..4094) > > > And so... why does yours differ > docsQosPktClassVlanId OBJECT-TYPE > SYNTAX Integer32 (0..4095) > MAX-ACCESS read-only > STATUS current > > I am not claiming that one is better than the other. > But I always wonder why they are different. > Best to try and get in touch with the bridgemib people > > Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Apr 2 17:57:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13835 for ; Wed, 2 Apr 2003 17:57:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32NLbP30034 for ipcdn-archive@odin.ietf.org; Wed, 2 Apr 2003 18:21:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NLFK29937; Wed, 2 Apr 2003 18:21:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NKaK29876 for ; Wed, 2 Apr 2003 18:20:36 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13652 for ; Wed, 2 Apr 2003 17:55:38 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by peacock.tci.com (8.12.8/8.12.8) with ESMTP id h32Mw4nu020316; Wed, 2 Apr 2003 15:58:04 -0700 (MST) Received: from 147.191.90.11 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 02 Apr 2003 15:57:59 -0600 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 2 Apr 2003 15:57:13 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056638AC@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Wilson.Sawyer@arrisi.com'" , "Wijnen, Bert (Bert)" cc: ipcdn@ietf.org Subject: RE: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt Date: Wed, 2 Apr 2003 15:57:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1295B57D1563228-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 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: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] Sent: Wednesday, April 02, 2003 9:59 AM To: Wijnen, Bert (Bert) Cc: ipcdn@ietf.org Subject: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt 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: "'Wilson.Sawyer@arrisi.com'" , om> cc: "'bwijnen@lucent.com'" , "'Erik Nordmark (E-mail)'" , "'Ipcdn (E-mail)'" , 04/02/03 09:45 AM "'ipcdn-admin@ietf.org'" , "'Thomas Narten (E-mail)'" Subject: Status - draft-ietf-ipcdn-subscriber-mib-10.txt 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: Wilson.Sawyer@arrisi.com; ipcdn@ietf.org > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); Ipcdn (E-mail); > ipcdn-admin@ietf.org; 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: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > Sent: donderdag 20 februari 2003 20:40 > > To: ipcdn@ietf.org > > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); Ipcdn (E-mail); > > ipcdn-admin@ietf.org; 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)" > > > bwijnen@lucent.com, "Erik Nordmark (E-mail)" > > om> > > , "Thomas Narten (E-mail)" > > > > 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:Erik.Nordmark@sun.com] > > 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 > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Apr 2 18:15:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15102 for ; Wed, 2 Apr 2003 18:15:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32NHLG31396 for ipcdn-archive@odin.ietf.org; Wed, 2 Apr 2003 18:17:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NH1K31374; Wed, 2 Apr 2003 18:17:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NGCK31318 for ; Wed, 2 Apr 2003 18:16:12 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14947 for ; Wed, 2 Apr 2003 18:13:41 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by snowmass.tci.com (8.12.8/8.12.8) with ESMTP id h32NFqdg017202 for ; Wed, 2 Apr 2003 16:16:07 -0700 (MST) Received: from 147.191.89.201 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 02 Apr 2003 16:15:55 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id <2FGWRJMN>; Wed, 2 Apr 2003 16:15:17 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056638AF@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN WG (E-mail)" Date: Wed, 2 Apr 2003 16:15:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1295B0A1766679-02-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] IPCDN meeting minutes from San Francisco Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, Could you review and comment on the following IPCDN meeting minutes from the March IETF meeting by close of business Thursday? Thanks. -- Rich IETF IPCDN Meeting San Francisco, CA USA March 19, 2003 Reported by Greg Nakanishi (gnakanishi@motorola.com) Edited by Rich Woundy (richard_woundy@cable.comcast.com) WG Meeting Summary ------------------ Approximately twelve attendees of the IP over Cable Data Networks WG met at the San Francisco IETF on March 19, 2003. The WG discussed the status of its work items: five drafts for DOCSIS MIBs, three drafts for PacketCable/IPCablecom, and six drafts for CableHome. The results of the February 2003 interim meeting in Louisville, CO were also discussed. Total meeting time was a little more than one hour. The "DOCSIS Subscriber Management MIB" completed MIB doctor review, although the use of DSCP value and mask objects needs to be resolved. The "Application of the IGMP MIB to DOCSIS 1.1" needs to be rewritten with a MIB compliance statement; this draft will be brought back to the WG. Twenty-two submissions for thirteen distinct internet-drafts have been posted since the previous IETF meeting in Atlanta. The WG also launched a website for additional information, . This was the first time the WG used jabber text conferencing during its meeting. There were two remote jabber participants (not counted in the twelve participants above), and a third jabber participant joined after the meeting ended. Interim Meeting --------------- Rich Woundy reviewed the discussion from the February interim meeting. At the interim meeting, eighteen attendees reviewed IPCDN MIBs for about six hours. The BPI+ MIB and DOCSIS QoS MIB were reviewed in depth, four more DOCSIS MIBs were briefly reviewed, the DOCSIS Set-Top Gateway MIB was briefly discussed, and the CableHome MIBs were presented. The minutes have been posted to the IETF and www.ipcdn.org websites. Review of DOCSIS MIBs --------------------- Rich Woundy presented a list of the most current versions of the DOCSIS MIBs. Greg Nakanishi asked for the timeframe(s) to have all of the draft updates as a result of the interim meeting. Jean-Francois Mule responded that the timeframe depended on the draft. There were a number of technical comments on the BPI+ MIB draft -08 at the interim meeting. The BPI+ MIB draft -09 is work-in-progress at the moment. The goal is to post the next draft with all comments resolved prior to June. The Cable Device MIB draft -04 was briefly discussed at the interim meeting, which resulted in the posting of draft -05. The latest draft has significant revisions to the compliance statements (separated for CM and CMTS), has new filtering tables for IPv4/IPv6 filtering, Dscp marking, and IPv4/IPv6 CPE control, and has deleted all VACM extension objects. This draft requires careful WG review. At this point, Rich raised the debate about the use of the DiffServ MIB and its applicability to Cable Device IPv4/IPv6 filtering, and to the packet classification tables in the DOCSIS QoS and Subscriber Management MIBs. Rich found the DiffServ MIB to have powerful features for packet classification, queuing and scheduling, although for adoption into cable might require simplications via MIB compliance statements. One difficulty in adopting the DiffServ MIB is that its Data Path table differentiates between interfaces but not between groups of devices (e.g. cable modems) on a single interface -- unlike the Subscriber Management MIB. An additional issue may be the potential "partial" use of the DiffServ MIB for cable interfaces, but the "complete" use of the DiffServ MIB for other interfaces on a CMTS. The Event Notification MIB draft -03 was briefly discussed at the interim meeting. A timeframe for publication of draft -04 needs to be determined, and the draft requires careful WG review. The DOCSIS 2.0 RFI MIB draft -05 was briefly discussed at the interim meeting, which resulted in the posting of draft -06. The name of the MIB module needs to be changed from DOCS-IETF-RFI-MIB back to DOCS-IF-MIB (the slide incorrectly indicated it should be changed to DOCS-RFI-MIB); both this draft and the cable device MIB draft need to retain the module names of RFC 2670 and RFC 2669, respectively. This draft requires careful WG review. Minnie Lu raised an issue about the RFI MIB objects docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets, asking why they do not include packets from DOCSIS 1.1 or 2.0 modems after registration -- according to the DOCSIS QoS MIB. This issue will be (re-)raised and discussed on the mailing list. The DOCSIS QoS MIB draft -07 was discussed in-depth at the interim meeting, which resulted in the posting of draft -08. One remaining issue is the MIB's use of IP ToS instead of DSCP. Rich's opinion was that the MIB should reflect what is in the DOCSIS specifications, and in the case of packet classification for DOCSIS QoS, DOCSIS clearly uses the older notion of the IP ToS byte. The DOCSIS Subscriber Management MIB draft -08 was briefly discussed at the interim meeting, where Bert Wijnen indicated his MIB doctor approval. However, two draft revisions were made after the interim meeting to resolve issues raised in different MIB reviews. Draft -09 changed the module name from DOCS-SUBMGT-MIB to DOCS-IETF-SUBMGT-MIB, to reduce potential confusion between the CableLabs and IETF versions. Draft -10 replaced the TosValue and TosMask objects with DscpValue and DscpMask objects. The current controversy is whether to keep the DscpMask object, over the objections of the IETF DiffServ WG, or just drop this new object. Rich led a discussion comparing the progress of the DiffServ WG in parallel with the development of DOCSIS 1.1 and the IPCDN WG. DSCP is replacing IP ToS in the Cable Device and Subscriber Management MIBs; the DOCSIS QoS MIB is retaining the concept of the IP ToS byte. In the meantime, folks in CableLabs are looking at how the DOCSIS protocols and specifications can be made DiffServ-friendly. Greg Nakanishi asked which operators are using DiffServ today. Cox appears to be a key cable operator using DiffServ. Someone in the meeting asked what happens if the DscpMask object is dropped, and what are the impacts to the underlying DOCSIS layer two protocols. Rich replied that the WG co-chairs are going back to the operators to understand how they have been using DiffServ, and whether dropping the DscpMask object would cause operational difficulties. Review of PacketCable/IPCablecom MIBs ------------------------------------- Jean-Francois Mule reviewed the progress on the PacketCable/IPCablecom MIBs. Jean-Francois pointed out that he and Rich are seeing the same mistakes and issues in multiple MIBs under review of the IPCDN WG. The chairs may start asking for peer reviews on draft MIBs within our WG; that is, authors may be requested to review other authors' MIBs. There were a number of technical and editorial comments reviewed for the PacketCable/IPCablecom MTA MIB, based on email sent to the mailing list. One issue is the use of a "TFTP URL" for downloading an MTA configuration file -- the IETF draft defining the TFTP URI scheme has been queued for AD approval for almost a year, presumably due to the lack of adequate security in the TFTP protocol. One participant suggested that we don't expose the fact that we are using TFTP for configuration file downloads, to avoid the IETF controversy about using TFTP. Similarly, the WG reviewed comments for the PacketCable/IPCablecom Signaling MIB, based on another email sent to the mailing list. One issue is that AVT profiles are defined in RFC 1890 (and the recent internet-draft update draft-ietf-avt-profile-new-13.txt), but this MIB uses its own naming convention. Another issue is the residual references to the DCS protocol (SIP-based), even though PacketCable/IPCablecom uses the NCS protocol (MGCP-based). A third issue is a needed clarification as to when the MTA performs DNS resolution, e.g. at boot-time, or upon receipt of an RSIP (ReStartInProgress) NCS message. This third issue prompted a number of questions and comments on DNS responses. Rich pointed out that some CMS vendors might support server cluster failover by returning multiple IP addresses in a single DNS "A" resource record; the presence of an IP address in the "A" record might imply that the CMS believes that the server with that IP address is alive, and the ordering of IP addresses in the "A" record might indicate relative server processing load (lighter-loaded servers are listed before heavier -loaded servers). [Editor's note: The original slides included the following comment on the Signaling MIB: "Use InetAddress dns type for pktcNcsEndPntConfigCallAgentId". This comment was removed, because the CallAgentId as defined by NCS/MGCP includes more than the DNS FQDN, e.g. "ca@ca.company.com".] Finally, the WG reviewed comments for the PacketCable/IPCablecom Management Event MIB. The InetAddress objects in this MIB must link to the appropriate InetAddressType objects (the slides incorrectly indicated the opposite linkage, from InetAddressType objects to InetAddress objects). Another issue is the lack of alignment of logging severity levels between the Management Event MIB and the SYSLOG MIB. The consensus of the meeting attendees is to align PacketCable/IPCablecom event logging severity levels with DOCSIS/CableHome event logging severity levels, which are already aligned with the SYSLOG MIB. Azlina volunteered to review the Management Event MIB; other volunteers are sought to ensure quality MIB reviews in the WG. Greg Nakanishi asked whether all PacketCable/IPCablecom MIB names should be changed using the same naming convention adopted for the DOCSIS MIBs, to prevent confusion between CableLabs and IETF versions. The attendees and co-chairs agreed with this proposal. This implies the following MIB module name changes: PKTC-IETF-MTA-MIB for the MTA MIB, PKTC-IETF-SIG-MIB for the Signaling MIB, and PKTC-IETF-EVENT-MIB for the Event Management MIB. The expectation is that the PacketCable/IPCablecom MIBs will be revised in the next month or so after the San Francisco IETF meeting (target of mid-April). The co-chairs will want to issue WG last-calls as soon as the MIBs are updated and ready for review. Review of CableHome MIBs ------------------------ New co-authors have signed up to edit and review the CableHome MIBs. The authors represent CableLabs, YAS corporation, and four CableHome vendors (Ashley Laurent, Linksys, Motorola, and TI). As a result, the WG co-chairs believe that the IPCDN WG should accept the CableHome MIBs as part of the IPCDN charter. There is some overlap between the DHCPv4 Server MIB and the CableHome Gateway Configuration MIB. The DHCPv4 Server MIB has been recently revised, and as soon as it reaches WG last call in the DHC WG, the appropriate CableHome authors will need to resolve the overlap. No objections to accepting the CableHome MIBs were received from the IPCDN mailing list, nor from the IETF meeting participants. The co- chairs will add them to the WG charter. Miscellaneous Items ------------------- There was an expectation that the IPCDN WG would discuss the DOCSIS Set-Top Gateway (DSG) MIB at the San Francisco IETF meeting. This agenda item was cancelled due to lack of preparation by interested parties. By default, the WG is deferring any decision about whether to accept this MIB as one of its work items. The chairs reminded the IPCDN authors that they are insisting on more frequent draft updates than in the past. They are also requesting that participants review the MIBs of this WG -- in addition to a new request for MIB authors to participate in peer reviews of each others' work. Greg White (jabber participant) requested a timeline for getting the DOCSIS MIBs from internet-draft status to RFC, for coordination with CableLabs standardization efforts. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Apr 2 18:41:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15883 for ; Wed, 2 Apr 2003 18:41:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32Nh4k01396 for ipcdn-archive@odin.ietf.org; Wed, 2 Apr 2003 18:43:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32Nh2K01337; Wed, 2 Apr 2003 18:43:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32Ng5K01262 for ; Wed, 2 Apr 2003 18:42:05 -0500 Received: from mms2.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15838 for ; Wed, 2 Apr 2003 18:39:35 -0500 (EST) Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.0)); Wed, 02 Apr 2003 15:38:56 -0700 Received: from nt-sjce-0701.sv.broadcom.com ( nt-sjce-0701.sj.broadcom.com [10.19.192.66]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA05704; Wed, 2 Apr 2003 15:41:41 -0800 (PST) Received: by nt-sjce-0701.sv.broadcom.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 2 Apr 2003 15:40:00 -0800 Received: from broadcom.com (dhcp-10-9-253-46.broadcom.com [10.9.253.46] ) by nt-sjcb-0501.sv.broadcom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GWFCY488; Wed, 2 Apr 2003 15:41:44 -0800 From: "Stephen Palm" To: "Woundy, Richard" cc: "IPCDN WG (E-mail)" Message-ID: <3E8B73E4.2010306@broadcom.com> Date: Wed, 02 Apr 2003 15:36:04 -0800 User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [ipcdn] IPCDN meeting minutes from San Francisco References: <6732623D2548D61193C90002A5C88DCC056638AF@entmaexch02.broadband.att.com> X-WSS-ID: 1295AB1A1718561-01-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Woundy, Richard wrote: > Review of CableHome MIBs > ------------------------ [...] > No objections to accepting the CableHome MIBs were received from the > IPCDN mailing list, nor from the IETF meeting participants. The co- > chairs will add them to the WG charter. Some of the CableHome MIBs may point to material that might not be publically available. In that light, what is the scope and timeline for CableHome MIBs? regards, kiwin -- Stephen [kiwin] Palm Ph.D. E: palm@kiwin.com Principal Engineer T: +1-949-926-PALM Epigram/Broadcom Home Networking Division F: +1-530-325-9798 Irvine, California W: http://www.kiwin.com Secondary email accounts: palm@itu.ch palm@broadcom.com s.palm@ieee.org spalm@cs.cmu.edu palm@ics.t.u-tokyo.ac.jp _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Apr 3 16:50:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15921 for ; Thu, 3 Apr 2003 16:50:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Lr2A01966 for ipcdn-archive@odin.ietf.org; Thu, 3 Apr 2003 16:53:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LqJK01943; Thu, 3 Apr 2003 16:52:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LpuK01909 for ; Thu, 3 Apr 2003 16:51:56 -0500 Received: from mms1.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15883 for ; Thu, 3 Apr 2003 16:48:58 -0500 (EST) Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.0)); Thu, 03 Apr 2003 13:51:08 -0700 Received: from nt-rmna-exch.ca.broadcom.com ( nt-rmna-exch.ca.broadcom.com [10.136.192.25]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id NAA03375 for ; Thu, 3 Apr 2003 13:51:04 -0800 (PST) Received: by nt-rmna-exch.ca.broadcom.com with Internet Mail Service ( 5.5.2653.19) id ; Thu, 3 Apr 2003 13:51:20 -0800 Message-ID: <725301F4D1E9D411A69F0002A507428E01C0DB50@nt-rmna-exch.ca.broadcom.com> From: "Eugene Nechamkin" To: "IPCDN WG (E-mail)" Date: Thu, 3 Apr 2003 13:51:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12927346749273-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] DEFVAL Clause Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit While reviewing the PacketCable MTA MIB IETF draft, there was a discssion of the DEFVAL Clause. As SMIv2 states: It is also permitted to use it for scalar objects dynamically created by an agent, or for columnar objects of a read-write table dynamically created by an agent. it's permitted to use DEFVAL clause for dynamic scalar MIB objects. In many occasions, there is a need to be able to define default values for the static scalar objects also. I do not seem to be able to find any explicit permissions or prohibitions on doing that. Any pointers in this direction will be appreciated. Thanks, Eugene. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Apr 3 18:45:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20463 for ; Thu, 3 Apr 2003 18:45:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33NmOF12126 for ipcdn-archive@odin.ietf.org; Thu, 3 Apr 2003 18:48:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33Nm7K12116; Thu, 3 Apr 2003 18:48:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33NleK12095 for ; Thu, 3 Apr 2003 18:47:40 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20425 for ; Thu, 3 Apr 2003 18:44:39 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.8/8.12.8) with ESMTP id h33Nl0df018663; Thu, 3 Apr 2003 16:47:01 -0700 (MST) Received: from 147.191.90.11 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Thu, 03 Apr 2003 16:46:53 -0600 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Thu, 3 Apr 2003 16:46:06 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056638C6@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Stephen Palm'" cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] IPCDN meeting minutes from San Francisco Date: Thu, 3 Apr 2003 16:46:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 129218671711746-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The publication of the CableHome MIBs by the IETF will be well after the expected publication of the CableHome 1.1 specifications this month. -- Rich -----Original Message----- From: Stephen Palm [mailto:palm@broadcom.com] Sent: Wednesday, April 02, 2003 6:36 PM To: Woundy, Richard Cc: IPCDN WG (E-mail) Subject: Re: [ipcdn] IPCDN meeting minutes from San Francisco Woundy, Richard wrote: > Review of CableHome MIBs > ------------------------ [...] > No objections to accepting the CableHome MIBs were received from the > IPCDN mailing list, nor from the IETF meeting participants. The co- > chairs will add them to the WG charter. Some of the CableHome MIBs may point to material that might not be publically available. In that light, what is the scope and timeline for CableHome MIBs? regards, kiwin -- Stephen [kiwin] Palm Ph.D. E: palm@kiwin.com Principal Engineer T: +1-949-926-PALM Epigram/Broadcom Home Networking Division F: +1-530-325-9798 Irvine, California W: http://www.kiwin.com Secondary email accounts: palm@itu.ch palm@broadcom.com s.palm@ieee.org spalm@cs.cmu.edu palm@ics.t.u-tokyo.ac.jp _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Apr 4 08:12:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20955 for ; Fri, 4 Apr 2003 08:12:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34DF9b14548 for ipcdn-archive@odin.ietf.org; Fri, 4 Apr 2003 08:15:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DErK14530; Fri, 4 Apr 2003 08:14:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DDRK14463 for ; Fri, 4 Apr 2003 08:13:27 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20927 for ; Fri, 4 Apr 2003 08:10:05 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34DCKU07077 for ; Fri, 4 Apr 2003 08:12:21 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 15:12:19 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501484118@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Woundy, Richard" , "'Wilson.Sawyer@arrisi.com'" , "Wijnen, Bert (Bert)" Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt Date: Fri, 4 Apr 2003 15:12:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , 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 > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: donderdag 3 april 2003 0:58 > To: 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert) > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] Re: Status - > draft-ietf-ipcdn-subscriber-mib-10.txt > > > 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: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > Sent: Wednesday, April 02, 2003 9:59 AM > To: Wijnen, Bert (Bert) > Cc: ipcdn@ietf.org > Subject: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt > > > > 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: > "'Wilson.Sawyer@arrisi.com'" , > > > om> cc: > "'bwijnen@lucent.com'" , "'Erik Nordmark > (E-mail)'" > > , > "'Ipcdn (E-mail)'" , > 04/02/03 09:45 AM > "'ipcdn-admin@ietf.org'" > , "'Thomas Narten (E-mail)'" > > > Subject: Status - > draft-ietf-ipcdn-subscriber-mib-10.txt > > > > > > > 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: Wilson.Sawyer@arrisi.com; ipcdn@ietf.org > > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); Ipcdn (E-mail); > > ipcdn-admin@ietf.org; 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: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > > Sent: donderdag 20 februari 2003 20:40 > > > To: ipcdn@ietf.org > > > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); Ipcdn (E-mail); > > > ipcdn-admin@ietf.org; 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)" > > > > > bwijnen@lucent.com, "Erik Nordmark (E-mail)" > > > om> > > > , "Thomas Narten (E-mail)" > > > > > > 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:Erik.Nordmark@sun.com] > > > 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 > > > IPCDN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Apr 4 09:11:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22408 for ; Fri, 4 Apr 2003 09:11:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34EE4J18773 for ipcdn-archive@odin.ietf.org; Fri, 4 Apr 2003 09:14:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34EE3K18762; Fri, 4 Apr 2003 09:14:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34EDMK18716 for ; Fri, 4 Apr 2003 09:13:22 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22377 for ; Fri, 4 Apr 2003 09:10:04 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by snowmass.tci.com (8.12.8/8.12.8) with ESMTP id h34EBvdi001887; Fri, 4 Apr 2003 07:12:32 -0700 (MST) Received: from 147.191.89.203 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 04 Apr 2003 07:12:24 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 4 Apr 2003 07:13:50 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056638CA@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Eugene Nechamkin'" cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] DEFVAL Clause Date: Fri, 4 Apr 2003 07:12:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12934D42972674-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eugene, I forwarded your email question to a MIB doctor, that has previously relayed your question to other MIB doctors at last month's IETF meeting in San Francisco (but had forgotten to get back to me). Here is his reply: >Ahhh, yes -- I did ask about that. They could not see any reason that >you could not or should not use a DEFVAL on a scalar. Go for it! So I stand corrected! -- Rich -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Thursday, April 03, 2003 4:51 PM To: IPCDN WG (E-mail) Subject: [ipcdn] DEFVAL Clause While reviewing the PacketCable MTA MIB IETF draft, there was a discssion of the DEFVAL Clause. As SMIv2 states: It is also permitted to use it for scalar objects dynamically created by an agent, or for columnar objects of a read-write table dynamically created by an agent. it's permitted to use DEFVAL clause for dynamic scalar MIB objects. In many occasions, there is a need to be able to define default values for the static scalar objects also. I do not seem to be able to find any explicit permissions or prohibitions on doing that. Any pointers in this direction will be appreciated. Thanks, Eugene. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Apr 4 10:48:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27068 for ; Fri, 4 Apr 2003 10:48:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34FpLS26282 for ipcdn-archive@odin.ietf.org; Fri, 4 Apr 2003 10:51:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Fow826214; Fri, 4 Apr 2003 10:50:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34FgW825718 for ; Fri, 4 Apr 2003 10:42:32 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26703 for ; Fri, 4 Apr 2003 10:39:11 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by peacock.tci.com (8.12.8/8.12.8) with ESMTP id h34Ffdnu002991; Fri, 4 Apr 2003 08:41:39 -0700 (MST) Received: from 147.191.89.201 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 04 Apr 2003 08:41:33 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id <2FGWVN7H>; Fri, 4 Apr 2003 08:40:54 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056638CC@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Wijnen, Bert (Bert)'" , "'Wilson.Sawyer@arrisi.com'" cc: ipcdn@ietf.org Subject: RE: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt Date: Fri, 4 Apr 2003 08:41:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12937827985286-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 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:bwijnen@lucent.com] Sent: Friday, April 04, 2003 8:12 AM To: Woundy, Richard; 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert) Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt 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 > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: donderdag 3 april 2003 0:58 > To: 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert) > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] Re: Status - > draft-ietf-ipcdn-subscriber-mib-10.txt > > > 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: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > Sent: Wednesday, April 02, 2003 9:59 AM > To: Wijnen, Bert (Bert) > Cc: ipcdn@ietf.org > Subject: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt > > > > 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: > "'Wilson.Sawyer@arrisi.com'" , > > > om> cc: > "'bwijnen@lucent.com'" , "'Erik Nordmark > (E-mail)'" > > , > "'Ipcdn (E-mail)'" , > 04/02/03 09:45 AM > "'ipcdn-admin@ietf.org'" > , "'Thomas Narten (E-mail)'" > > > Subject: Status - > draft-ietf-ipcdn-subscriber-mib-10.txt > > > > > > > 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: Wilson.Sawyer@arrisi.com; ipcdn@ietf.org > > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); Ipcdn (E-mail); > > ipcdn-admin@ietf.org; 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: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > > Sent: donderdag 20 februari 2003 20:40 > > > To: ipcdn@ietf.org > > > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); Ipcdn (E-mail); > > > ipcdn-admin@ietf.org; 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)" > > > > > bwijnen@lucent.com, "Erik Nordmark (E-mail)" > > > om> > > > , "Thomas Narten (E-mail)" > > > > > > 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:Erik.Nordmark@sun.com] > > > 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 > > > IPCDN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > > > > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Apr 4 10:50:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27186 for ; Fri, 4 Apr 2003 10:50:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34FrEY26497 for ipcdn-archive@odin.ietf.org; Fri, 4 Apr 2003 10:53:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Fqu826448; Fri, 4 Apr 2003 10:52:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Fn6826071 for ; Fri, 4 Apr 2003 10:49:06 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26960 for ; Fri, 4 Apr 2003 10:45:46 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34FmEO26424 for ; Fri, 4 Apr 2003 10:48:15 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 17:48:13 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501484184@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Woundy, Richard" Cc: "Ipcdn (E-mail)" Date: Fri, 4 Apr 2003 17:48:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [ipcdn] FW: snmpconf Reusability of Diffserv MIB Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Thanks, Bert -----Original Message----- From: Harrie Hazewinkel [mailto:harrie@jumpy.it] Sent: vrijdag 4 april 2003 15:55 To: snmpconf@snmp.com Cc: Harrie Hazewinkel; Wilson.Sawyer@arrisi.com Subject: Re: snmpconf Reusability of Diffserv MIB Hi, I have not check the subscriber-mib, but some question are in line. Not saying I am an expert in all areas, therefore, some of it below may sound dumb. But in idea I believe it is quit similar. Hope this helps, Harrie On Friday, April 4, 2003, at 03:12 PM, Wijnen, Bert (Bert) wrote: > So I wonder if document draft-ietf-snmpconf-diffpolicy-05.txt > would be of help in this case. I have not checked the details > yet. > > Thanks, > Bert > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: donderdag 3 april 2003 0:58 > To: 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert) > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] Re: Status - > draft-ietf-ipcdn-subscriber-mib-10.txt > > > 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. I do not understand what you mean by 'initial' table. In the diffserv-mib it is not needed to have a classifier as the first datapath element. > > 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). 'typical' I would say possibility. > > 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. A classifier in diffserv is also a set of rows in a table. So far I believe it is all similar in concept. Just a question, are only 4 filter-groups possible?? In theory, this is also possible in the diffserv-mib. The diffpolicy MIB is then a possibility to use in order to define/register such a filter or complete datapath. > 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. I am not getting this. Do you say that since the DiffServ MIB does not group the classifier table it is not applicable in the subscriber mib?? If I understand it, the docsSubMgtCmFilterTable has just different parameters to get to a first classifier/filter, right?? If so, I do not see a major difference is usage/concept, except that the docsSubMgtCmFilterTable points to an filter defined in the docsSubMgtPktFilterTable (and is simply more restrictive). This as opposite that in diffserv a filter is not needed to be first. Correct me if I am wrong, but is the intention of the diffserv-mib is that a filter for a specific interface and direction and you want to have a single filter defined in the docsSubMgtPktFilterTable that is reused for all the subscribers. > 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. The more generic usage was to allow configuration templates. For that reason also many datapath element tables are not directly associated with an interface nad it direction. If I understand you correctly you want to have filters that are used, but not tightly coupled to en entities managed in the subscriber-mib. The diffpolicy-mib provides something likem this. As you may note, in the diffserv-mib also datapath elements defined in the various tables do not have to be in operational use. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Apr 4 12:09:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29465 for ; Fri, 4 Apr 2003 12:09:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34HCTA32706 for ipcdn-archive@odin.ietf.org; Fri, 4 Apr 2003 12:12:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HCE832636; Fri, 4 Apr 2003 12:12:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HAJ832359 for ; Fri, 4 Apr 2003 12:10:19 -0500 Received: from mms1.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29390 for ; Fri, 4 Apr 2003 12:06:57 -0500 (EST) Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.2)); Fri, 04 Apr 2003 09:09:09 -0700 Received: from nt-rmna-exch.ca.broadcom.com ( nt-rmna-exch.ca.broadcom.com [10.136.192.25]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id JAA11812; Fri, 4 Apr 2003 09:09:05 -0800 (PST) Received: by nt-rmna-exch.ca.broadcom.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 4 Apr 2003 09:09:21 -0800 Message-ID: <725301F4D1E9D411A69F0002A507428E01C0DB60@nt-rmna-exch.ca.broadcom.com> From: "Eugene Nechamkin" To: "'Woundy, Richard'" cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] DEFVAL Clause Date: Fri, 4 Apr 2003 09:09:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 129363BF62932-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rich, We are using DEFVAL clause in numerous occasions in the PacketCable MIBs, so this is really helpful. Thanks for the clarification. Eugene. -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Friday, April 04, 2003 6:12 AM To: Eugene Nechamkin Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] DEFVAL Clause Eugene, I forwarded your email question to a MIB doctor, that has previously relayed your question to other MIB doctors at last month's IETF meeting in San Francisco (but had forgotten to get back to me). Here is his reply: >Ahhh, yes -- I did ask about that. They could not see any reason that >you could not or should not use a DEFVAL on a scalar. Go for it! So I stand corrected! -- Rich -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Thursday, April 03, 2003 4:51 PM To: IPCDN WG (E-mail) Subject: [ipcdn] DEFVAL Clause While reviewing the PacketCable MTA MIB IETF draft, there was a discssion of the DEFVAL Clause. As SMIv2 states: It is also permitted to use it for scalar objects dynamically created by an agent, or for columnar objects of a read-write table dynamically created by an agent. it's permitted to use DEFVAL clause for dynamic scalar MIB objects. In many occasions, there is a need to be able to define default values for the static scalar objects also. I do not seem to be able to find any explicit permissions or prohibitions on doing that. Any pointers in this direction will be appreciated. Thanks, Eugene. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Apr 4 13:06:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01467 for ; Fri, 4 Apr 2003 13:06:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34I9Po05170 for ipcdn-archive@odin.ietf.org; Fri, 4 Apr 2003 13:09:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34I98805145; Fri, 4 Apr 2003 13:09:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34I86805097 for ; Fri, 4 Apr 2003 13:08:06 -0500 Received: from com21.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01405 for ; Fri, 4 Apr 2003 13:04:43 -0500 (EST) Received: from ianw (dhcp-250-68.ie.com21.com [192.168.250.68]) by com21.ie (8.11.0/8.11.0) with SMTP id h34I7an25793 for ; Fri, 4 Apr 2003 19:07:36 +0100 (BST) From: "ian wheelock" To: Date: Fri, 4 Apr 2003 19:06:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [ipcdn] Aging out docsSubMgtCpeIpTable entries Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi can entries in the docsSubMgtCpeIpTable ever be 'aged' out ? the draft states "The learning mechanism is not defined by this document.", it does not state anything about the duration an entry is retained in the table or how/if "aging" should be part of the table operation. the draft also states "In particular, this MIB provides two capabilities: first, to limit the IP addresses behind a modem, and, second, to provide protocol filtering to and from a modem." does the first capability suggest 1/ limiting the 'number' of ip addresses, OR 2/ limiting the 'specific' ip addresses (learned on a first-come basis, and once learned will NEVER be removed unless the table is reset) ? if it is suggesting 1, then would 'aging' be acceptable ? 'aging' would enable new/different IP addresses to replace old/aged out 'learned' IP addresses, while continuing to support the limiting of the number of IP addresses to the configured maximum (docsSubMgtCpeControlMaxCpeIp). Supporting aging would require an additional mib variable to be able to configure/read the aging interval. i realise that there is a 'reset' option to clear out all 'learned' addresses. Ian _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Apr 4 13:21:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01860 for ; Fri, 4 Apr 2003 13:21:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34IOO805909 for ipcdn-archive@odin.ietf.org; Fri, 4 Apr 2003 13:24:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34IO9805895; Fri, 4 Apr 2003 13:24:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34IN6805849 for ; Fri, 4 Apr 2003 13:23:06 -0500 Received: from titan.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01793 for ; Fri, 4 Apr 2003 13:19:42 -0500 (EST) From: Wilson.Sawyer@arrisi.com Subject: Re: [ipcdn] Aging out docsSubMgtCpeIpTable entries To: "ian wheelock" Cc: ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Fri, 4 Apr 2003 13:21:49 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 04/04/2003 01:21:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , The short answer is 'yes', entries can be aged out. We avoided specifying the learning mechanism because we wanted to leave it open to a variety of mechanisms likely to already be part of the forwarding process of CMTSs - for example, the ARP cache, bridge learning, DHCP gleaning, etc. I'd think that the same rationale would apply to aging - whatever replacement mechanisms and aging are part of CMTS forwarding table maintenance could also be applied to the CpeIpTable. The goal of the CpeIpTable is to prevent address spoofing. Any aging/replacement process that is reasonably long duration (minutes) should fulfill this purpose. Keep in mind, too, that the subscriber can always clear the table by re-registering the modem. - Wilson Sawyer "ian wheelock" To: Sent by: cc: ipcdn-admin@ietf. Subject: [ipcdn] Aging out docsSubMgtCpeIpTable entries org 04/04/03 01:06 PM Hi can entries in the docsSubMgtCpeIpTable ever be 'aged' out ? the draft states "The learning mechanism is not defined by this document.", it does not state anything about the duration an entry is retained in the table or how/if "aging" should be part of the table operation. the draft also states "In particular, this MIB provides two capabilities: first, to limit the IP addresses behind a modem, and, second, to provide protocol filtering to and from a modem." does the first capability suggest 1/ limiting the 'number' of ip addresses, OR 2/ limiting the 'specific' ip addresses (learned on a first-come basis, and once learned will NEVER be removed unless the table is reset) ? if it is suggesting 1, then would 'aging' be acceptable ? 'aging' would enable new/different IP addresses to replace old/aged out 'learned' IP addresses, while continuing to support the limiting of the number of IP addresses to the configured maximum (docsSubMgtCpeControlMaxCpeIp). Supporting aging would require an additional mib variable to be able to configure/read the aging interval. i realise that there is a 'reset' option to clear out all 'learned' addresses. Ian _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Apr 4 14:25:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03798 for ; Fri, 4 Apr 2003 14:25:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34JSRA10767 for ipcdn-archive@odin.ietf.org; Fri, 4 Apr 2003 14:28:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34JS7810740; Fri, 4 Apr 2003 14:28:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34JRD810685 for ; Fri, 4 Apr 2003 14:27:13 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03739 for ; Fri, 4 Apr 2003 14:23:49 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by snowmass.tci.com (8.12.8/8.12.8) with ESMTP id h34JQCdf029534; Fri, 4 Apr 2003 12:26:12 -0700 (MST) Received: from 147.191.90.10 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 04 Apr 2003 12:26:04 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 4 Apr 2003 12:24:19 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056638DA@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Wilson.Sawyer@arrisi.com'" , "ian wheelock" cc: ipcdn@ietf.org Subject: RE: [ipcdn] Aging out docsSubMgtCpeIpTable entries Date: Fri, 4 Apr 2003 12:25:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 129303C61026926-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Consider the following example of CMTS management of the CPE entries. If a particular CPE with IP address 24.1.1.1 is renumbered (via DHCP) to IP address 24.2.2.2, then it makes a lot of sense for the CMTS to replace the 24.1.1.1 entry with a 24.2.2.2 entry in the CPE table. The example above shows a key motivation of why I don't see value in an explicit "aging timer" MIB object. The CPE entry invalidation may be based on DHCP gleaning by the CMTS -- and the DHCP messages are driven by timers in the DHCP client (CPE) and DHCP server, not the CMTS. -- Rich -----Original Message----- From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] Sent: Friday, April 04, 2003 1:22 PM To: ian wheelock Cc: ipcdn@ietf.org Subject: Re: [ipcdn] Aging out docsSubMgtCpeIpTable entries The short answer is 'yes', entries can be aged out. We avoided specifying the learning mechanism because we wanted to leave it open to a variety of mechanisms likely to already be part of the forwarding process of CMTSs - for example, the ARP cache, bridge learning, DHCP gleaning, etc. I'd think that the same rationale would apply to aging - whatever replacement mechanisms and aging are part of CMTS forwarding table maintenance could also be applied to the CpeIpTable. The goal of the CpeIpTable is to prevent address spoofing. Any aging/replacement process that is reasonably long duration (minutes) should fulfill this purpose. Keep in mind, too, that the subscriber can always clear the table by re-registering the modem. - Wilson Sawyer "ian wheelock" To: Sent by: cc: ipcdn-admin@ietf. Subject: [ipcdn] Aging out docsSubMgtCpeIpTable entries org 04/04/03 01:06 PM Hi can entries in the docsSubMgtCpeIpTable ever be 'aged' out ? the draft states "The learning mechanism is not defined by this document.", it does not state anything about the duration an entry is retained in the table or how/if "aging" should be part of the table operation. the draft also states "In particular, this MIB provides two capabilities: first, to limit the IP addresses behind a modem, and, second, to provide protocol filtering to and from a modem." does the first capability suggest 1/ limiting the 'number' of ip addresses, OR 2/ limiting the 'specific' ip addresses (learned on a first-come basis, and once learned will NEVER be removed unless the table is reset) ? if it is suggesting 1, then would 'aging' be acceptable ? 'aging' would enable new/different IP addresses to replace old/aged out 'learned' IP addresses, while continuing to support the limiting of the number of IP addresses to the configured maximum (docsSubMgtCpeControlMaxCpeIp). Supporting aging would require an additional mib variable to be able to configure/read the aging interval. i realise that there is a 'reset' option to clear out all 'learned' addresses. Ian _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Apr 21 10:58:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18768 for ; Mon, 21 Apr 2003 10:58:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3LF96W04316 for ipcdn-archive@odin.ietf.org; Mon, 21 Apr 2003 11:09:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LF8b804294; Mon, 21 Apr 2003 11:08:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LF7p804260 for ; Mon, 21 Apr 2003 11:07:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18739 for ; Mon, 21 Apr 2003 10:56:15 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197ckf-0000ls-00 for ipcdn@ietf.org; Mon, 21 Apr 2003 10:58:37 -0400 Received: from coral.tci.com ([198.178.8.81] helo=peacock.tci.com) by ietf-mx with esmtp (Exim 4.12) id 197cke-0000lo-00 for ipcdn@ietf.org; Mon, 21 Apr 2003 10:58:36 -0400 Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by peacock.tci.com (8.12.8/8.12.8) with ESMTP id h3LEwOnu016240; Mon, 21 Apr 2003 08:58:24 -0600 (MDT) Received: from 147.191.89.201 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Mon, 21 Apr 2003 08:58:18 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id <2FGX49S9>; Mon, 21 Apr 2003 08:57:36 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC05663984@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Stephen Palm'" cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] IPCDN meeting minutes from San Francisco Date: Mon, 21 Apr 2003 08:58:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12BAD880640186-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stephen, That *was* a very good question. But that material (CableHome 1.1 and the CableHome QoS MIB) is now publically available on: . Now we should be able to tackle the CableHome drafts full-force! -- Rich -----Original Message----- From: Stephen Palm [mailto:palm@broadcom.com] Sent: Wednesday, April 02, 2003 6:36 PM To: Woundy, Richard Cc: IPCDN WG (E-mail) Subject: Re: [ipcdn] IPCDN meeting minutes from San Francisco Woundy, Richard wrote: > Review of CableHome MIBs > ------------------------ [...] > No objections to accepting the CableHome MIBs were received from the > IPCDN mailing list, nor from the IETF meeting participants. The co- > chairs will add them to the WG charter. Some of the CableHome MIBs may point to material that might not be publically available. In that light, what is the scope and timeline for CableHome MIBs? regards, kiwin -- Stephen [kiwin] Palm Ph.D. E: palm@kiwin.com Principal Engineer T: +1-949-926-PALM Epigram/Broadcom Home Networking Division F: +1-530-325-9798 Irvine, California W: http://www.kiwin.com Secondary email accounts: palm@itu.ch palm@broadcom.com s.palm@ieee.org spalm@cs.cmu.edu palm@ics.t.u-tokyo.ac.jp _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Apr 21 13:26:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23068 for ; Mon, 21 Apr 2003 13:26:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3LHbJw14106 for ipcdn-archive@odin.ietf.org; Mon, 21 Apr 2003 13:37:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LHb2813612; Mon, 21 Apr 2003 13:37:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LHHu812904 for ; Mon, 21 Apr 2003 13:17:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22500 for ; Mon, 21 Apr 2003 13:06:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197emW-0001aW-00 for ipcdn@ietf.org; Mon, 21 Apr 2003 13:08:40 -0400 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 197emV-0001aT-00 for ipcdn@ietf.org; Mon, 21 Apr 2003 13:08:39 -0400 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS3 SMTP Relay (MMS v5.5.2)); Mon, 21 Apr 2003 10:08:43 -0700 Received: from nt-sjce-0701.sv.broadcom.com ( nt-sjce-0701.sj.broadcom.com [10.19.192.66]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA03795; Mon, 21 Apr 2003 10:08:35 -0700 (PDT) Received: by nt-sjce-0701.sv.broadcom.com with Internet Mail Service ( 5.5.2653.19) id <2PVKP05D>; Mon, 21 Apr 2003 10:06:52 -0700 Received: from broadcom.com (dhcp-2-143-56.broadcom.com [10.2.143.56]) by nt-sjcb-0501.sv.broadcom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2PVKSDQ8; Mon, 21 Apr 2003 10:08: 49 -0700 From: "Stephen Palm" To: "Woundy, Richard" cc: "IPCDN WG (E-mail)" Message-ID: <3EA4258B.7010204@broadcom.com> Date: Mon, 21 Apr 2003 10:08:27 -0700 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [ipcdn] IPCDN meeting minutes from San Francisco References: <6732623D2548D61193C90002A5C88DCC05663984@entmaexch02.broadband.att.com> X-WSS-ID: 12BAFA111690288-01-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Agreed! So what is the revised timeline? regards, kiwin Woundy, Richard wrote: > Stephen, > > That *was* a very good question. But that material (CableHome 1.1 and the > CableHome QoS MIB) is now publically available on: > > http://www.cablelabs.com/projects/cablehome/specifications/ > > Now we should be able to tackle the CableHome drafts full-force! > > -- Rich > > -----Original Message----- > From: Stephen Palm [mailto:palm@broadcom.com] > Sent: Wednesday, April 02, 2003 6:36 PM > To: Woundy, Richard > Cc: IPCDN WG (E-mail) > Subject: Re: [ipcdn] IPCDN meeting minutes from San Francisco > > > > Woundy, Richard wrote: > > >>Review of CableHome MIBs >>------------------------ > > [...] > >>No objections to accepting the CableHome MIBs were received from the >>IPCDN mailing list, nor from the IETF meeting participants. The co- >>chairs will add them to the WG charter. > > > Some of the CableHome MIBs may point to material that might > not be publically available. In that light, what > is the scope and timeline for CableHome MIBs? > > regards, kiwin > -- Stephen [kiwin] Palm Ph.D. E: palm@kiwin.com Principal Engineer T: +1-949-926-PALM Broadcom Home & Wireless Networking Division F: +1-530-325-9798 Irvine, California W: http://www.kiwin.com Secondary email accounts: palm@hompna.org palm@broadcom.com s.palm@ieee.org palm@itu.ch spalm@cs.cmu.edu palm@ics.t.u-tokyo.ac.jp _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Apr 28 10:37:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03243 for ; Mon, 28 Apr 2003 10:37:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SEgGH15735 for ipcdn-archive@odin.ietf.org; Mon, 28 Apr 2003 10:42:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEg8815727; Mon, 28 Apr 2003 10:42:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEes815628 for ; Mon, 28 Apr 2003 10:40:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03123 for ; Mon, 28 Apr 2003 10:35:47 -0400 (EDT) From: Wilson.Sawyer@arrisi.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A9lZ-0003HB-00 for ipcdn@ietf.org; Mon, 28 Apr 2003 10:38:01 -0400 Received: from [63.86.74.196] (helo=titan) by ietf-mx with esmtp (Exim 4.12) id 19A9lV-0003Gx-00 for ipcdn@ietf.org; Mon, 28 Apr 2003 10:37:58 -0400 To: ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Mon, 28 Apr 2003 10:38:07 -0400 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.12 |February 13, 2003) at 04/28/2003 10:38:34 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBE785DFC384BE8f9e8a93df938690918c0ABBE785DFC384BE" Content-Disposition: inline Subject: [ipcdn] Proposed changes to filtering in docsis subscriber management MIB Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --0__=0ABBE785DFC384BE8f9e8a93df938690918c0ABBE785DFC384BE Content-type: text/plain; charset=us-ascii Reviewers of the DOCSIS Subscriber Management MIB have pointed out a large overlap with the Diffserv MIB RFC 3289, and suggested that 3289 could be adapted to our uses. To that end, I'm considering scrapping most of the filtering portion of the subscriber management mib (draft-ietf-ipcdn-subscriber-mib-10.txt) in favor of adding hooks pointing to the diffserv mib (RFC3289). Your advice would be appreciated, particularly if you are a CMTS vendor or operator. In the existing submgt MIB, the filter group indexes a table which contains the IP/TCP/UDP filtering criteria which the operator has configured for that group of modems. The proposed adaptation of RFC 3289 is sketched on the attached acrobat drawing. The mapping of the packet to a filter group remains signaled by Docsis and is outside of the 3289 framework. Conceptually, the packet arrives at the 3289 data path table with its filter group prepended: (filter group)(mac header)(ip header) ... Two tiers of classification are performed: the first use of clfrElementTable is to choose a 'next' based on the filter group. This 'next' chooses a clfrEntry that is the list of IP/TCP/UDP filtering criteria for that modem group. The bottom half of the sketch is entirely within 3289 and wouldn't be part of the revised docsis submgt MIB. It illustrates how we would duplicate our existing functionality using standard 3289 components. The sketch should be read as a UML object diagram; my apologies for any notational inaccuracies. All boxes except those at the upper right are currently part of 3289. In addition to the MIB mechanics, the major changes to classification are: -- TCP/UDP port *ranges* are now required. -- the TCP Flags are no longer used -- a separate default is defined per direction per interface, rather than systemwide. This will require a new section to the Docsis OSSI document to specify the required subset of RFC3289. This is not a mandate to support the full functionality of 3289, and I would resist any scope creep for subscriber management into queuing/metering/re-marking/etc. (See attached file: submgt3289.pdf) - Wilson Sawyer wsawyer@ieee.org --0__=0ABBE785DFC384BE8f9e8a93df938690918c0ABBE785DFC384BE Content-type: application/pdf; name="submgt3289.pdf" Content-Disposition: attachment; filename="submgt3289.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINJeLjz9MNCjMgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDUgDS9IIFsgOTE3 IDE3MyBdIA0vTCA3NDMwIA0vRSA3MTA3IA0vTiAxIA0vVCA3MjUzIA0+PiANZW5kb2JqDSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTMgMjYgDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMDg2NCAwMDAwMCBuDQowMDAw MDAxMDkwIDAwMDAwIG4NCjAwMDAwMDEyOTQgMDAwMDAgbg0KMDAwMDAwMTQyNiAwMDAwMCBuDQow MDAwMDAxNjA2IDAwMDAwIG4NCjAwMDAwMDIwNzAgMDAwMDAgbg0KMDAwMDAwMjI0OSAwMDAwMCBu DQowMDAwMDAyMjcwIDAwMDAwIG4NCjAwMDAwMDI4MDUgMDAwMDAgbg0KMDAwMDAwMjgyNiAwMDAw MCBuDQowMDAwMDAzNDIxIDAwMDAwIG4NCjAwMDAwMDM0NDIgMDAwMDAgbg0KMDAwMDAwMzk0MCAw MDAwMCBuDQowMDAwMDAzOTYxIDAwMDAwIG4NCjAwMDAwMDQ1NTMgMDAwMDAgbg0KMDAwMDAwNDU3 NCAwMDAwMCBuDQowMDAwMDA1MTI1IDAwMDAwIG4NCjAwMDAwMDUxNDYgMDAwMDAgbg0KMDAwMDAw NTcxNiAwMDAwMCBuDQowMDAwMDA1NzM3IDAwMDAwIG4NCjAwMDAwMDYzODcgMDAwMDAgbg0KMDAw MDAwNjQwOCAwMDAwMCBuDQowMDAwMDA2OTY1IDAwMDAwIG4NCjAwMDAwMDA5MTcgMDAwMDAgbg0K MDAwMDAwMTA3MCAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDI5DS9JbmZvIDIgMCBSIA0vUm9v dCA0IDAgUiANL1ByZXYgNzI0NCANL0lEWzwzYTlmMjRkOGMyMTMyMDk2MDdhY2JhNmRiMGY5NmE3 ZT48M2E5ZjI0ZDhjMjEzMjA5NjA3YWNiYTZkYjBmOTZhN2U+XQ0+Pg1zdGFydHhyZWYNMA0lJUVP Rg0gICAgICANNCAwIG9iag08PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyAxIDAgUiANPj4gDWVu ZG9iag0yNyAwIG9iag08PCAvUyAzNiAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI4IDAg UiA+PiANc3RyZWFtDQpIiWJgYJBgYGCeygAE4o4M2AAHlBYAYjEoZmAQZeDSPfapdrd6AwcHQ38D ewlD3wEOD4ZOB84rDG3ME4AqAAIMABxBCycNZW5kc3RyZWFtDWVuZG9iag0yOCAwIG9iag02OSAN ZW5kb2JqDTUgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDEgMCBSIA0vUmVzb3VyY2Vz IDYgMCBSIA0vQ29udGVudHMgWyAxMSAwIFIgMTMgMCBSIDE1IDAgUiAxNyAwIFIgMTkgMCBSIDIx IDAgUiAyMyAwIFIgMjUgMCBSIF0gDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94 IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTYgMCBvYmoNPDwgDS9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDggMCBSID4+IA0vRXh0R1N0YXRlIDw8 IC9HUzEgMjYgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDkgMCBSID4+IA0+PiANZW5kb2Jq DTcgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA5MDUgDS9DYXBIZWln aHQgMCANL0Rlc2NlbnQgLTIxMSANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtNjY1IC0zMjUgMjAy OCAxMDM3IF0gDS9Gb250TmFtZSAvQXJpYWxNVCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0+ PiANZW5kb2JqDTggMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9G aXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMjIgDS9XaWR0aHMgWyAyNzggMCAwIDAgMCAwIDAgMTkx IDMzMyAzMzMgMCA1ODQgMjc4IDMzMyAyNzggMjc4IDAgMCAwIDAgNTU2IDAgNTU2IA0wIDAgMCAy NzggMCAwIDU4NCAwIDAgMCA2NjcgMCA3MjIgNzIyIDY2NyA2MTEgNzc4IDAgMjc4IDAgMCA1NTYg DTgzMyA3MjIgNzc4IDY2NyAwIDcyMiA2NjcgNjExIDcyMiAwIDAgMCAwIDYxMSAwIDAgMCAwIDAg MCA1NTYgNTU2IA01MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMCA1MDAgMjIyIDgzMyA1NTYg NTU2IDU1NiAwIDMzMyA1MDAgDTI3OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDUwMCBdIA0vRW5jb2Rp bmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9BcmlhbE1UIA0vRm9udERlc2NyaXB0b3Ig NyAwIFIgDT4+IA1lbmRvYmoNOSAwIG9iag1bIA0vQ2FsUkdCIDw8IC9XaGl0ZVBvaW50IFsgMC45 NTA1IDEgMS4wODkgXSAvR2FtbWEgWyAyLjIyMjIxIDIuMjIyMjEgMi4yMjIyMSBdIA0vTWF0cml4 IFsgMC40MTI0IDAuMjEyNiAwLjAxOTMgMC4zNTc2IDAuNzE1MTkgMC4xMTkyIDAuMTgwNSAwLjA3 MjIgMC45NTA1IF0gPj4gDQ1dDWVuZG9iag0xMCAwIG9iag00NTcgDWVuZG9iag0xMSAwIG9iag08 PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEwIDAgUiA+PiANc3RyZWFtDQpIiXyTT2/b MAzF7/oUPKZFq5Cy/l6bFUMKDBgQ3YYestjpEjgZkBjo9u1HyqnrNOngi60n6f0eSU9nRwerI1B5 jis1lYXZArA8i5lCeOKXLaA2Fl6BEL7Bj2eEWk2/LghejopgA8o4o9GCiRGCAYpwaNSDeshqmjN/ Q16rVK5MYLzTlQeTLF+JFeSd6t3YHjWiMZD5DfKrmixX3eb3/nHfHf7e5K16zGogdVYMbTDaWkgI Pmjne1sXtWclnJZZL8uhIAY0HxDfwAIfEz1eck3qZbf8vux+5eXPthlQnhhlC4rkSAQfrbYRduWb nbwnbaBVi7EJERWNYQYXCU0SerJZz/d18+cO6s2hKdk/xn7rxymNC/6TNIkExsXiY8+rXLxW7fpw XtlRHEEkr8dpkKTAEocIWfFoJPWwwSXLKqErtejF9nxvq9a3V6L4qpyvSBp2rTGWr3BVuJJESmff 47TNrtl3/0slBRPkikfE+VCIe8H1uOZCCH70YdMocTly3l4TZd4cz7jB9/ZWNDDO6ztBuycdkG3u ZUbyl37XRZJ5/Wn/+6LZSKf5t2mY/xEPOzhKOpgrP1qVil0ztsq3RbLC+0+AAQCuLuM3DWVuZHN0 cmVhbQ1lbmRvYmoNMTIgMCBvYmoNNTE3IA1lbmRvYmoNMTMgMCBvYmoNPDwgL0ZpbHRlciAvRmxh dGVEZWNvZGUgL0xlbmd0aCAxMiAwIFIgPj4gDXN0cmVhbQ0KSIl0U7tu3DAQ7PkVLM8uCHJ3SYpl HDhAghQBrNLNQdI5MnQP6OQ4/vvsLmXn4sBgIQ73MbPU0GxO89AN/XDohqv20bTXxjvvMdq2M5vz cpy3D28BPZuPz3fLdnk6y+lta4KVde4MATpPFn2yxdvQ2HkwN+amNcV6XsUSBucbiwEckEfb7o3X EBcLKZAS7J+mZfwyDlP/edrNt4dlfnmj+sZUj9YARKWK6KCxewMYuaVispOBGF1Of2FKyluzGeck G8EhCW6SQ0kHV0BwYQyKk+TzRDUf5JhxSC5IPLhG+iOryRWj9ENRw9CLCIZEjkix0glvZDoq8mGc QOPUSBfG2bsiceXORbVRXoub7CSXFQkqUScjHX8y5MFFpmZGnZR8UWWEmk4sXJlA9DMGcFLt69wE jWwQSxVCSCoUG2kquHbDXO+BmCZxOx2aWL6o5hq9NIrVDYirtJhUGnugksVSi73TQUluwSIUqZrM HR9gZQsiYs+40Ya1W/K8y6+ll5mT2V1fuk7+nsfCm8hzpNV3bDcq1eOnoRt3Y/fezp7N5sVsq68D vwnxdQ7/GxuyhcJm8+9drQxjvz6gzbbv5/bldPnSoKroz8snDl4E+HevgR/zsBt/fx8OD8vPyzca qv65e1+ZXwMfVEZcW3enf572bjo+f+3t/WY8/Ur3Vxz7I8AAQSrouA1lbmRzdHJlYW0NZW5kb2Jq DTE0IDAgb2JqDTQyMCANZW5kb2JqDTE1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9M ZW5ndGggMTQgMCBSID4+IA1zdHJlYW0NCkiJlFPBTuswELz7K3xs38Gyd+04PnB46HFBD8EhN8Qh SgMCSh05RtC/Z22nFJpwQFHSjmd3Z+xJWPOHSSElVrzp2GoIPvrOb9fNE5sYhZnZjPG/vvEhXj3u DuwJ0b7P28bQLbcdiW9taAobfWgf+i+Eholo4+uY1i8apni6xo6p2gmpuTLIneNG89Czc3beMMcl XY4rh+kWWlNZ88JkXqfObOZ2tQl+aPZDf9Zu39r9+C/4tUKBq2F911weLIArG6ba6y72cfzqW39y N89HJi8KIX4wDNImw6qeGQYFAuiJAmaW0+kWuXb7QFaHi10M+1MJMJAlDHALnPKdSZiKg62pSOJM YMrhcRf7cN92hyR+GwwiZhN0PGRiYZ+opaipgH4WNwpleudfd/FvFxd3OomoWiaRhfQRLQeQC+kf /fvTRHVdvojn7zn/7v28JIdPnCHofAxW8hcCRtBwsEo44FvCVkDC9MJVGTuBlL3VZDhhVKXeCJV5 1BmY3IxV+pNwqXVC59YyWkMZTfJ1xqZgEDaP0nUuVxNtVB5Wuaz0IcAAFer2DA1lbmRzdHJlYW0N ZW5kb2JqDTE2IDAgb2JqDTUxNCANZW5kb2JqDTE3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggMTYgMCBSID4+IA1zdHJlYW0NCkiJbFPLbhQxELz7K3yESFjutrttXyNyyQkp 8wOjZQOJNgTNDkL8PdW2B0WA5jBb09XV1Y91SXIo6lnVXheXpIRagXMgNqxkP3i8DPcAD9rFPeCL BEuIgdS/ALYQMwhHNsRFg3Txt9SLe7xxt4trPuJpPkmyYJHANSa/vLgYYszNLyf37vr9fHp6fDq9 X57d3eIoVitSIqMixYQi2hIkZ0BrNkD8d8AyzDR5e64nF/09qj97V7gn5hTYF/ZU/XZ2t28NlhYS 5HJDM9Ngj5gKnFLpTj+v+/pp3b/efdu3X4fdo9osQopOi0015H/LoEaC8fyfGknGNPbXbf1yNvXl Bgz7tr3+fNjX/cfVvuYgJSX/gTFLv3wcuTN13fY/tu5hC70TRg9fEtX4mCi2iyUb7mskrDEZLuMI SG1JwNU+G+6jkdjGUVBJnU8UWo+XYhsXypNfoxGFShgwY0/CMeS+topVIcrZTAE3soBwndVbtnMS DGnwWxkYaoY5diHJvXvDqevlEnRgCRlYUq/O6EpBl2Ysw63LWY8G0QRkpdC4YbajQnapwx1T6r1Y DwPngOsTmE6DL12u1SknNhOFh5mu4yR4AsxJqQadEJrKh5NivjXR7AM0sWM5nHDEdeYwfneSShwb ZE4BB6eiB0aiHgPCZK2O4j9tEAWASh/PbwEGAHHs1zkNZW5kc3RyZWFtDWVuZG9iag0xOCAwIG9i ag00NzMgDWVuZG9iag0xOSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDE4 IDAgUiA+PiANc3RyZWFtDQpIiXRTMW4jMQzs9QqVuRSCKFGU1AZIk9b7g8UaSLA2Do6Lu9/fkFKM OMlhC2HE4ZDicF3KHEryUltI7HeXcg2teWkp9KSYKWQBrnooLgH0TqEM2ENkYNw2xSWrjvQWxORK Dcy+RppYSOVr5MkXGXE7gCsBfPRSSxAl91msxcDAhAPwAEJX2Uo5kPgTCE27qUSDjdQ6694xd3d8 dE+L6z7i6z6hgr65o6mY/XJyMcTI3S+re3j/va2vx9f11/LmnhdHXr/31UX/guQ374hZq3LKviZP zV829/RZniRr35ygz1PfQqaiNdb9eHk+Xy9/b0VeUES1MU/Vbvo8KkWnBDDmQxhuG0EAiXrLbTpB kvTF3DBpg6yGMnytg15DRE8YaR3xHghx7IEZQZWs8LBAcbJaOCZmmMDIsmzQNCpgG6yWLNN1gqqK j2UYuAtw1mvF5jBzG0YfHKFPJGC7WB+OLlWPycgCs3gs3n7H/OorwdGidcvN2Ifz9uf6fyuTqGqm ro32iP9COzJDKUc8LqePexDmfbGc2jTwk/2sDWc14pv7WDMI3lZg307b+frzJswZYMtONm/Mi8YA RiAWA/wtgIwbyF0+zdNSDvd/QrQVIww1WrP/BBgA9lTWJw1lbmRzdHJlYW0NZW5kb2JqDTIwIDAg b2JqDTQ5MiANZW5kb2JqDTIxIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgg MjAgMCBSID4+IA1zdHJlYW0NCkiJZFLLbhsxDLzrK3RMg5aQSOp1DZpDcs3+QGBvCgS2E6y3aD+/ JKU1NihycIYzKw6HdAFCoOing7s7nN6Wp+P3b9O7+xGhhFy8/KKffjpT8U31eJrP82V9Oqr2cXLR 69/14IJ/9sG/excpQWBPWIHZt+C5Qcp+md2De5hcE1XwzUdqnnKGgoH8dHbB6vqQNmzWcN43m+6N 4u74c5kP83G+HOYdR8m46/qxvP66EVZbPv68rK/r7+vN97P4FruI3S4VtXt2SAEIN3wSnICr4VAV c4Cs+qxlxQmy8glKVpyEF8hgbEqAyhJ0ssnAAlGrgjP35kHLikWLTWsCSjQxFohGlqQWSAx3WDuk Ia+hy8MwUslTrEAdqB+KCVqHGVD6RupDvkil6mcUWac7G1ZnYTxlGWzyr+KTe7vfb1bZpEZQguzL vbvMf9eR/HgZRaJtivjSzGykaiEj2wNmU0CGymME6a559+wqqgqZNj5oTsgIPb2inpGjrlOxmPW6 vR6IhCv/ILXRSpJHqtBwrEWfFpxMnKNZpjrmTxVi3mPzpLjfSOrWqGw30qAqn8dquHuTm9lOiFTO /UhkIm1GY062M0CKfXeyK+b+uY2gJ1t1NEx2rs1S0oMza1+0/60KLX75RtLj/ab+CTAAKBza6w1l bmRzdHJlYW0NZW5kb2JqDTIyIDAgb2JqDTU3MiANZW5kb2JqDTIzIDAgb2JqDTw8IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9MZW5ndGggMjIgMCBSID4+IA1zdHJlYW0NCkiJfFNNb9swDL37V/CYDoum b8sDeljXbkCB7rD6NOTiynLqzrECSUHb/fpRcrNmWDEEiPJCPpJ6j6qu2opB/kRbUbgGCg9QcWMI lVBTDkwL0uBhILjqorpoqwZzKDTAG0U05hjCJRXQ7ipaIrkQoZThX7Za9d7G28PdzTbd+N7t2tAN w2g/T12MV3MKz2ftQ3U6w0trbeR/W3PQDX27MX9tPMYv45Rc+Br8Yb9ZnY9z7542Z7mnIJzrGtaC GCaQcVm4tC7cb+4RkofX2T9mCoU1I/yYypbU767r136ent+DexpjijAOOO/gQnB9LnJXrti+W2ZT hdTNz2CnIVxNbufmVIQg8An2nf3p0km+5CV/1yV77yKk+zEiEbUbh9EFuOsiNvHzCUOYwkj3DsJh Qs7gA2S06AFx3M7dNM7bUw4rHD/AUOSCbdYrkj/eXKM3eS2a+ujNrgCmQddNNmkqWKEttSKNLtgg 4IQtQUOQpbUhssCGYFRL/J4qQRn+ZkTpAjgRWEaZIxakxjZKveQqIrGQErlZxjVuAWJGluymTKho PhAzRih2kmYZSuBWZsCXoCrJMhe+/Wu/cPEVRo1Z9mtl/Zy6cY7QweQf1/vgrOvdbN2pt+bVq3V2 OOt/GtclvlnFvbPonz3/5YK/9OkHHpsz8u+atNnu4PZTZ9HIw/5D7x/nSzd0hynFozmoBF5CNgo9 YU15PKrc/faNhy100UfW+HYMMC6JNm89MFFno2StUeUiwW8BBgDTGAsSDWVuZHN0cmVhbQ1lbmRv YmoNMjQgMCBvYmoNNDc5IA1lbmRvYmoNMjUgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUg L0xlbmd0aCAyNCAwIFIgPj4gDXN0cmVhbQ0KSIl8kt2O2yAQhe95irnrX2qBTRynd91kK7VSr+I+ ACGT2CsbIkM22rfvAGmEd6uVJcsWh/PNnBnGITxOM15wXq6g1ezjwWr387gZvduMO6/8xT0aP718 ap/YY8sEhIduVI0oygbkUhZSgihlUTcgGpiQPbCHlq2j9RqqtQBZ86LhvIJ2ZDOkqO/I3WX/++Q3 449+8Di9i+Q8Qy7lW2SzLEoJUgpC/IdKZ4HqLvsE29qrcX5CNQZi+zmKqleiP+c3knIZJXp8z6ae aXKXEgQvVrym2LfJr4raCb3qDR7gONkRKJsUzT2NX5TGEzApm2JVwpJLGJmsRMhENk1IaGC7PI96 XZColCuS0EeII9CaSGs7pAAH5XtrXNefwR4DicNXCvteWepU6aDCMJtF1iMX0F6pR3sx/rv2cXYL UOaQZxUMeNSp4bSd7DnKoHe5aB0x/TBcKCYq6RnBmuHlG2xpQ+ZScdscdOaDB60mhGuHvsMpTz/1 iEp3cIwDgFF5+pl5Vckr1k+xOzwrguMwa1Kk4dwYQK+8mjLlM+8MVA5J911vTgN6axaAXhfQdqTT yuRmqeg9woBHD96CPSMVZCeweXO3dfl3+OUZzWEmSBt86J2mlaLB3TborwADABrsFFANZW5kc3Ry ZWFtDWVuZG9iag0yNiAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0ZSANL1NBIGZhbHNlIA0vU00g MC4wMiANL1RSIC9JZGVudGl0eSANPj4gDWVuZG9iag0xIDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMg DS9LaWRzIFsgNSAwIFIgXSANL0NvdW50IDEgDT4+IA1lbmRvYmoNMiAwIG9iag08PCANL0NyZWF0 aW9uRGF0ZSAoRDoyMDAzMDQxNjExMTk0MikNL1Byb2R1Y2VyIChBY3JvYmF0IERpc3RpbGxlciA0 LjAgZm9yIFdpbmRvd3MpDS9Nb2REYXRlIChEOjIwMDMwNDE2MTExOTQyLTA0JzAwJykNPj4gDWVu ZG9iag14cmVmDTAgMyANMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDA3MDQzIDAwMDAwIG4NCjAw MDAwMDcxMDcgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAzDS9JRFs8M2E5ZjI0ZDhjMjEzMjA5 NjA3YWNiYTZkYjBmOTZhN2U+PDNhOWYyNGQ4YzIxMzIwOTYwN2FjYmE2ZGIwZjk2YTdlPl0NPj4N c3RhcnR4cmVmDTE3Mw0lJUVPRg0= --0__=0ABBE785DFC384BE8f9e8a93df938690918c0ABBE785DFC384BE-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn