From ipcdn-admin@ietf.org Fri Sep 1 11:44:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14677; Fri, 1 Sep 2000 11:44:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18103; Fri, 1 Sep 2000 11:39:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18074 for ; Fri, 1 Sep 2000 11:39:51 -0400 (EDT) Received: from mailhost.ne.arris-i.com (abyss.arris-i.com [206.135.68.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14559 for ; Fri, 1 Sep 2000 11:39:50 -0400 (EDT) Received: from ne.arris-i.com (belafonte.ne.arris-i.com [141.251.36.84]) by mailhost.ne.arris-i.com (8.9.3/8.9.3) with ESMTP id LAA02219; Fri, 1 Sep 2000 11:31:39 -0400 Message-ID: <39AFCCB5.AB63DE0E@ne.arris-i.com> Date: Fri, 01 Sep 2000 11:35:17 -0400 From: Stuart Green Organization: Nortel Networks Corporation - Arris Venture X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Anna Ziper CC: docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Subject: Re: [ipcdn] CMTS Multicast Mibs References: <39AD6D5A.EFBB7E9A@terayon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Anna, These are good suggestions which we should incorporate in a future release of the MIB. Stuart Anna Ziper wrote: > > I have a few suggestions on multicast issue: > > a. Multicast groups sets and subsets > > BPI+ Mibs defines docsBpi2CmtsIpMulticastMapTable. > Lets consider two possible entries in this table. > > 1. IP Multicast Address 10.24.0d.3e prefix - 16 > 2. IP Multicast Address 10.24.d4.6f prefix - 16 > > Both entries match the same set of Ip multicast addresses. > So if both of them exist in the table two appropriate SAIDs can match > for one multicast group. > I suggest to restrict this situation. It can be done by rejection of > collision entries inserting. > I.e. it is illegal to create new entry in the table that can match or > be subset > of existing set of multicast groups. It is illegal also to create new > entry for which the existing one can be subset. > > I prefer to change BPI+ MIBs for table docsBpi2CmtsIpMulticastMapTable: > > from: > "Each entry contains objects describing the mapping of > one multicast IP address and prefix to one SAID, as well as > associated message counters and error information. > Note: For dynamic multicast IP addresses, create access > does not apply." > > to: > "Each entry contains objects describing the mapping of > a set of multicast IP addresses and prefix and all its subsets to one > SAID, as well as > associated message counters and error information. > Note: For dynamic multicast IP addresses, create access > does not apply." > > b. Multicast SAIDs > > I suggest to split between Multicast Saids (both dynamic and static) and > Unicast Saids. > > By definition, Primary Saids equal to primary Sids. > This statement automatically defines range for unicast Sids from 1 to > 8K. > Lets consider situation when a multicast group is defined with the same > Said as > primary Said of some cable modem. It looks at least unsafe. > > If we range multicast Saids from 16K to 8K, > it decreases the common number of Saids, but clarifies the issue. > > This change can be done by changing BPI+ Mibs for > docsBpi2CmtsIpMulticastMapTable: > > from: > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > SYNTAX Integer32 (1..16383) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object represents the multicast SAID to be > used in this IP multicast address mapping entry." > ::= { docsBpi2CmtsIpMulticastMapEntry 3 } > > to: > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > SYNTAX Integer32 (8193..16383) > > Thanks, Anna > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > http://www1.ietf.org/mailman/listinfo/ipcdn -- Stuart M Green Nortel Networks Corporation - Arris Venture 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 5 09:01:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00938; Tue, 5 Sep 2000 09:01:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26665; Tue, 5 Sep 2000 09:00:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26628 for ; Tue, 5 Sep 2000 09:00:07 -0400 (EDT) Received: from huksweep.eu.hns.com (mail.eu.hns.com [193.129.245.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00856 for ; Tue, 5 Sep 2000 09:00:08 -0400 (EDT) Received: from pegasus.eu.hns.com (unverified) by huksweep.eu.hns.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Tue, 5 Sep 2000 14:10:55 +0100 Received: from EUROWEB ([139.85.104.6]) by pegasus.eu.hns.com (Lotus Domino Release 5.0.4a) with ESMTP id 2000090514040563:150 ; Tue, 5 Sep 2000 14:04:05 +0000 To: ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: From: A.Valentine@eu.hns.com Date: Tue, 5 Sep 2000 12:59:51 +0000 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on HNSUK1/HNSEU(Release 5.0.2c (Intl)|2 February 2000) at 05/09/2000 13:59:52, Itemize by SMTP Server on PEGASUS/HNSEU(Release 5.0.4a |July 24, 2000) at 05/09/2000 14:04:05, Serialize by Router on PEGASUS/HNSEU(Release 5.0.4a |July 24, 2000) at 05/09/2000 14:04:06, Serialize complete at 05/09/2000 14:04:06 Content-type: text/plain; charset=us-ascii Subject: [ipcdn] CableNetwork Interface Unit MIB. Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Dear all, I have been having some discussion with Jens from Cisco CPS about the CDM MIB, from this discussion the following changes to the MIB have been suggested. If nobody disagrees with them, I will add them to the next draft. 1) A new object to disable / enable multicast. See definition below > Multicast. > Here we have to distinguish between upstream and downstream. > Especially the downstream multicast control can not simply be controlled > with dvbNiuIpFilters. > The modem must support the IGMPv2 protocol > and use that to minimize the load on the Ethernet and the cable. > Please note that the ETS 300 800 6.1.2.2 already states that > the IGMP protocol should be used as a basis for MAC address setup. > Downstream enabled > If downstream multicast is enabled downstream IGMP query messages > should be let trough. > The modem should look at the IGMP report messages and only > let trough the UDP multicast packets for those groups that are active. > This implies that the modem must keep track of all the active multicast > sessions. > Since there can be an unlimited number of multicast sessions, > at some number of sessions (we choose 16) the modem > must enter a promiscuous mode where all is let trough. > Promiscuous mode should be left gracefully when the number of sessions > get below the limit again. > Downstream disabled > If downstream multicast is disabled the both downstream IGMP queries, > upstream IGMP reports and multicast UDP packets should be discarded. > Upstream > The upstream multicast is just a simple filter. > If upstream multicast is enabled all upstream UDP multicast packets are > let trough. > If disabled then all upstream UDP multicast packets are discarded. > This could be done with the dvbNiuIpFilters. 2) Add to the NAPT/NAT description that it not applicable to multicast and state that in the downstream NAPT/NAT is applied before filters. 3) A new table should be created for anti-spoofing filters and remove them from the current filter table . This will be much simpler than the current filter table. The reason for the new table is to simply the management of this type of filter, and resolve index creation issues. 4) > Under dvbNiuIpFilterTable is stated that "Packets which match no filters will be discarded". > Will a packet that once has passed a filter row with dvbNiuIpFilterAction > set to Accept and dvbNiuIpFilterContinue set to TRUE > be discarded when it reach the end of the filter table? The packet would not be discarded because there was a filter hit. the descritpion needs clarifying. 5) > Should there be a NAT/NAPT action applied to both directions? > Or this action only for upstream direction and then implicit on the > downstream direction > if enabled upstream? > You can not just use the same filter in both directions, since > in the upstream it should be applied to some source (and destination) > addresses > and in the downstream it should be applied to a specific destination > address. > I assume the translation (IP/port) => port only can be applied upstream. A NAT/NAPT filter always has a implicit inverse function e.g. if I set up a filter to perform NAPT in the upstream direction, then any packets sent downstream to the NAPTed address will be translated. The NAPT was intended only for the upstream direction, I will explicity state this in the MIB. -- Andrew Valentine Systems Engineer UK Engineering Design Centre Hughes Network Systems Ltd. Linford Wood , Saxon Street, Milton Keynes MK14 6LD, United Kingdom Tel : Direct +44 1908 326 233 Tel Main +44 1908 221122 x 233 Fax : +44 1908 221127 Email: A.Valentine@eu.hns.com #********************************************************************** This message is intended solely for the use of the individual or organisation to whom it is addressed. It may contain privileged or confidential information. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you should not use, copy, alter, or disclose the contents of this message. All information or opinions expressed in this message and/or any attachments are those of the author and are not necessarily those of Hughes Network Systems Limited, including its European subsidiaries and affiliates. Hughes Network Systems Limited, including its European subsidiaries and affiliates accepts no responsibility for loss or damage arising from its use, including damage from virus. #********************************************************************** _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 5 17:40:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14362; Tue, 5 Sep 2000 17:40:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02628; Tue, 5 Sep 2000 17:31:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02598 for ; Tue, 5 Sep 2000 17:30:53 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14205 for ; Tue, 5 Sep 2000 17:30:51 -0400 (EDT) Received: [from pobox3.mot.com ([10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA22227 for ; Tue, 5 Sep 2000 14:30:51 -0700 (MST)] Received: [from ont15exm1.ont.isg.mot.com (ont15exch1.ont.isg.mot.com [219.1.83.99]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA29189 for ; Tue, 5 Sep 2000 14:29:41 -0700 (MST)] Received: by ont15exch1.ont.isg.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Sep 2000 17:35:51 -0400 Message-ID: <642F9A357902D411BA5F0008C791975688EE5A@ma07exm1.corp.isg.mot.com> From: Levine Jay-LJL033 To: "'Stuart Green'" , Anna Ziper Cc: docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Subject: RE: [ipcdn] CMTS Multicast Mibs Date: Tue, 5 Sep 2000 17:30:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Stuart and Anna, (and the rest) As regards the range of multicast saids, there is no prohibition that a multicast said not be equal to a cm's primary said. See section 5.1 of the Bpi+ spec. It is also a MAY in the pics 4.7.10. It looks ugly, but in practice all it means is that multicast flow as well as some other traffic is encrypted/decrypted with the same set of keying material. -Jay Jay Levine Motorola Broadband Communications Sector 20 Cabot Blvd Mansfield MA, 02048-1193 Tel : (508) 261-4487 Email : ljl033@email.mot.com > -----Original Message----- > From: Stuart Green [mailto:stu.green@ne.arris-i.com] > Sent: Friday, September 01, 2000 11:35 AM > To: Anna Ziper > Cc: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; ipcdn@ietf.org > Subject: Re: [ipcdn] CMTS Multicast Mibs > > > Anna, > These are good suggestions which we should incorporate > in a future release of the MIB. > > Stuart > > Anna Ziper wrote: > > > > I have a few suggestions on multicast issue: > > > > a. Multicast groups sets and subsets > > > > BPI+ Mibs defines docsBpi2CmtsIpMulticastMapTable. > > Lets consider two possible entries in this table. > > > > 1. IP Multicast Address 10.24.0d.3e prefix - 16 > > 2. IP Multicast Address 10.24.d4.6f prefix - 16 > > > > Both entries match the same set of Ip multicast addresses. > > So if both of them exist in the table two appropriate > SAIDs can match > > for one multicast group. > > I suggest to restrict this situation. It can be done by > rejection of > > collision entries inserting. > > I.e. it is illegal to create new entry in the table that > can match or > > be subset > > of existing set of multicast groups. It is illegal also to > create new > > entry for which the existing one can be subset. > > > > I prefer to change BPI+ MIBs for table > docsBpi2CmtsIpMulticastMapTable: > > > > from: > > "Each entry contains objects describing the mapping of > > one multicast IP address and prefix to one SAID, as well as > > associated message counters and error information. > > Note: For dynamic multicast IP addresses, create access > > does not apply." > > > > to: > > "Each entry contains objects describing the mapping of > > a set of multicast IP addresses and prefix and all its > subsets to one > > SAID, as well as > > associated message counters and error information. > > Note: For dynamic multicast IP addresses, create access > > does not apply." > > > > b. Multicast SAIDs > > > > I suggest to split between Multicast Saids (both dynamic > and static) and > > Unicast Saids. > > > > By definition, Primary Saids equal to primary Sids. > > This statement automatically defines range for unicast Sids > from 1 to > > 8K. > > Lets consider situation when a multicast group is defined > with the same > > Said as > > primary Said of some cable modem. It looks at least unsafe. > > > > If we range multicast Saids from 16K to 8K, > > it decreases the common number of Saids, but clarifies the issue. > > > > This change can be done by changing BPI+ Mibs for > > docsBpi2CmtsIpMulticastMapTable: > > > > from: > > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > > SYNTAX Integer32 (1..16383) > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "This object represents the multicast SAID to be > > used in this IP multicast address mapping entry." > > ::= { docsBpi2CmtsIpMulticastMapEntry 3 } > > > > to: > > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > > SYNTAX Integer32 (8193..16383) > > > > Thanks, Anna > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > http://www1.ietf.org/mailman/listinfo/ipcdn > > -- > Stuart M Green > Nortel Networks Corporation - Arris Venture > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Sep 7 19:07:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28968; Thu, 7 Sep 2000 19:07:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16152; Thu, 7 Sep 2000 19:01:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16126 for ; Thu, 7 Sep 2000 19:01:45 -0400 (EDT) Received: from mailhost.ne.arris-i.com (abyss.arris-i.com [206.135.68.99]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28901 for ; Thu, 7 Sep 2000 19:01:45 -0400 (EDT) Received: from ne.arris-i.com (belafonte.ne.arris-i.com [141.251.36.84]) by mailhost.ne.arris-i.com (8.9.3/8.9.3) with ESMTP id SAA02070; Thu, 7 Sep 2000 18:52:45 -0400 Message-ID: <39B81D34.7459B9ED@ne.arris-i.com> Date: Thu, 07 Sep 2000 18:56:52 -0400 From: Stuart Green Organization: Nortel Networks Corporation - Arris Venture X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Levine Jay-LJL033 CC: Anna Ziper , docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Subject: Re: [ipcdn] CMTS Multicast Mibs References: <642F9A357902D411BA5F0008C791975688EE5A@ma07exm1.corp.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Good point, Jay. I had a feeling that the mapping might be funny. On the other hand, if the multicast IP address is mapped to a primary SAID then there would already be a TEK entry (which in turn is referenced by an AUTH entry). So we would not necessarily need a multicast SAID entry; it would provide little additional information. I'm going to take your suggestion and leave the multicast SAID range as is, unless someone has a strong objection. We could always not utilize the additional range. Stuart Levine Jay-LJL033 wrote: > > Stuart and Anna, (and the rest) > > As regards the range of multicast saids, there is no prohibition that a > multicast said not be equal to a cm's primary said. See section 5.1 of the > Bpi+ spec. It is also a MAY in the pics 4.7.10. It looks ugly, but in > practice all it means is that multicast flow as well as some other traffic > is encrypted/decrypted with the same set of keying material. > > -Jay > > Jay Levine > Motorola Broadband Communications Sector > 20 Cabot Blvd > Mansfield MA, 02048-1193 > Tel : (508) 261-4487 > Email : ljl033@email.mot.com > > > -----Original Message----- > > From: Stuart Green [mailto:stu.green@ne.arris-i.com] > > Sent: Friday, September 01, 2000 11:35 AM > > To: Anna Ziper > > Cc: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; ipcdn@ietf.org > > Subject: Re: [ipcdn] CMTS Multicast Mibs > > > > > > Anna, > > These are good suggestions which we should incorporate > > in a future release of the MIB. > > > > Stuart > > > > Anna Ziper wrote: > > > > > > I have a few suggestions on multicast issue: > > > > > > a. Multicast groups sets and subsets > > > > > > BPI+ Mibs defines docsBpi2CmtsIpMulticastMapTable. > > > Lets consider two possible entries in this table. > > > > > > 1. IP Multicast Address 10.24.0d.3e prefix - 16 > > > 2. IP Multicast Address 10.24.d4.6f prefix - 16 > > > > > > Both entries match the same set of Ip multicast addresses. > > > So if both of them exist in the table two appropriate > > SAIDs can match > > > for one multicast group. > > > I suggest to restrict this situation. It can be done by > > rejection of > > > collision entries inserting. > > > I.e. it is illegal to create new entry in the table that > > can match or > > > be subset > > > of existing set of multicast groups. It is illegal also to > > create new > > > entry for which the existing one can be subset. > > > > > > I prefer to change BPI+ MIBs for table > > docsBpi2CmtsIpMulticastMapTable: > > > > > > from: > > > "Each entry contains objects describing the mapping of > > > one multicast IP address and prefix to one SAID, as well as > > > associated message counters and error information. > > > Note: For dynamic multicast IP addresses, create access > > > does not apply." > > > > > > to: > > > "Each entry contains objects describing the mapping of > > > a set of multicast IP addresses and prefix and all its > > subsets to one > > > SAID, as well as > > > associated message counters and error information. > > > Note: For dynamic multicast IP addresses, create access > > > does not apply." > > > > > > b. Multicast SAIDs > > > > > > I suggest to split between Multicast Saids (both dynamic > > and static) and > > > Unicast Saids. > > > > > > By definition, Primary Saids equal to primary Sids. > > > This statement automatically defines range for unicast Sids > > from 1 to > > > 8K. > > > Lets consider situation when a multicast group is defined > > with the same > > > Said as > > > primary Said of some cable modem. It looks at least unsafe. > > > > > > If we range multicast Saids from 16K to 8K, > > > it decreases the common number of Saids, but clarifies the issue. > > > > > > This change can be done by changing BPI+ Mibs for > > > docsBpi2CmtsIpMulticastMapTable: > > > > > > from: > > > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > > > SYNTAX Integer32 (1..16383) > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "This object represents the multicast SAID to be > > > used in this IP multicast address mapping entry." > > > ::= { docsBpi2CmtsIpMulticastMapEntry 3 } > > > > > > to: > > > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > > > SYNTAX Integer32 (8193..16383) > > > > > > Thanks, Anna > > > > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > -- > > Stuart M Green > > Nortel Networks Corporation - Arris Venture > > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > http://www1.ietf.org/mailman/listinfo/ipcdn -- Stuart M Green Nortel Networks Corporation - Arris Venture 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From owner-ipcdn@mails.terayon.com Tue Sep 12 16:18:35 2000 Received: from terayon.com (terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13532 for ; Tue, 12 Sep 2000 16:18:35 -0400 (EDT) Received: (from root@localhost) by terayon.com (8.9.3+Sun/8.9.3) id KAA25875 for ipcdn-outgoing; Tue, 12 Sep 2000 10:26:02 -0700 (PDT) Message-ID: <013b01c01cde$281a3ee0$7501a8c0@oleane.oleane.com> From: "Peter Lewis" To: Subject: IP over DWDM 2000 International Conference, Paris 27-30 November, 2000 Date: Tue, 12 Sep 2000 19:23:24 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0138_01C01CEE.EB36B880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipcdn@mails.terayon.com Precedence: bulk Reply-To: ipcdn@mails.terayon.com This is a multi-part message in MIME format. ------=_NextPart_000_0138_01C01CEE.EB36B880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This event aims at presenting an up-to-date state of the art in the = design of new Internet network architectures. It will be a unique = opportunity for researchers, network operators and service providers = from both the IP world and the optical networking world to discuss the = potentialities of all these promising perspectives.=20 http://www.upperside.fr/badwdm.htm ------=_NextPart_000_0138_01C01CEE.EB36B880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This event aims at presenting an up-to-date state of the art in the = design=20 of new Internet network architectures. It will be a unique opportunity = for=20 researchers, network operators and service providers from both the IP = world and=20 the optical networking world to discuss the potentialities of all these=20 promising perspectives.
 
http://www.upperside.fr/badwd= m.htm
------=_NextPart_000_0138_01C01CEE.EB36B880-- From ipcdn-admin@ietf.org Sat Sep 16 04:08:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13229; Sat, 16 Sep 2000 04:08:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16384; Sat, 16 Sep 2000 04:07:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16358 for ; Sat, 16 Sep 2000 04:07:50 -0400 (EDT) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13200 for ; Sat, 16 Sep 2000 04:07:51 -0400 (EDT) Received: from kazbook (A020-0015.DNVR.splitrock.net [63.253.54.15]) by pimout1-int.prodigy.net (8.10.1/8.10.1) with SMTP id e8G87fp196046; Sat, 16 Sep 2000 04:07:41 -0400 From: "Kaz Ozawa" To: "Stuart Green" , "Anna Ziper" Cc: , , Date: Sat, 16 Sep 2000 02:03:21 -0600 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <39AFD2EE.A3908DA8@ne.arris-i.com> Content-Transfer-Encoding: 7bit Subject: [ipcdn] RE: cm certs Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Anna and Stuart, Let me summarize the questions just in case... 1. The condition to override the trust state by docsBpi2CmtsProvisionedCmCertEntry As Stuart told, "the provisioned CM cert must be identical to the BPKM CM cert for an override to take place". I think this condition is not written in the BPI+ MIB spec (bpiplus-mib-03.txt) and we should add this. This may be obvious for the PKI specialist but we should eliminate the misunderstanding. I also want to make sure the exact meaning of "identical". Does this require the bit by bit comparison or the hash of the certs is also acceptable? I believe that the comparison of the subject commonName (that is, MAC address) is not enough. Strictly speaking, we cannot test the CMTS without this definition. (My head is flooded with ATP and automation and ATP and ATP and... :) 2. If CM MAC Address is same but Cert is NOT identical.... Let's consider the case where docsBpi2CmtsProvisionedCmCertMacAddress is identical to a certain CM but docsBpi2CmtsProvisionedCmCert is NOT identical to the cert which is forwarded from the CM to the CMTS via Auth Request message. From #1 above, it is clear that the trust state of the CM Cert forwarded via Auth Request message won't be overridden. Then the question is how the CMTS should handle the docsBpi2CmtsProvisionedCmCertEntry which does not work at all. (I thought that this was Anna's question.) Does the CMTS have to keep this meaningless entry forever? I don't think the CMTS is allowed to remove this entry automatically. However, there may be a couple of options. (1) The entry must not be removed but the entire cert need not to be retained in the CMTS. ---- I believe that this option is allowed under the current BPI+ MIB spec (2) The entry must not be removed but the "Event Notification" (Local event logging, SNMP TRAP or SYSLOG) takes place in order to encourage the operator to delete the entry. Any comments? Thanks, kaz > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Stuart Green > Sent: Friday, September 01, 2000 10:02 AM > To: Anna Ziper > Cc: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com > Subject: Re: cm certs > > > Anna, > The provisioned CM cert must be identical to the BPKM CM cert for > an override to take place. > Stuart > > Anna Ziper wrote: > > > > Hi everybody! > > > > I'd like to discuss some certification issues that are not clear for me > > from specs. > > > > Bpi+ Mibs spec defines two tables that may keep Cm Certification. > > > > docsBpi2CmtsAuthTable generally keeps Cm Cert arrived from Auth Request > > BPKM message. > > > > docsBpi2CmtsProvisionedCmCertTable keeps provisioned Cm Cert (source > > Snmp or config file or other). > > The spec says that the second table has bigger priority and overwrites > > the first one. > > > > There are two main problems: > > 1. memory > > 2. consistency. > > > > You should keep the same information twice > > and it is not clear what the procedure if the information is different. > > > > Lets consider next scenario, we have Provisioned CmCert for the cable > > modem. > > We get different Cm Cert from Auth Request. > > By definition they have to be the same, > > but by mistake (operator mistyped) they are different. > > > > We should reject the modem? Why? And if reject, then with which reason? > > > > And the opposite situation, we have Cm Cert from Auth Request, > > we get Cm Cert from SNMP manager, and they are different. > > What we should do? > > > > Actualy, I haven't found any other reasons to keep Cm certs. > > > > Thanks, > > Anna > > -- > Stuart M Green > Nortel Networks Corporation - Arris Venture > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Sat Sep 16 04:08:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13240; Sat, 16 Sep 2000 04:08:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16353; Sat, 16 Sep 2000 04:07:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16321 for ; Sat, 16 Sep 2000 04:07:45 -0400 (EDT) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13197 for ; Sat, 16 Sep 2000 04:07:46 -0400 (EDT) Received: from kazbook (A020-0015.DNVR.splitrock.net [63.253.54.15]) by pimout1-int.prodigy.net (8.10.1/8.10.1) with SMTP id e8G87ap196044; Sat, 16 Sep 2000 04:07:36 -0400 From: "Kaz Ozawa" To: "Stuart Green" , "Levine Jay-LJL033" Cc: "Anna Ziper" , , , Subject: RE: [ipcdn] CMTS Multicast Mibs Date: Sat, 16 Sep 2000 02:03:15 -0600 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <39B81D34.7459B9ED@ne.arris-i.com> Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > Stuart Green > Sent: Thursday, September 07, 2000 4:57 PM > To: Levine Jay-LJL033 > Cc: Anna Ziper; docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; > ipcdn@ietf.org > Subject: Re: [ipcdn] CMTS Multicast Mibs > > > Good point, Jay. I had a feeling that the mapping might be funny. > On the other hand, if the multicast IP address is mapped to a primary > SAID > then there would already be a TEK entry (which in turn is referenced > by an AUTH entry). So we would not necessarily need a multicast > SAID entry; it would provide little additional information. I understand that docsBpi2CmtsIpMulticastMapEntry and docsBpi2CmIpMulticastMapEntry are intended to provide - mapping between IP Multicast Address and SAID and - information related to Dynamic SA Map FSM. Therefore, regardless of the type of SAID, Primary, Static, or Dynamic, the entry provides those information. I have no doubt that the entry in these two tables are required regardless of the type of SAID. I think that only the difference is the following. In case of Dynamic SAID, the TEK state machine starts after the Dynamic SA Map Request and Reply messages. On the other hand, in case of Static and Primary SAID, the TEK state machine started before the Dynamic SA Map Request and Reply messages are exchanged. Thanks, kaz > > I'm going to take your suggestion and leave the multicast SAID > range as is, unless someone has a strong objection. We could always > not utilize the additional range. > > Stuart > > > Levine Jay-LJL033 wrote: > > > > Stuart and Anna, (and the rest) > > > > As regards the range of multicast saids, there is no prohibition that a > > multicast said not be equal to a cm's primary said. See section 5.1 of the > > Bpi+ spec. It is also a MAY in the pics 4.7.10. It looks ugly, but in > > practice all it means is that multicast flow as well as some other traffic > > is encrypted/decrypted with the same set of keying material. > > > > -Jay > > > > Jay Levine > > Motorola Broadband Communications Sector > > 20 Cabot Blvd > > Mansfield MA, 02048-1193 > > Tel : (508) 261-4487 > > Email : ljl033@email.mot.com > > > > > -----Original Message----- > > > From: Stuart Green [mailto:stu.green@ne.arris-i.com] > > > Sent: Friday, September 01, 2000 11:35 AM > > > To: Anna Ziper > > > Cc: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; ipcdn@ietf.org > > > Subject: Re: [ipcdn] CMTS Multicast Mibs > > > > > > > > > Anna, > > > These are good suggestions which we should incorporate > > > in a future release of the MIB. > > > > > > Stuart > > > > > > Anna Ziper wrote: > > > > > > > > I have a few suggestions on multicast issue: > > > > > > > > a. Multicast groups sets and subsets > > > > > > > > BPI+ Mibs defines docsBpi2CmtsIpMulticastMapTable. > > > > Lets consider two possible entries in this table. > > > > > > > > 1. IP Multicast Address 10.24.0d.3e prefix - 16 > > > > 2. IP Multicast Address 10.24.d4.6f prefix - 16 > > > > > > > > Both entries match the same set of Ip multicast addresses. > > > > So if both of them exist in the table two appropriate > > > SAIDs can match > > > > for one multicast group. > > > > I suggest to restrict this situation. It can be done by > > > rejection of > > > > collision entries inserting. > > > > I.e. it is illegal to create new entry in the table that > > > can match or > > > > be subset > > > > of existing set of multicast groups. It is illegal also to > > > create new > > > > entry for which the existing one can be subset. > > > > > > > > I prefer to change BPI+ MIBs for table > > > docsBpi2CmtsIpMulticastMapTable: > > > > > > > > from: > > > > "Each entry contains objects describing the mapping of > > > > one multicast IP address and prefix to one SAID, as well as > > > > associated message counters and error information. > > > > Note: For dynamic multicast IP addresses, create access > > > > does not apply." > > > > > > > > to: > > > > "Each entry contains objects describing the mapping of > > > > a set of multicast IP addresses and prefix and all its > > > subsets to one > > > > SAID, as well as > > > > associated message counters and error information. > > > > Note: For dynamic multicast IP addresses, create access > > > > does not apply." > > > > > > > > b. Multicast SAIDs > > > > > > > > I suggest to split between Multicast Saids (both dynamic > > > and static) and > > > > Unicast Saids. > > > > > > > > By definition, Primary Saids equal to primary Sids. > > > > This statement automatically defines range for unicast Sids > > > from 1 to > > > > 8K. > > > > Lets consider situation when a multicast group is defined > > > with the same > > > > Said as > > > > primary Said of some cable modem. It looks at least unsafe. > > > > > > > > If we range multicast Saids from 16K to 8K, > > > > it decreases the common number of Saids, but clarifies the issue. > > > > > > > > This change can be done by changing BPI+ Mibs for > > > > docsBpi2CmtsIpMulticastMapTable: > > > > > > > > from: > > > > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > > > > SYNTAX Integer32 (1..16383) > > > > MAX-ACCESS read-create > > > > STATUS current > > > > DESCRIPTION > > > > "This object represents the multicast SAID to be > > > > used in this IP multicast address mapping entry." > > > > ::= { docsBpi2CmtsIpMulticastMapEntry 3 } > > > > > > > > to: > > > > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > > > > SYNTAX Integer32 (8193..16383) > > > > > > > > Thanks, Anna > > > > > > > > _______________________________________________ > > > > IPCDN mailing list > > > > IPCDN@ietf.org > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > -- > > > Stuart M Green > > > Nortel Networks Corporation - Arris Venture > > > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > http://www1.ietf.org/mailman/listinfo/ipcdn > > -- > Stuart M Green > Nortel Networks Corporation - Arris Venture > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > http://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Sat Sep 16 19:44:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17931; Sat, 16 Sep 2000 19:44:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22531; Sat, 16 Sep 2000 19:42:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22479 for ; Sat, 16 Sep 2000 19:42:39 -0400 (EDT) Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17893 for ; Sat, 16 Sep 2000 19:42:40 -0400 (EDT) Received: from mail-serv.terayon.com (mail-serv.terayon.com [192.168.0.11]) by terayon.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20961; Sat, 16 Sep 2000 16:41:31 -0700 (PDT) Received: from name-asic.terayon.com (name-asic.terayon.com [192.168.66.10]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id QAA11316; Sat, 16 Sep 2000 16:41:30 -0700 (PDT) Received: from terayon.com ([192.168.130.254]) by name-asic.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id QAA15556; Sat, 16 Sep 2000 16:41:30 -0700 (PDT) Message-ID: <39C404F1.670CA05A@terayon.com> Date: Sat, 16 Sep 2000 16:40:33 -0700 From: Anna Ziper X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kaz Ozawa CC: Stuart Green , Levine Jay-LJL033 , Anna Ziper , docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Subject: Re: [ipcdn] CMTS Multicast Mibs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit I have a few questions about BPI multicast. Sorry, if these questions have been on the reflector yet. 1. ifindex in docsBpi2CmtsMulticastAuthTable table The key to the table includes ifindex, but cable modem can be located under different ifindexes, and its mac address defines in a unique way the modem. You can know ifindex only after the modem becomes active. I don't understand for which scenarios we need ifindex as a part of the table entry. 2. Multicast group mapping As I understand, ones a multicast group gets its Said, this Said stays as long as multicast group exists. There is no any way to change Said for existing multicast group. Please, correct me if I am wrong. 3. CM Authorization But it is possible to deauthorize a modem for Said. What happens if the operator wishes to revoke the CM's authorization to access some multicast flows? How do you do this? You must first force CM to stop accessing the multicast flow, and this may or may not involve the termination of a TEK FSM. Currently the only way to stop a CM from accessing a flow is via TEKInvalid. But this won't work for case where old DS SAID (i.e. TEK FSM) is used by more than one traffic flow. If there is a way to say SaMapInvalid to modem? thanks, Anna Kaz Ozawa wrote: > > -----Original Message----- > > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > > Stuart Green > > Sent: Thursday, September 07, 2000 4:57 PM > > To: Levine Jay-LJL033 > > Cc: Anna Ziper; docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; > > ipcdn@ietf.org > > Subject: Re: [ipcdn] CMTS Multicast Mibs > > > > > > Good point, Jay. I had a feeling that the mapping might be funny. > > On the other hand, if the multicast IP address is mapped to a primary > > SAID > > then there would already be a TEK entry (which in turn is referenced > > by an AUTH entry). So we would not necessarily need a multicast > > SAID entry; it would provide little additional information. > > I understand that docsBpi2CmtsIpMulticastMapEntry and > docsBpi2CmIpMulticastMapEntry are intended to provide > - mapping between IP Multicast Address and SAID and > - information related to Dynamic SA Map FSM. > Therefore, regardless of the type of SAID, Primary, Static, or > Dynamic, the entry provides those information. > > I have no doubt that the entry in these two tables are > required regardless of the type of SAID. > > I think that only the difference is the following. > In case of Dynamic SAID, the TEK state machine starts after > the Dynamic SA Map Request and Reply messages. > On the other hand, in case of Static and Primary SAID, the > TEK state machine started before the Dynamic SA Map Request > and Reply messages are exchanged. > > Thanks, > kaz > > > > > I'm going to take your suggestion and leave the multicast SAID > > range as is, unless someone has a strong objection. We could always > > not utilize the additional range. > > > > Stuart > > > > > > Levine Jay-LJL033 wrote: > > > > > > Stuart and Anna, (and the rest) > > > > > > As regards the range of multicast saids, there is no prohibition that a > > > multicast said not be equal to a cm's primary said. See section 5.1 of the > > > Bpi+ spec. It is also a MAY in the pics 4.7.10. It looks ugly, but in > > > practice all it means is that multicast flow as well as some other traffic > > > is encrypted/decrypted with the same set of keying material. > > > > > > -Jay > > > > > > Jay Levine > > > Motorola Broadband Communications Sector > > > 20 Cabot Blvd > > > Mansfield MA, 02048-1193 > > > Tel : (508) 261-4487 > > > Email : ljl033@email.mot.com > > > > > > > -----Original Message----- > > > > From: Stuart Green [mailto:stu.green@ne.arris-i.com] > > > > Sent: Friday, September 01, 2000 11:35 AM > > > > To: Anna Ziper > > > > Cc: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; ipcdn@ietf.org > > > > Subject: Re: [ipcdn] CMTS Multicast Mibs > > > > > > > > > > > > Anna, > > > > These are good suggestions which we should incorporate > > > > in a future release of the MIB. > > > > > > > > Stuart > > > > > > > > Anna Ziper wrote: > > > > > > > > > > I have a few suggestions on multicast issue: > > > > > > > > > > a. Multicast groups sets and subsets > > > > > > > > > > BPI+ Mibs defines docsBpi2CmtsIpMulticastMapTable. > > > > > Lets consider two possible entries in this table. > > > > > > > > > > 1. IP Multicast Address 10.24.0d.3e prefix - 16 > > > > > 2. IP Multicast Address 10.24.d4.6f prefix - 16 > > > > > > > > > > Both entries match the same set of Ip multicast addresses. > > > > > So if both of them exist in the table two appropriate > > > > SAIDs can match > > > > > for one multicast group. > > > > > I suggest to restrict this situation. It can be done by > > > > rejection of > > > > > collision entries inserting. > > > > > I.e. it is illegal to create new entry in the table that > > > > can match or > > > > > be subset > > > > > of existing set of multicast groups. It is illegal also to > > > > create new > > > > > entry for which the existing one can be subset. > > > > > > > > > > I prefer to change BPI+ MIBs for table > > > > docsBpi2CmtsIpMulticastMapTable: > > > > > > > > > > from: > > > > > "Each entry contains objects describing the mapping of > > > > > one multicast IP address and prefix to one SAID, as well as > > > > > associated message counters and error information. > > > > > Note: For dynamic multicast IP addresses, create access > > > > > does not apply." > > > > > > > > > > to: > > > > > "Each entry contains objects describing the mapping of > > > > > a set of multicast IP addresses and prefix and all its > > > > subsets to one > > > > > SAID, as well as > > > > > associated message counters and error information. > > > > > Note: For dynamic multicast IP addresses, create access > > > > > does not apply." > > > > > > > > > > b. Multicast SAIDs > > > > > > > > > > I suggest to split between Multicast Saids (both dynamic > > > > and static) and > > > > > Unicast Saids. > > > > > > > > > > By definition, Primary Saids equal to primary Sids. > > > > > This statement automatically defines range for unicast Sids > > > > from 1 to > > > > > 8K. > > > > > Lets consider situation when a multicast group is defined > > > > with the same > > > > > Said as > > > > > primary Said of some cable modem. It looks at least unsafe. > > > > > > > > > > If we range multicast Saids from 16K to 8K, > > > > > it decreases the common number of Saids, but clarifies the issue. > > > > > > > > > > This change can be done by changing BPI+ Mibs for > > > > > docsBpi2CmtsIpMulticastMapTable: > > > > > > > > > > from: > > > > > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > > > > > SYNTAX Integer32 (1..16383) > > > > > MAX-ACCESS read-create > > > > > STATUS current > > > > > DESCRIPTION > > > > > "This object represents the multicast SAID to be > > > > > used in this IP multicast address mapping entry." > > > > > ::= { docsBpi2CmtsIpMulticastMapEntry 3 } > > > > > > > > > > to: > > > > > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > > > > > SYNTAX Integer32 (8193..16383) > > > > > > > > > > Thanks, Anna > > > > > > > > > > _______________________________________________ > > > > > IPCDN mailing list > > > > > IPCDN@ietf.org > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > -- > > > > Stuart M Green > > > > Nortel Networks Corporation - Arris Venture > > > > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > > > > > > > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > -- > > Stuart M Green > > Nortel Networks Corporation - Arris Venture > > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Sat Sep 16 19:44:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17943; Sat, 16 Sep 2000 19:44:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22540; Sat, 16 Sep 2000 19:42:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22480 for ; Sat, 16 Sep 2000 19:42:39 -0400 (EDT) Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17894 for ; Sat, 16 Sep 2000 19:42:40 -0400 (EDT) Received: from mail-serv.terayon.com (mail-serv.terayon.com [192.168.0.11]) by terayon.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20965; Sat, 16 Sep 2000 16:41:33 -0700 (PDT) Received: from name-asic.terayon.com (name-asic.terayon.com [192.168.66.10]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id QAA11320; Sat, 16 Sep 2000 16:41:33 -0700 (PDT) Received: from terayon.com ([192.168.130.254]) by name-asic.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id QAA15560; Sat, 16 Sep 2000 16:41:33 -0700 (PDT) Message-ID: <39C404F4.5225C3F@terayon.com> Date: Sat, 16 Sep 2000 16:40:36 -0700 From: Anna Ziper X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kaz Ozawa CC: Stuart Green , Levine Jay-LJL033 , docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Subject: Re: [ipcdn] CMTS Multicast Mibs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit I still think that the range for multicast Saids can be chosen by vender. Stuart, may be you know when will be a future release of the MIB? thanks, Anna Kaz Ozawa wrote: > > -----Original Message----- > > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > > Stuart Green > > Sent: Thursday, September 07, 2000 4:57 PM > > To: Levine Jay-LJL033 > > Cc: Anna Ziper; docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; > > ipcdn@ietf.org > > Subject: Re: [ipcdn] CMTS Multicast Mibs > > > > > > Good point, Jay. I had a feeling that the mapping might be funny. > > On the other hand, if the multicast IP address is mapped to a primary > > SAID > > then there would already be a TEK entry (which in turn is referenced > > by an AUTH entry). So we would not necessarily need a multicast > > SAID entry; it would provide little additional information. > > I understand that docsBpi2CmtsIpMulticastMapEntry and > docsBpi2CmIpMulticastMapEntry are intended to provide > - mapping between IP Multicast Address and SAID and > - information related to Dynamic SA Map FSM. > Therefore, regardless of the type of SAID, Primary, Static, or > Dynamic, the entry provides those information. > > I have no doubt that the entry in these two tables are > required regardless of the type of SAID. > > I think that only the difference is the following. > In case of Dynamic SAID, the TEK state machine starts after > the Dynamic SA Map Request and Reply messages. > On the other hand, in case of Static and Primary SAID, the > TEK state machine started before the Dynamic SA Map Request > and Reply messages are exchanged. > > Thanks, > kaz > > > > > I'm going to take your suggestion and leave the multicast SAID > > range as is, unless someone has a strong objection. We could always > > not utilize the additional range. > > > > Stuart > > > > > > Levine Jay-LJL033 wrote: > > > > > > Stuart and Anna, (and the rest) > > > > > > As regards the range of multicast saids, there is no prohibition that a > > > multicast said not be equal to a cm's primary said. See section 5.1 of the > > > Bpi+ spec. It is also a MAY in the pics 4.7.10. It looks ugly, but in > > > practice all it means is that multicast flow as well as some other traffic > > > is encrypted/decrypted with the same set of keying material. > > > > > > -Jay > > > > > > Jay Levine > > > Motorola Broadband Communications Sector > > > 20 Cabot Blvd > > > Mansfield MA, 02048-1193 > > > Tel : (508) 261-4487 > > > Email : ljl033@email.mot.com > > > > > > > -----Original Message----- > > > > From: Stuart Green [mailto:stu.green@ne.arris-i.com] > > > > Sent: Friday, September 01, 2000 11:35 AM > > > > To: Anna Ziper > > > > Cc: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; ipcdn@ietf.org > > > > Subject: Re: [ipcdn] CMTS Multicast Mibs > > > > > > > > > > > > Anna, > > > > These are good suggestions which we should incorporate > > > > in a future release of the MIB. > > > > > > > > Stuart > > > > > > > > Anna Ziper wrote: > > > > > > > > > > I have a few suggestions on multicast issue: > > > > > > > > > > a. Multicast groups sets and subsets > > > > > > > > > > BPI+ Mibs defines docsBpi2CmtsIpMulticastMapTable. > > > > > Lets consider two possible entries in this table. > > > > > > > > > > 1. IP Multicast Address 10.24.0d.3e prefix - 16 > > > > > 2. IP Multicast Address 10.24.d4.6f prefix - 16 > > > > > > > > > > Both entries match the same set of Ip multicast addresses. > > > > > So if both of them exist in the table two appropriate > > > > SAIDs can match > > > > > for one multicast group. > > > > > I suggest to restrict this situation. It can be done by > > > > rejection of > > > > > collision entries inserting. > > > > > I.e. it is illegal to create new entry in the table that > > > > can match or > > > > > be subset > > > > > of existing set of multicast groups. It is illegal also to > > > > create new > > > > > entry for which the existing one can be subset. > > > > > > > > > > I prefer to change BPI+ MIBs for table > > > > docsBpi2CmtsIpMulticastMapTable: > > > > > > > > > > from: > > > > > "Each entry contains objects describing the mapping of > > > > > one multicast IP address and prefix to one SAID, as well as > > > > > associated message counters and error information. > > > > > Note: For dynamic multicast IP addresses, create access > > > > > does not apply." > > > > > > > > > > to: > > > > > "Each entry contains objects describing the mapping of > > > > > a set of multicast IP addresses and prefix and all its > > > > subsets to one > > > > > SAID, as well as > > > > > associated message counters and error information. > > > > > Note: For dynamic multicast IP addresses, create access > > > > > does not apply." > > > > > > > > > > b. Multicast SAIDs > > > > > > > > > > I suggest to split between Multicast Saids (both dynamic > > > > and static) and > > > > > Unicast Saids. > > > > > > > > > > By definition, Primary Saids equal to primary Sids. > > > > > This statement automatically defines range for unicast Sids > > > > from 1 to > > > > > 8K. > > > > > Lets consider situation when a multicast group is defined > > > > with the same > > > > > Said as > > > > > primary Said of some cable modem. It looks at least unsafe. > > > > > > > > > > If we range multicast Saids from 16K to 8K, > > > > > it decreases the common number of Saids, but clarifies the issue. > > > > > > > > > > This change can be done by changing BPI+ Mibs for > > > > > docsBpi2CmtsIpMulticastMapTable: > > > > > > > > > > from: > > > > > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > > > > > SYNTAX Integer32 (1..16383) > > > > > MAX-ACCESS read-create > > > > > STATUS current > > > > > DESCRIPTION > > > > > "This object represents the multicast SAID to be > > > > > used in this IP multicast address mapping entry." > > > > > ::= { docsBpi2CmtsIpMulticastMapEntry 3 } > > > > > > > > > > to: > > > > > docsBpi2CmtsIpMulticastSAId OBJECT-TYPE > > > > > SYNTAX Integer32 (8193..16383) > > > > > > > > > > Thanks, Anna > > > > > > > > > > _______________________________________________ > > > > > IPCDN mailing list > > > > > IPCDN@ietf.org > > > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > -- > > > > Stuart M Green > > > > Nortel Networks Corporation - Arris Venture > > > > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > > > > > > > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > -- > > Stuart M Green > > Nortel Networks Corporation - Arris Venture > > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 19 16:38:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24552; Tue, 19 Sep 2000 16:38:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14751; Tue, 19 Sep 2000 16:37:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14723 for ; Tue, 19 Sep 2000 16:37:10 -0400 (EDT) Received: from mailhost.ne.arris-i.com (abyss.arris-i.com [206.135.68.99]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24526 for ; Tue, 19 Sep 2000 16:37:08 -0400 (EDT) Received: from ne.arris-i.com (belafonte.ne.arris-i.com [141.251.36.84]) by mailhost.ne.arris-i.com (8.9.3/8.9.3) with ESMTP id QAA28329; Tue, 19 Sep 2000 16:27:01 -0400 Message-ID: <39C7CD44.824E9CB2@ne.arris-i.com> Date: Tue, 19 Sep 2000 16:32:04 -0400 From: Stuart Green Organization: Nortel Networks Corporation - Arris Venture X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kaz Ozawa CC: Anna Ziper , docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] Re: cm certs Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Kaz, See below for my comments. Thanks. Stuart Kaz Ozawa wrote: > > Anna and Stuart, > > Let me summarize the questions just in case... > > 1. The condition to override the trust state by > docsBpi2CmtsProvisionedCmCertEntry > As Stuart told, "the provisioned CM cert must be identical to the > BPKM CM cert for an override to take place". I think this condition > is not written in the BPI+ MIB spec (bpiplus-mib-03.txt) and we > should add this. This may be obvious for the PKI specialist but > we should eliminate the misunderstanding. > > I also want to make sure the exact meaning of "identical". Does > this require the bit by bit comparison or the hash of the certs > is also acceptable? Right. The entire certificate must match, not just the commonName. > I believe that the comparison of the subject > commonName (that is, MAC address) is not enough. > Strictly speaking, we cannot test the CMTS without this definition. > (My head is flooded with ATP and automation and ATP and ATP and... :) > > 2. If CM MAC Address is same but Cert is NOT identical.... > Let's consider the case where docsBpi2CmtsProvisionedCmCertMacAddress > is identical to a certain CM but docsBpi2CmtsProvisionedCmCert is NOT > identical to the cert which is forwarded from the CM to the CMTS via > Auth Request message. From #1 above, it is clear that the trust > state of the CM Cert forwarded via Auth Request message won't be > overridden. Then the question is how the CMTS should handle the > docsBpi2CmtsProvisionedCmCertEntry which does not work at all. > (I thought that this was Anna's question.) > Does the CMTS have to keep this meaningless entry forever? > No, the row status column enables a user to destroy a provisioned certificate. The certificate could also disappear following a re-boot. > I don't think the CMTS is allowed to remove this entry automatically. > However, there may be a couple of options. > (1) The entry must not be removed but the entire cert need not to be > retained in the CMTS. ---- I believe that this option is allowed > under the current BPI+ MIB spec True. > (2) The entry must not be removed but the "Event Notification" > (Local event logging, SNMP TRAP or SYSLOG) takes place in order > to encourage the operator to delete the entry. > We could add an event notification when receiving a bpkm certificate which does not match the provisioned certificate. It would say something such as "ignoring provisioned certificate" and include the mac address. I would not be too concerned about this case, however. One can determine if the provisioned certificate has any effect by just rebooting the modem. > Any comments? > Thanks, > kaz > > > -----Original Message----- > > From: owner-docsis-sec@cablelabs.com > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Stuart Green > > Sent: Friday, September 01, 2000 10:02 AM > > To: Anna Ziper > > Cc: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com > > Subject: Re: cm certs > > > > > > Anna, > > The provisioned CM cert must be identical to the BPKM CM cert for > > an override to take place. > > Stuart > > > > Anna Ziper wrote: > > > > > > Hi everybody! > > > > > > I'd like to discuss some certification issues that are not clear for me > > > from specs. > > > > > > Bpi+ Mibs spec defines two tables that may keep Cm Certification. > > > > > > docsBpi2CmtsAuthTable generally keeps Cm Cert arrived from Auth Request > > > BPKM message. > > > > > > docsBpi2CmtsProvisionedCmCertTable keeps provisioned Cm Cert (source > > > Snmp or config file or other). > > > The spec says that the second table has bigger priority and overwrites > > > the first one. > > > > > > There are two main problems: > > > 1. memory > > > 2. consistency. > > > > > > You should keep the same information twice > > > and it is not clear what the procedure if the information is different. > > > > > > Lets consider next scenario, we have Provisioned CmCert for the cable > > > modem. > > > We get different Cm Cert from Auth Request. > > > By definition they have to be the same, > > > but by mistake (operator mistyped) they are different. > > > > > > We should reject the modem? Why? And if reject, then with which reason? > > > > > > And the opposite situation, we have Cm Cert from Auth Request, > > > we get Cm Cert from SNMP manager, and they are different. > > > What we should do? > > > > > > Actualy, I haven't found any other reasons to keep Cm certs. > > > > > > Thanks, > > > Anna > > > > -- > > Stuart M Green > > Nortel Networks Corporation - Arris Venture > > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > > > > > -- Stuart M Green Nortel Networks Corporation - Arris Venture 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 19 22:23:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29359; Tue, 19 Sep 2000 22:23:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17877; Tue, 19 Sep 2000 22:20:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17849 for ; Tue, 19 Sep 2000 22:20:19 -0400 (EDT) Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29327 for ; Tue, 19 Sep 2000 22:20:17 -0400 (EDT) Received: from kazbook (A010-0813.DNVR.splitrock.net [63.253.51.51]) by pimout4-int.prodigy.net (8.10.1/8.10.1) with SMTP id e8K2K7Z174096; Tue, 19 Sep 2000 22:20:07 -0400 From: "Kaz Ozawa" To: "Stuart Green" , "Kaz Ozawa" Cc: "Anna Ziper" , , , Date: Tue, 19 Sep 2000 20:15:39 -0600 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <39C7CD44.824E9CB2@ne.arris-i.com> Content-Transfer-Encoding: 7bit Subject: [ipcdn] RE: cm certs Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Stuart, Thank you for your reply. Please see my comments inline. > -----Original Message----- > From: sgreen@ne.arris-i.com [mailto:sgreen@ne.arris-i.com]On Behalf Of > Stuart Green > Sent: Tuesday, September 19, 2000 2:32 PM > To: Kaz Ozawa > Cc: Anna Ziper; docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; > ipcdn@ietf.org > Subject: Re: cm certs > > > Kaz, > See below for my comments. Thanks. > Stuart > > Kaz Ozawa wrote: > > > > Anna and Stuart, > > > > Let me summarize the questions just in case... > > > > 1. The condition to override the trust state by > > docsBpi2CmtsProvisionedCmCertEntry > > As Stuart told, "the provisioned CM cert must be identical to the > > BPKM CM cert for an override to take place". I think this condition > > is not written in the BPI+ MIB spec (bpiplus-mib-03.txt) and we > > should add this. This may be obvious for the PKI specialist but > > we should eliminate the misunderstanding. > > > > I also want to make sure the exact meaning of "identical". Does > > this require the bit by bit comparison or the hash of the certs > > is also acceptable? > > > Right. The entire certificate must match, not just the commonName. Then I think we should add some text to make sure this in BPI+ MIB spec or OSSI spec. How do you think? > > > > I believe that the comparison of the subject > > commonName (that is, MAC address) is not enough. > > Strictly speaking, we cannot test the CMTS without this definition. > > (My head is flooded with ATP and automation and ATP and ATP and... :) > > > > 2. If CM MAC Address is same but Cert is NOT identical.... > > Let's consider the case where docsBpi2CmtsProvisionedCmCertMacAddress > > is identical to a certain CM but docsBpi2CmtsProvisionedCmCert is NOT > > identical to the cert which is forwarded from the CM to the CMTS via > > Auth Request message. From #1 above, it is clear that the trust > > state of the CM Cert forwarded via Auth Request message won't be > > overridden. Then the question is how the CMTS should handle the > > docsBpi2CmtsProvisionedCmCertEntry which does not work at all. > > (I thought that this was Anna's question.) > > Does the CMTS have to keep this meaningless entry forever? > > > > No, the row status column enables a user to destroy a > provisioned certificate. The certificate could also > disappear following a re-boot. That's right. > > > > I don't think the CMTS is allowed to remove this entry automatically. > > However, there may be a couple of options. > > (1) The entry must not be removed but the entire cert need not to be > > retained in the CMTS. ---- I believe that this option is allowed > > under the current BPI+ MIB spec > > True. > > > (2) The entry must not be removed but the "Event Notification" > > (Local event logging, SNMP TRAP or SYSLOG) takes place in order > > to encourage the operator to delete the entry. > > > > We could add an event notification when receiving a bpkm certificate > which does not match the provisioned certificate. It would say > something such as "ignoring provisioned certificate" and include > the mac address. > > I would not be too concerned about this case, however. > One can determine if the provisioned certificate has any effect > by just rebooting the modem. Let's see. The operator will put the provisioned CM cert only when they want to override the trust status of the CM cert comes from the CM. Therefore, if the operator sets a wrong one and it does not override the status, the operator should recognize. Therefore, this message may not be so essential. I need to review the event notification requirement for the CMTS... Thanks, kaz > > > > Any comments? > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Stuart Green > > > Sent: Friday, September 01, 2000 10:02 AM > > > To: Anna Ziper > > > Cc: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com > > > Subject: Re: cm certs > > > > > > > > > Anna, > > > The provisioned CM cert must be identical to the BPKM CM cert for > > > an override to take place. > > > Stuart > > > > > > Anna Ziper wrote: > > > > > > > > Hi everybody! > > > > > > > > I'd like to discuss some certification issues that are not clear for me > > > > from specs. > > > > > > > > Bpi+ Mibs spec defines two tables that may keep Cm Certification. > > > > > > > > docsBpi2CmtsAuthTable generally keeps Cm Cert arrived from Auth Request > > > > BPKM message. > > > > > > > > docsBpi2CmtsProvisionedCmCertTable keeps provisioned Cm Cert (source > > > > Snmp or config file or other). > > > > The spec says that the second table has bigger priority and overwrites > > > > the first one. > > > > > > > > There are two main problems: > > > > 1. memory > > > > 2. consistency. > > > > > > > > You should keep the same information twice > > > > and it is not clear what the procedure if the information is different. > > > > > > > > Lets consider next scenario, we have Provisioned CmCert for the cable > > > > modem. > > > > We get different Cm Cert from Auth Request. > > > > By definition they have to be the same, > > > > but by mistake (operator mistyped) they are different. > > > > > > > > We should reject the modem? Why? And if reject, then with which reason? > > > > > > > > And the opposite situation, we have Cm Cert from Auth Request, > > > > we get Cm Cert from SNMP manager, and they are different. > > > > What we should do? > > > > > > > > Actualy, I haven't found any other reasons to keep Cm certs. > > > > > > > > Thanks, > > > > Anna > > > > > > -- > > > Stuart M Green > > > Nortel Networks Corporation - Arris Venture > > > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > > > > > > > > > > -- > Stuart M Green > Nortel Networks Corporation - Arris Venture > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From owner-ipcdn@terayon.com Thu Sep 21 21:26:34 2000 Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16798 for ; Thu, 21 Sep 2000 21:26:34 -0400 (EDT) Received: (from root@localhost) by terayon.com (8.9.3+Sun/8.9.3) id PAA10301 for ipcdn-outgoing; Thu, 21 Sep 2000 15:39:26 -0700 (PDT) Message-ID: <39CA8D6B.EDFA9353@cisco.com> Date: Thu, 21 Sep 2000 18:36:27 -0400 From: Doug Currie Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipcdn@terayon.com Subject: ipcdn archive Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com Content-Transfer-Encoding: 7bit I just joined this list and was hoping to come up to speed by perusing the archives. The ietf site (http://www.ietf.org/html.charters/ipcdn-charter.html) lists the archive as: Archive: ftp://ftp.terayon.com/pub/ipcdn There doesn't appear to be a "ipcdn" directory in /pub at ftp.terayon.com. An updated pointer or clarifications would be appreciated. Thanks, Doug From ipcdn-admin@ietf.org Fri Sep 22 22:12:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01364; Fri, 22 Sep 2000 22:11:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16149; Fri, 22 Sep 2000 22:07:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16117 for ; Fri, 22 Sep 2000 22:07:45 -0400 (EDT) Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01268 for ; Fri, 22 Sep 2000 22:07:42 -0400 (EDT) Received: from mail-serv.terayon.com (mail-serv.terayon.com [192.168.0.11]) by terayon.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10578; Fri, 22 Sep 2000 19:07:12 -0700 (PDT) Received: from name-asic.terayon.com (name-asic.terayon.com [192.168.66.10]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id TAA14105; Fri, 22 Sep 2000 19:07:11 -0700 (PDT) Received: from terayon.com ([192.168.130.254]) by name-asic.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id TAA17381; Fri, 22 Sep 2000 19:07:11 -0700 (PDT) Message-ID: <39CC1001.EFCA2106@terayon.com> Date: Fri, 22 Sep 2000 19:05:53 -0700 From: Anna Ziper X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] multicast without BPI? Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Hi everybody, Can multicast work without BPI? I.e. packages in multicast can be non encrypted? If yes, what happens with a modem authorization per multicast group? Can we still use Bpi multicast mib tables for authorization purpose? Thanks, Anna _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 26 14:18:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13808; Tue, 26 Sep 2000 14:18:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21969; Tue, 26 Sep 2000 14:13:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21943 for ; Tue, 26 Sep 2000 14:12:59 -0400 (EDT) Received: from ns.intelenet.net (ns.intelenet.net [204.182.160.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13746 for ; Tue, 26 Sep 2000 14:12:58 -0400 (EDT) Received: from kazbook (at029.cablelabs.com [12.17.244.29] (may be forged)) by ns.intelenet.net (8.9.3/8.9.3) with SMTP id LAA02149; Tue, 26 Sep 2000 11:12:51 -0700 (PDT) From: "Kaz Ozawa" To: "Anna Ziper" , , , Cc: Subject: RE: [ipcdn] multicast without BPI? Date: Tue, 26 Sep 2000 12:08:12 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <39CC1001.EFCA2106@terayon.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit I believe that the IP Multicast works without BPI+ in DOCSIS 1.1. The CMTS and the CM must be compliant to the section 3.3.1 of the DOCSIS RFIv1.1 spec. Those requirements are independent from the BPI+ and the BPI+ can be either turned on nor off. If the BPI+ is turned on, the BPI+ MIB's multicast related tables can be used to manage the authorization of the cable modems per SAID. However, it's not a requirement in the DOCSIS. If we turn off the BPI+ in DOCSIS 1.1, I believe that all the BPI+ MIB tables are not required. However, I think there is no problem to implement if a vendor want to do so. By the way, If the BPI+ is turned off, how can we block the IP multicast packet forwarding to a specific CM (or CPE beyond the CM)? Thanks, kaz > -----Original Message----- > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > Anna Ziper > Sent: Friday, September 22, 2000 8:06 PM > To: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; ipcdn@ietf.org > Subject: [ipcdn] multicast without BPI? > > > > Hi everybody, > > Can multicast work without BPI? I.e. packages in multicast can be > non encrypted? > If yes, what happens with a modem authorization per multicast group? > > Can we still use Bpi multicast mib tables for authorization purpose? > > Thanks, > Anna > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > http://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 26 14:31:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14048; Tue, 26 Sep 2000 14:31:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22187; Tue, 26 Sep 2000 14:27:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22157 for ; Tue, 26 Sep 2000 14:27:36 -0400 (EDT) Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13967 for ; Tue, 26 Sep 2000 14:27:35 -0400 (EDT) Received: from mail-serv.terayon.com (mail-serv.terayon.com [192.168.0.11]) by terayon.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02462; Tue, 26 Sep 2000 11:27:01 -0700 (PDT) Received: from name-asic.terayon.com (name-asic.terayon.com [192.168.66.10]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id LAA04479; Tue, 26 Sep 2000 11:27:00 -0700 (PDT) Received: from terayon.com ([192.168.130.254]) by name-asic.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id LAA14641; Tue, 26 Sep 2000 11:27:00 -0700 (PDT) Message-ID: <39D0EA56.903913FA@terayon.com> Date: Tue, 26 Sep 2000 11:26:30 -0700 From: Anna Ziper X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kaz Ozawa CC: docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org, docsis-macup@cablelabs.com Subject: Re: [ipcdn] multicast without BPI? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit See my comment inline thanks, Anna Kaz Ozawa wrote: > I believe that the IP Multicast works without BPI+ in DOCSIS 1.1. > The CMTS and the CM must be compliant to the section 3.3.1 of the DOCSIS RFIv1.1 > spec. > Those requirements are independent from the BPI+ and the BPI+ can be either > turned on nor off. > > If the BPI+ is turned on, the BPI+ MIB's multicast related tables can be used to > manage > the authorization of the cable modems per SAID. However, it's not a requirement > in the > DOCSIS. > > If we turn off the BPI+ in DOCSIS 1.1, I believe that all the BPI+ MIB tables > are not > required. However, I think there is no problem to implement if a vendor want to > do so. > > By the way, If the BPI+ is turned off, how can we block the IP multicast packet > forwarding to a specific CM (or CPE beyond the CM)? The problem is that cable modem multicast authorization depends on BPI multicast tables. If there is another authorization table connecting IP multicast address and cable modem identification? > Thanks, > kaz > > > -----Original Message----- > > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > > Anna Ziper > > Sent: Friday, September 22, 2000 8:06 PM > > To: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; ipcdn@ietf.org > > Subject: [ipcdn] multicast without BPI? > > > > > > > > Hi everybody, > > > > Can multicast work without BPI? I.e. packages in multicast can be > > non encrypted? > > If yes, what happens with a modem authorization per multicast group? > > > > Can we still use Bpi multicast mib tables for authorization purpose? > > > > Thanks, > > Anna > > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 26 19:24:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17676; Tue, 26 Sep 2000 19:24:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25693; Tue, 26 Sep 2000 19:23:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25663 for ; Tue, 26 Sep 2000 19:23:26 -0400 (EDT) Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17664 for ; Tue, 26 Sep 2000 19:23:25 -0400 (EDT) Received: from mail-serv.terayon.com (mail-serv.terayon.com [192.168.0.11]) by terayon.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09367; Tue, 26 Sep 2000 16:22:53 -0700 (PDT) Received: from name-asic.terayon.com (name-asic.terayon.com [192.168.66.10]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id QAA10639; Tue, 26 Sep 2000 16:22:53 -0700 (PDT) Received: from terayon.com ([192.168.130.254]) by name-asic.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id QAA19685; Tue, 26 Sep 2000 16:22:52 -0700 (PDT) Message-ID: <39D12FAD.C98A1992@terayon.com> Date: Tue, 26 Sep 2000 16:22:21 -0700 From: Anna Ziper X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Content-Type: multipart/mixed; boundary="------------78D11B331947F768DC132E8F" Subject: [ipcdn] [Fwd: FW: multicast mib table question] Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org This is a multi-part message in MIME format. --------------78D11B331947F768DC132E8F Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit --------------78D11B331947F768DC132E8F Content-Type: message/rfc822 Content-Disposition: inline Received: from mail-serv.terayon.com (mail-serv.terayon.com [192.168.0.11]) by name-asic.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id QAA19488 for ; Tue, 26 Sep 2000 16:16:32 -0700 (PDT) Received: from scbh01.terayon.com (SCOWA.terayon.com [192.168.0.19]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id QAA10492 for ; Tue, 26 Sep 2000 16:16:32 -0700 (PDT) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Sep 2000 16:14:09 -0700 Message-ID: <37063C40296BD411A68400D0B7AF537AAF3ED8@SCEXCH01.terayon.com> From: "Mitchell, Earl" To: "Ziper, Anna" Subject: FW: multicast mib table question Date: Tue, 26 Sep 2000 16:14:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mozilla-Status2: 00000000 -----Original Message----- From: Mitchell, Earl Sent: Monday, September 25, 2000 4:13 PM To: 'docsis-sec@cablelabs.com' Subject: multicast mib table question The CMTS Multicast SAID Authorization Table has a comment that states: Note: The CMTS need only track those CMs actively using the SAID. I don't understand this comment. Is this table used by operator to specify which CMs are authorized to used which SAIDs? Or is it used to show which CM's are currently using which SAIDs? The comment implies that only CMs that are actively using this SAID are listed in the table. This table could be used for both if you just added another field to state whether the CM is currently using the SAID or not. -earl --------------78D11B331947F768DC132E8F-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 26 20:10:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18061; Tue, 26 Sep 2000 20:10:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26277; Tue, 26 Sep 2000 20:09:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26253 for ; Tue, 26 Sep 2000 20:09:21 -0400 (EDT) Received: from mailhost.ne.arris-i.com (abyss.arris-i.com [206.135.68.99]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18033 for ; Tue, 26 Sep 2000 20:09:20 -0400 (EDT) Received: from ne.arris-i.com (belafonte.ne.arris-i.com [141.251.36.84]) by mailhost.ne.arris-i.com (8.9.3/8.9.3) with ESMTP id TAA12878; Tue, 26 Sep 2000 19:58:57 -0400 Message-ID: <39D13990.E2C1D52E@ne.arris-i.com> Date: Tue, 26 Sep 2000 20:04:32 -0400 From: Stuart Green Organization: Nortel Networks Corporation - Arris Venture X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Anna Ziper CC: docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Subject: Re: [ipcdn] [Fwd: FW: multicast mib table question] References: <39D12FAD.C98A1992@terayon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Folks, The description needs some clarification. For static SAIDs, you would need to track both active and inactive CMs. However, dynamic SAIDs need only track active CMs. Tracking inactive CMs would be optional. The goal was to re-use a 1.0/BPI table (which only supported static SAIDs). The comment was not in the BPI MIB. I'll make a note of modifying the comment in a future revision. Stuart Anna Ziper wrote: > > ------------------------------------------------------------------------ > > Subject: FW: multicast mib table question > Date: Tue, 26 Sep 2000 16:14:40 -0700 > From: "Mitchell, Earl" > To: "Ziper, Anna" > > > -----Original Message----- > From: Mitchell, Earl > Sent: Monday, September 25, 2000 4:13 PM > To: 'docsis-sec@cablelabs.com' > Subject: multicast mib table question > > The CMTS Multicast SAID Authorization Table > has a comment that states: > > Note: The CMTS need only track those CMs actively using > the SAID. > > I don't understand this comment. Is this table used by > operator to specify which CMs are authorized to used > which SAIDs? Or is it used to show which CM's are > currently using which SAIDs? > > The comment implies that only CMs that are actively > using this SAID are listed in the table. This table could > be used for both if you just added another field to state > whether the CM is currently using the SAID or not. > > -earl > > -- Stuart M Green Nortel Networks Corporation - Arris Venture 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 26 20:34:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18273; Tue, 26 Sep 2000 20:34:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26690; Tue, 26 Sep 2000 20:33:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26661 for ; Tue, 26 Sep 2000 20:33:38 -0400 (EDT) Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18252 for ; Tue, 26 Sep 2000 20:33:37 -0400 (EDT) Received: from mail-serv.terayon.com (mail-serv.terayon.com [192.168.0.11]) by terayon.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11239; Tue, 26 Sep 2000 17:32:35 -0700 (PDT) Received: from name-asic.terayon.com (name-asic.terayon.com [192.168.66.10]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id RAA12241; Tue, 26 Sep 2000 17:32:34 -0700 (PDT) Received: from terayon.com ([192.168.130.254]) by name-asic.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id RAA20747; Tue, 26 Sep 2000 17:32:34 -0700 (PDT) Message-ID: <39D14003.3051826C@terayon.com> Date: Tue, 26 Sep 2000 17:32:03 -0700 From: Anna Ziper X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stuart Green CC: docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Subject: Re: [ipcdn] [Fwd: FW: multicast mib table question] References: <39D12FAD.C98A1992@terayon.com> <39D13990.E2C1D52E@ne.arris-i.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Stuart, I want to clarify that the CMTS Multicast SAID Authorization Table is used for provisioning, it gives you legal Saids per modem regardless Said is static or dynamic. And "tracking" is completely different mechanism that CMTS should provide? You can implement "tracking" by using this table by Earl's suggestion. If I am wrong, please, correct me. thanks, Anna Stuart Green wrote: > Folks, > The description needs some clarification. > For static SAIDs, you would need to track > both active and inactive CMs. However, > dynamic SAIDs need only track active CMs. > Tracking inactive CMs would be optional. > The goal was to re-use a 1.0/BPI table > (which only supported static SAIDs). The > comment was not in the BPI MIB. > I'll make a note of modifying the comment > in a future revision. > > Stuart > > Anna Ziper wrote: > > > > ------------------------------------------------------------------------ > > > > Subject: FW: multicast mib table question > > Date: Tue, 26 Sep 2000 16:14:40 -0700 > > From: "Mitchell, Earl" > > To: "Ziper, Anna" > > > > > > -----Original Message----- > > From: Mitchell, Earl > > Sent: Monday, September 25, 2000 4:13 PM > > To: 'docsis-sec@cablelabs.com' > > Subject: multicast mib table question > > > > The CMTS Multicast SAID Authorization Table > > has a comment that states: > > > > Note: The CMTS need only track those CMs actively using > > the SAID. > > > > I don't understand this comment. Is this table used by > > operator to specify which CMs are authorized to used > > which SAIDs? Or is it used to show which CM's are > > currently using which SAIDs? > > > > The comment implies that only CMs that are actively > > using this SAID are listed in the table. This table could > > be used for both if you just added another field to state > > whether the CM is currently using the SAID or not. > > > > -earl > > > > > > -- > Stuart M Green > Nortel Networks Corporation - Arris Venture > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 26 21:25:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18718; Tue, 26 Sep 2000 21:25:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27181; Tue, 26 Sep 2000 21:24:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27150 for ; Tue, 26 Sep 2000 21:24:31 -0400 (EDT) Received: from mailhost.ne.arris-i.com (abyss.arris-i.com [206.135.68.99]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18700 for ; Tue, 26 Sep 2000 21:24:29 -0400 (EDT) Received: from ne.arris-i.com (belafonte.ne.arris-i.com [141.251.36.84]) by mailhost.ne.arris-i.com (8.9.3/8.9.3) with ESMTP id VAA14274; Tue, 26 Sep 2000 21:14:06 -0400 Message-ID: <39D14B2D.1B808A95@ne.arris-i.com> Date: Tue, 26 Sep 2000 21:19:41 -0400 From: Stuart Green Organization: Nortel Networks Corporation - Arris Venture X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Anna Ziper CC: docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Subject: Re: [ipcdn] [Fwd: FW: multicast mib table question] References: <39D12FAD.C98A1992@terayon.com> <39D13990.E2C1D52E@ne.arris-i.com> <39D14003.3051826C@terayon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Anna, I do not entirely agree with your statement. The table is meant to be general purpose. Though other possibilities exist, I can only imagine "provisioning" static multicast SAIDs and "tracking" dynamic multicast SAIDs. The real issue is that, to my knowledge, there has been no definition of a back-end CMTS interface to determine dynamic multicast SAID ownership by CMs. The BPI+ standard needs to clarify how dynamic multicast SAIDs are to be discovered by the head-end. The BPI+ MIB table, however, can handle either "provisioned" or "tracked" dynamic multicast SAIDs. It just doesn't make a lot of sense to "provision" anything dynamic. Likewise, it makes little sense to "track" something static. Stuart -- Stuart M Green Nortel Networks Corporation - Arris Venture 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 The DOCSIS BPI+ standard needs to specify Anna Ziper wrote: > > Stuart, > > I want to clarify that the CMTS Multicast SAID Authorization Table is used > for provisioning, it gives you legal Saids per modem regardless Said is static > or dynamic. > And "tracking" is completely different mechanism that CMTS should provide? > You can implement "tracking" by using this table by Earl's suggestion. > If I am wrong, please, correct me. > > thanks, Anna > > Stuart Green wrote: > > > Folks, > > The description needs some clarification. > > For static SAIDs, you would need to track > > both active and inactive CMs. However, > > dynamic SAIDs need only track active CMs. > > Tracking inactive CMs would be optional. > > The goal was to re-use a 1.0/BPI table > > (which only supported static SAIDs). The > > comment was not in the BPI MIB. > > I'll make a note of modifying the comment > > in a future revision. > > > > Stuart > > > > Anna Ziper wrote: > > > > > > ------------------------------------------------------------------------ > > > > > > Subject: FW: multicast mib table question > > > Date: Tue, 26 Sep 2000 16:14:40 -0700 > > > From: "Mitchell, Earl" > > > To: "Ziper, Anna" > > > > > > > > > -----Original Message----- > > > From: Mitchell, Earl > > > Sent: Monday, September 25, 2000 4:13 PM > > > To: 'docsis-sec@cablelabs.com' > > > Subject: multicast mib table question > > > > > > The CMTS Multicast SAID Authorization Table > > > has a comment that states: > > > > > > Note: The CMTS need only track those CMs actively using > > > the SAID. > > > > > > I don't understand this comment. Is this table used by > > > operator to specify which CMs are authorized to used > > > which SAIDs? Or is it used to show which CM's are > > > currently using which SAIDs? > > > > > > The comment implies that only CMs that are actively > > > using this SAID are listed in the table. This table could > > > be used for both if you just added another field to state > > > whether the CM is currently using the SAID or not. > > > > > > -earl > > > > > > > > > > -- > > Stuart M Green > > Nortel Networks Corporation - Arris Venture > > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 26 21:53:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19883; Tue, 26 Sep 2000 21:53:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27542; Tue, 26 Sep 2000 21:52:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27513 for ; Tue, 26 Sep 2000 21:52:36 -0400 (EDT) Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19871 for ; Tue, 26 Sep 2000 21:52:34 -0400 (EDT) Received: from mail-serv.terayon.com (mail-serv.terayon.com [192.168.0.11]) by terayon.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12630; Tue, 26 Sep 2000 18:51:32 -0700 (PDT) Received: from name-asic.terayon.com (name-asic.terayon.com [192.168.66.10]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id SAA13361; Tue, 26 Sep 2000 18:51:32 -0700 (PDT) Received: from terayon.com ([192.168.130.254]) by name-asic.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id SAA21845; Tue, 26 Sep 2000 18:51:31 -0700 (PDT) Message-ID: <39D15284.C350D285@terayon.com> Date: Tue, 26 Sep 2000 18:51:00 -0700 From: Anna Ziper X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stuart Green CC: docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Subject: Re: [ipcdn] [Fwd: FW: multicast mib table question] References: <39D12FAD.C98A1992@terayon.com> <39D13990.E2C1D52E@ne.arris-i.com> <39D14003.3051826C@terayon.com> <39D14B2D.1B808A95@ne.arris-i.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Stuart, I thought that both static and dynamic SAIDs is provisioning information to CMTS. And the only difference between them, that Auth Reply contains static SAIDs. And modem gets dynamic Saids by Sa Map Request. If this table is not for multicast information provisioning, how I can check if the modem authorized to use multicast group. Do you know other tables where such information located? Maybe some IGMP tables? thanks, Anna Stuart Green wrote: > Anna, > I do not entirely agree with your statement. > The table is meant to be general purpose. > Though other possibilities exist, I can only > imagine "provisioning" static multicast SAIDs > and "tracking" dynamic multicast SAIDs. > The real issue is that, to my knowledge, > there has been no definition of a back-end > CMTS interface to determine dynamic multicast > SAID ownership by CMs. The BPI+ standard needs > to clarify how dynamic multicast SAIDs are to > be discovered by the head-end. > The BPI+ MIB table, however, can handle > either "provisioned" or "tracked" dynamic > multicast SAIDs. It just doesn't make a lot > of sense to "provision" anything dynamic. > Likewise, it makes little sense to "track" > something static. > > Stuart > -- > Stuart M Green > Nortel Networks Corporation - Arris Venture > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 > > The DOCSIS BPI+ standard needs to specify > > Anna Ziper wrote: > > > > Stuart, > > > > I want to clarify that the CMTS Multicast SAID Authorization Table is used > > for provisioning, it gives you legal Saids per modem regardless Said is static > > or dynamic. > > And "tracking" is completely different mechanism that CMTS should provide? > > You can implement "tracking" by using this table by Earl's suggestion. > > If I am wrong, please, correct me. > > > > thanks, Anna > > > > Stuart Green wrote: > > > > > Folks, > > > The description needs some clarification. > > > For static SAIDs, you would need to track > > > both active and inactive CMs. However, > > > dynamic SAIDs need only track active CMs. > > > Tracking inactive CMs would be optional. > > > The goal was to re-use a 1.0/BPI table > > > (which only supported static SAIDs). The > > > comment was not in the BPI MIB. > > > I'll make a note of modifying the comment > > > in a future revision. > > > > > > Stuart > > > > > > Anna Ziper wrote: > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > Subject: FW: multicast mib table question > > > > Date: Tue, 26 Sep 2000 16:14:40 -0700 > > > > From: "Mitchell, Earl" > > > > To: "Ziper, Anna" > > > > > > > > > > > > -----Original Message----- > > > > From: Mitchell, Earl > > > > Sent: Monday, September 25, 2000 4:13 PM > > > > To: 'docsis-sec@cablelabs.com' > > > > Subject: multicast mib table question > > > > > > > > The CMTS Multicast SAID Authorization Table > > > > has a comment that states: > > > > > > > > Note: The CMTS need only track those CMs actively using > > > > the SAID. > > > > > > > > I don't understand this comment. Is this table used by > > > > operator to specify which CMs are authorized to used > > > > which SAIDs? Or is it used to show which CM's are > > > > currently using which SAIDs? > > > > > > > > The comment implies that only CMs that are actively > > > > using this SAID are listed in the table. This table could > > > > be used for both if you just added another field to state > > > > whether the CM is currently using the SAID or not. > > > > > > > > -earl > > > > > > > > > > > > > > -- > > > Stuart M Green > > > Nortel Networks Corporation - Arris Venture > > > 6 Riverside Drive, Andover, MA 01810, USA (978) 946-4664 _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 26 21:58:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19930; Tue, 26 Sep 2000 21:58:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27674; Tue, 26 Sep 2000 21:58:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27640 for ; Tue, 26 Sep 2000 21:57:58 -0400 (EDT) Received: from ns.intelenet.net (ns.intelenet.net [204.182.160.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19926 for ; Tue, 26 Sep 2000 21:57:56 -0400 (EDT) Received: from kazbook (at029.cablelabs.com [12.17.244.29] (may be forged)) by ns.intelenet.net (8.9.3/8.9.3) with SMTP id SAA11940; Tue, 26 Sep 2000 18:57:53 -0700 (PDT) From: "Kaz Ozawa" To: "Anna Ziper" , "Kaz Ozawa" Cc: , , , Subject: RE: [ipcdn] multicast without BPI? Date: Tue, 26 Sep 2000 19:53:13 -0600 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <39D0EA56.903913FA@terayon.com> Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Anna, The tables can contain the cable modems which are authorized to join a set of multicast groups corresponding to a single SAID. However, it's an option and the BPI+ MIB does not require the CMTS to do so. That's the intention from the beginning. I understand that the CMTS may have its proprietary interface to communicate with the IP Multicast management server or something like that. If we really need to mandate such a function, I personally think we should specify the interface between the CMTS and such a server as a part of the OSSIv1.1 specification. Thanks, kaz > -----Original Message----- > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > Anna Ziper > Sent: Tuesday, September 26, 2000 12:27 PM > To: Kaz Ozawa > Cc: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; ipcdn@ietf.org; > docsis-macup@cablelabs.com > Subject: Re: [ipcdn] multicast without BPI? > > > > See my comment inline > > thanks, Anna > > Kaz Ozawa wrote: > > > I believe that the IP Multicast works without BPI+ in DOCSIS 1.1. > > The CMTS and the CM must be compliant to the section 3.3.1 of the > DOCSIS RFIv1.1 > > spec. > > Those requirements are independent from the BPI+ and the BPI+ can be either > > turned on nor off. > > > > If the BPI+ is turned on, the BPI+ MIB's multicast related tables > can be used to > > manage > > the authorization of the cable modems per SAID. However, it's not > a requirement > > in the > > DOCSIS. > > > > If we turn off the BPI+ in DOCSIS 1.1, I believe that all the BPI+ > MIB tables > > are not > > required. However, I think there is no problem to implement if a > vendor want to > > do so. > > > > By the way, If the BPI+ is turned off, how can we block the IP > multicast packet > > forwarding to a specific CM (or CPE beyond the CM)? > > The problem is that cable modem multicast authorization depends on BPI > multicast tables. > If there is another authorization table connecting IP multicast > address and cable > modem identification? > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > > > Anna Ziper > > > Sent: Friday, September 22, 2000 8:06 PM > > > To: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; ipcdn@ietf.org > > > Subject: [ipcdn] multicast without BPI? > > > > > > > > > > > > Hi everybody, > > > > > > Can multicast work without BPI? I.e. packages in multicast can be > > > non encrypted? > > > If yes, what happens with a modem authorization per multicast group? > > > > > > Can we still use Bpi multicast mib tables for authorization purpose? > > > > > > Thanks, > > > Anna > > > > > > > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org > > > http://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > http://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Sep 26 22:16:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20166; Tue, 26 Sep 2000 22:16:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28037; Tue, 26 Sep 2000 22:14:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28009 for ; Tue, 26 Sep 2000 22:14:25 -0400 (EDT) Received: from scbh01.terayon.com (labs.terayon.com [63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20136 for ; Tue, 26 Sep 2000 22:14:23 -0400 (EDT) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Sep 2000 19:11:32 -0700 Message-ID: <37063C40296BD411A68400D0B7AF537A594D04@SCEXCH01.terayon.com> From: "Goren, Aviv" To: "'Kaz Ozawa'" , "Ziper, Anna" , docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Cc: docsis-macup@cablelabs.com Subject: RE: [ipcdn] multicast without BPI? Date: Tue, 26 Sep 2000 19:11:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="koi8-r" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Kaz, Section 3.3.1 does not refer to multicast forwarding but to IGMP requirements. Together, BPI and 3.3.1 are completing the IGMP (signaling) and forwarding (authentication and group definition) picture. I believe the question is still un-answered: how can a group be provisioned to be forwarded by the CMTS if BPI MIB is disabled ? As for your question Kaz, "If the BPI+ is turned off, how can we block the IP multicast packet forwarding to a specific CM (or CPE beyond the CM)?" I believe the answer is "we can not" ! if BPI is disabled all modem can get a multicast stream since traffic is not encrypted and is addressed to a multicast MAC address. My proposal will therefore be: BPI is used for modem membership. BPI group definition is used only with respect to BPI authentication. A new MIB is to be proposed for group definition. The new MIB will define the group for forwarding. When BPI is disabled, all modems are receiving the multicast stream. -Aviv. -----Original Message----- From: Kaz Ozawa [mailto:kaz@pobox.com] Sent: Tuesday, September 26, 2000 11:08 AM To: Anna Ziper; docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; ipcdn@ietf.org Cc: docsis-macup@cablelabs.com Subject: RE: [ipcdn] multicast without BPI? I believe that the IP Multicast works without BPI+ in DOCSIS 1.1. The CMTS and the CM must be compliant to the section 3.3.1 of the DOCSIS RFIv1.1 spec. Those requirements are independent from the BPI+ and the BPI+ can be either turned on nor off. If the BPI+ is turned on, the BPI+ MIB's multicast related tables can be used to manage the authorization of the cable modems per SAID. However, it's not a requirement in the DOCSIS. If we turn off the BPI+ in DOCSIS 1.1, I believe that all the BPI+ MIB tables are not required. However, I think there is no problem to implement if a vendor want to do so. By the way, If the BPI+ is turned off, how can we block the IP multicast packet forwarding to a specific CM (or CPE beyond the CM)? Thanks, kaz > -----Original Message----- > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > Anna Ziper > Sent: Friday, September 22, 2000 8:06 PM > To: docsis-sec@cablelabs.com; docsis-oss@cablelabs.com; ipcdn@ietf.org > Subject: [ipcdn] multicast without BPI? > > > > Hi everybody, > > Can multicast work without BPI? I.e. packages in multicast can be > non encrypted? > If yes, what happens with a modem authorization per multicast group? > > Can we still use Bpi multicast mib tables for authorization purpose? > > Thanks, > Anna > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > http://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Wed Sep 27 17:38:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22926; Wed, 27 Sep 2000 17:38:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16705; Wed, 27 Sep 2000 17:36:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16677 for ; Wed, 27 Sep 2000 17:36:32 -0400 (EDT) Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22885 for ; Wed, 27 Sep 2000 17:36:30 -0400 (EDT) Received: from mail-serv.terayon.com (mail-serv.terayon.com [192.168.0.11]) by terayon.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07414; Wed, 27 Sep 2000 14:35:29 -0700 (PDT) Received: from name-asic.terayon.com (name-asic.terayon.com [192.168.66.10]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id OAA29773; Wed, 27 Sep 2000 14:35:28 -0700 (PDT) Received: from terayon.com ([192.168.130.41]) by name-asic.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id OAA05076; Wed, 27 Sep 2000 14:35:28 -0700 (PDT) Message-ID: <39D2681E.E85EED0A@terayon.com> Date: Wed, 27 Sep 2000 14:35:26 -0700 From: Earl Mitchell X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stuart Green CC: Anna Ziper , docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Subject: Re: [ipcdn] [Fwd: FW: multicast mib table question] References: <39D12FAD.C98A1992@terayon.com> <39D13990.E2C1D52E@ne.arris-i.com> <39D14003.3051826C@terayon.com> <39D14B2D.1B808A95@ne.arris-i.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Stuart Green wrote: > The BPI+ MIB table, however, can handle > either "provisioned" or "tracked" dynamic > multicast SAIDs. It just doesn't make a lot > of sense to "provision" anything dynamic. > Likewise, it makes little sense to "track" > something static. There is a problem though. The two table mappings define a relationship that looks like this: multicast ip -> SAID -> CM Now assuming the operator must use these two tables to define which which CMs are authorized to access which multicast groups you have to predetermine what the SAID assignment should be. This is also a problem if BPI is disabled and this table must be used to determine which multicast group a CM is authorized to access. If the tables were changed to represent this relationship: CM -> multicast group -> SAID Then all the problems would be fixed. You could use this table for provisioning CM authorization, provisioning which multicast group's use which SAIDs, and tracking which CM's are using which SAIDs. Does anyone know if another MIB table exist which can be used to provision which CMs can access which multicast groups? -earl _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Wed Sep 27 18:03:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23280; Wed, 27 Sep 2000 18:03:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16981; Wed, 27 Sep 2000 17:57:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16953 for ; Wed, 27 Sep 2000 17:57:31 -0400 (EDT) Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23183 for ; Wed, 27 Sep 2000 17:57:28 -0400 (EDT) Received: from mail-serv.terayon.com (mail-serv.terayon.com [192.168.0.11]) by terayon.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07942; Wed, 27 Sep 2000 14:56:28 -0700 (PDT) Received: from name-asic.terayon.com (name-asic.terayon.com [192.168.66.10]) by mail-serv.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id OAA00197; Wed, 27 Sep 2000 14:56:12 -0700 (PDT) Received: from terayon.com ([192.168.130.41]) by name-asic.terayon.com (8.9.3+Sun/8.9.1) with ESMTP id OAA05380; Wed, 27 Sep 2000 14:56:12 -0700 (PDT) Message-ID: <39D26CFB.3B73E8ED@terayon.com> Date: Wed, 27 Sep 2000 14:56:11 -0700 From: Earl Mitchell X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stuart Green , Anna Ziper , docsis-sec@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org Subject: Re: [ipcdn] [Fwd: FW: multicast mib table question] References: <39D12FAD.C98A1992@terayon.com> <39D13990.E2C1D52E@ne.arris-i.com> <39D14003.3051826C@terayon.com> <39D14B2D.1B808A95@ne.arris-i.com> <39D2681E.E85EED0A@terayon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Earl Mitchell wrote: > > If the tables were changed to represent this > relationship: > > CM -> multicast group -> SAID > > Then all the problems would be fixed. You could > use this table for provisioning CM authorization, > provisioning which multicast group's use which > SAIDs, and tracking which CM's are using which > SAIDs. Correction: Because you are using the tables for provisioning and tracking you still need to add a field to keep track of which CM's are currently using the multicast group. Without this you just know which CMs are provisioned to use the multicast group. -earl _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From owner-ipcdn@terayon.com Thu Sep 28 00:47:30 2000 Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00502 for ; Thu, 28 Sep 2000 00:47:29 -0400 (EDT) Received: (from root@localhost) by terayon.com (8.9.3+Sun/8.9.3) id TAA12695 for ipcdn-outgoing; Wed, 27 Sep 2000 19:00:25 -0700 (PDT) Date: Wed, 27 Sep 2000 19:00:19 -0700 From: Jim Kuhfeld To: docsis-oss@cablelabs.com, stjohns@corp.home.net, ipcdn@terayon.com Subject: Question about rfc2670 Message-ID: <20000927190019.C17168@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com Is there a reason for the inconsistent syntax? The only way to legally implement this appears to be to restrict the syntax of docsIfCmtsCmStatusIndex to 1.65535. That is a serious restriction given the requirement, "For an individual Cable Modem, this index value should not change during CMTS uptime." docsIfCmtsServiceCmStatusIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Pointer to an entry in docsIfCmtsCmStatusTable identifying the Cable Modem using this Service Queue. If multiple Cable Modems are using this Service Queue, the value of this object is zero." ::= { docsIfCmtsServiceEntry 2 } docsIfCmtsCmStatusIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index value to uniquely identify an entry in this table. For an individual Cable Modem, this index value should not change during CMTS uptime." ::= { docsIfCmtsCmStatusEntry 1 } From ipcdn-admin@ietf.org Thu Sep 28 14:37:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29139; Thu, 28 Sep 2000 14:37:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05987; Thu, 28 Sep 2000 14:32:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05959 for ; Thu, 28 Sep 2000 14:32:56 -0400 (EDT) Received: from scbh01.terayon.com (labs.terayon.com [63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29067 for ; Thu, 28 Sep 2000 14:32:54 -0400 (EDT) Received: by SCOWA.terayon.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Sep 2000 11:29:26 -0700 Message-ID: <37063C40296BD411A68400D0B7AF537A679625@SCEXCH01.terayon.com> From: "Gummadidala, Kishore" To: "'docsis-macup@cablelabs.com'" , "'docsis-oss@cablelabs.com'" , "'ipcdn@ietf.org'" Date: Thu, 28 Sep 2000 11:29:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] Question about interaction between External Classifiers and Polic y Based Classifiers Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Hi All, I have a question which can be better asked by means of a scenario (at least I hope it will be).. So please read on and let me know what you think ought to happen.. Consider the following case. Classifiers 2,5,10,13 in the DocsDevFilterIpTable all have the continue bit ON. Classifiers 2,10 have the their policies (via docsDevFilterPolicyTable) pointing to the DocsQosServiceClassPolicyTable entries 1,2 respectively. These entries specify 1:{GoldServiceClassName,2} 2:{SilverServiceClassName,1} Classifier 13 has a ToS overwrite policy. Classifier 5 does not have any policy associated with it. In summary the relevant entries of the DocsDevFilterTable look like this: Continue Policy 2: Y DocsQosServiceClassPolicyTable[2] 5: Y - 10: Y DocsQosServiceClassPolicyTable[1] 13: Y DocsDevFilterTosTable[1] Now a packet comes in which matches Classifiers 2,5,10,13 only. When it finally hits the DOCSIS MAC layer, what will be passed in the MAC_DATA.request?? a) Will it be {GoldServiceClassName,2} which is the last QoS policy that would have applied? OR b) Will no SCN/RulePriority combo be passed to the MAC layer since the last CD classifier that matched did not have an associated QoS policy? Any thoughts you might have on this will be much appreciated. Best Regards, -Kishore. _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn