Subject: [ipcdn] Comment on new Cable Device Mib draft

From: "Lejeune, Andre" <[email-masked]>
Date: Tue, 3 Dec 2002 06:49:10 -0800

Hi Rich,
 
The following comment (see attached email) was posted on the ipcdn reflector
a year ago. Would it be possible to include a change in the new draft to
address this? I would like to propose that the MIBs be changed to no longer
be dependant on the value of docsDevFilterIpProtocol. Since there was an ECR
that explained that the fields are only applicable if relevant, all 4 port
related MIBs could be made to match only relevant packets (udp and tcp),
irrespective of the docsDevFilterIpProtocol value.
 
This would therefore read something like:
 
docsDevFilterIpSourcePortLow OBJECT-TYPE
           SYNTAX      Integer32 (0..65535)
           MAX-ACCESS  read-create
           STATUS      current
           DESCRIPTION
               "If the protocol of the packet is udp or tcp, this is the
                inclusive lower bound of the transport-layer source port
                range that is to be matched. This table entry does not
                match if it is set and the packet is not tcp or udp."
           DEFVAL { 0 }
           ::= { docsDevFilterIpEntry 12 }<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />

I am flexible on the actual wording...
 
Thanks,
 
André

From: Wim De Ketelaere [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 1:39 PM
To: [email-masked]
Subject: [ipcdn] docsDevFilterIp requirements

Hi all,

In 

draft-ietf-ipcdn-device-mibv2-01.txt              

I think the definition for docsDevFilterIpSourcePort and equivalent MIBs
should be clarified that

in the case that docsDevFilterIpProtocol is set to "all", the port numbers
need to be checked for 

matching if the traffic is udp or tcp as udp and tcp are included in "all",
this is not clear from the current definitions. Cable operators typically
want to block all TCP/UDP ports below a certain port-number, they will use
any protocol, and put one port-range in. 

docsDevFilterIpSourcePortLow OBJECT-TYPE
           SYNTAX      Integer32 (0..65535)
           MAX-ACCESS  read-create
           STATUS      current
           DESCRIPTION
               "If docsDevFilterIpProtocol is udp or tcp, this is the
                inclusive lower bound of the transport-layer source port
                range that is to be matched, otherwise it is ignored
                during matching."
           DEFVAL { 0 }
           ::= { docsDevFilterIpEntry 12 }

Any comments ?

Thanks,

  Best regards,

    Wim

Wim De Ketelaere
CTO 
tComLabs

---

From: "Lejeune, Andre" <[email-masked]>
Date: Tue, 3 Dec 2002 13:06:30 -0800

Rich,

I know that in the field, some config files are setting protocol to 256 and
setting the ports to what they want, and they expect the packets that are
not udp or tcp to not match with the filter entry. This is the reason I went
through the archive and sent you this comment, btw. This MSO told me that
they have 50% of the modems behaving as they expect (matching to the packet)
and the other 50% behaving the opposite (matching to the filter protocol).
What I am trying to achieve with my wording is to stay along the lines of
RFI-N-02115 (attached), which clarified this kind of situation for
classifiers. I also understand your comment about the object always being
set. But if we go with your definition, currently deployed config files may
stop working for some MSOs and that worries me. What about requiring the
*Low values to be non-0 or the *High to be non-65535 for both the *Low and
*High values to be applicable?

Thanks a lot,

André

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 2:04 PM
To: 'Lejeune, Andre'
Cc: [email-masked]; Raftus, David
Subject: RE: Comment on new Cable Device Mib draft

Andre,

I must have missed the original comment from Wim. Sorry.

Your proposed modifications to the Cable Device MIB seems reasonably OK to
me, with slight wording corrections. In particular, you cannot say "This
table entry does not match if [this object] is set and the packet is not tcp
or udp", because the DEFVAL clauses ensure that these columns are always
"set". If you want to ignore all non-TCP/UDP packets in this row of the IP
filter table, then I think you need to set docsDevFilterIpProtocol to the
appropriate value.

docsDevFilterIpSourcePortLow OBJECT-TYPE
           SYNTAX      Integer32 (0..65535)
           MAX-ACCESS  read-create
           STATUS      current
           DESCRIPTION
               "This is the inclusive lower bound of the transport-layer
                source port range that is to be matched. If the IP
                protocol of the packet is neither UDP nor TCP, this
                object is ignored during matching."
           DEFVAL { 0 }
           ::= { docsDevFilterIpEntry 12 }

What do other folks think? Did I capture the new wording correctly?

-- Rich

-----Original Message-----
From: Lejeune, Andre [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 9:49 AM
To: Woundy, Richard; [email-masked]
Cc: Raftus, David
Subject: Comment on new Cable Device Mib draft

Hi Rich,

Thanks,

André

Hi all,
 
In 

 
Any comments ?
 
Thanks,
  Best regards,
    Wim
               
Wim De Ketelaere
CTO 
tComLabs

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 24 Dec 2002 09:42:05 -0700

Andre and other filtering/classification experts,

I'm not sure how to resolve Andre's objection in the email below, other than
broaden the audience and solicit the opinions of other folks.

My perspective is that the definition of the docsDevFilterIpTable is driven
by the requirements of the DOCSIS RFI, not vice versa. I also had an
informal chat with Matt Schmitt, the author of RFI-N-02115 that is cited
below. Matt pointed out that (unfortunately) there has been a different set
of packet matching rules for the DOCSIS QoS classifiers (per the ECN) and
the docsDevFilterIpTable. Hence, I have been confused about how to resolve
Andre's objection.

If some folks could help me provide some agreeable new DESCRIPTIONs for
docsDevFilterIpSourcePortLow and other Cable Device MIB objects, so they
meet CableLabs requirements and don't cause backward compatability problems,
I would be very grateful.

I would like to publish a working-group last-call-ready version of the Cable
Device MIB by January 20th.

-- Rich

-----Original Message-----
From: Lejeune, Andre [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 4:07 PM
To: Woundy, Richard
Cc: [email-masked]; Raftus, David
Subject: [ipcdn] RE: Comment on new Cable Device Mib draft

Rich,

Thanks a lot,

André

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 2:04 PM
To: 'Lejeune, Andre'
Cc: [email-masked]; Raftus, David
Subject: RE: Comment on new Cable Device Mib draft

Andre,

-- Rich

-----Original Message-----
From: Lejeune, Andre [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 9:49 AM
To: Woundy, Richard; [email-masked]
Cc: Raftus, David
Subject: Comment on new Cable Device Mib draft

Hi Rich,

Thanks,

André

Hi all,
 
In 

 
Any comments ?
 
Thanks,
  Best regards,
    Wim
               
Wim De Ketelaere
CTO 
tComLabs

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Pollak, Lucy" <[email-masked]>
Date: Wed, 25 Dec 2002 19:18:09 +0200

Rich,
I disagree with André. This issue was discussed with CL a number of times,
this is correct. But I also remember that there was not consensus how to
treat this problem. André's mail from 6/9/01 was unanswered in OSS reflector
at least. 
Even if André's statistic is correct, 50% of vendors need to change their
implementations. 
To do what André propose (filter row will not match if fields are
irrelevant), we need to add BIT mask of settled fields as we do it in
classifier. This will not be backward compatible to 100% of vendors.
The MIB compliant CM must "ignore during matching" port fields if
docsDevFilterIpProtocol is not "udp or tcp" in accordance with current MIB
text. The only one problem in the text is that docsDevFilterIpProtocol
=256(any) is not covered in description. 
I suppose we should not change the policy to differently opposite, only to
clarify it. I agree, that classifiers and filters treat similar fields
differently. But I also do not see any problem with this. Each of them are
intended to strictly different things.
I guess, that the better clarification may be:
               "If packet's Ip protocol is udp or tcp, this is the
                inclusive lower bound of the transport-layer source port
                range that is to be matched, otherwise it is ignored
                during matching."
Thanks.
Lucy

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Tuesday, December 24, 2002 6:42 PM
To: 'Lejeune, Andre'; [email-masked]; DOCSIS OSS (E-mail)
Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft

-- Rich

-----Original Message-----
From: Lejeune, Andre [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 4:07 PM
To: Woundy, Richard
Cc: [email-masked]; Raftus, David
Subject: [ipcdn] RE: Comment on new Cable Device Mib draft

Rich,

Thanks a lot,

André

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 2:04 PM
To: 'Lejeune, Andre'
Cc: [email-masked]; Raftus, David
Subject: RE: Comment on new Cable Device Mib draft

Andre,

-- Rich

-----Original Message-----
From: Lejeune, Andre [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 9:49 AM
To: Woundy, Richard; [email-masked]
Cc: Raftus, David
Subject: Comment on new Cable Device Mib draft

Hi Rich,

Thanks,

André

Hi all,
 
In 

 
Any comments ?
 
Thanks,
  Best regards,
    Wim
               
Wim De Ketelaere
CTO 
tComLabs