Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt

From: "Nakanishi, Greg" <[email-masked]>
Date: Fri, 10 Nov 2000 14:42:33 -0500

With regard to the multicast tables in the BPI+ MIB...

I don't think the multicast mapping table, as defined in the BPI+ MIB, can
be used to support both BPI and BPI+ simultaneously.  BPI maps an IP address
to a SID; whereas BPI+ maps an IP address to a SAID.  With the exception of
the primary SID, there is no relationship between a SAID and SID.  

It is possible that an IP multicast address has to map to a SAID for BPI+
CMs and to a SID for BPI CMs.  This would result in two entries in the
multicast mapping table for the same IP address without being able to
differentiate whether the associated mapping is a SID or SAID.

One solution would be to add another object in the mapping table to identify
whether it is a SAID or SID.

A higher level question is are any operators planning to do multicast to 1.0
CMs?  If not, this would be a non-issue. The multicast mapping table could
remain as-is and only map to SAIDs.

greg

Greg Nakanishi
Motorola Cable Modem Engineering
6450 Sequence Drive, San Diego, CA 92121
(858) 404-2366

> -----Original Message-----
> From: Schmitt, Matt [mailto:[email-masked]]
> Sent: Friday, November 10, 2000 8:03 AM
> To: 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna
> Cc: [email-masked]; [email-masked]; 
> [email-masked]'
> Subject: RE: [ipcdn] possible issue with new version of BPI MIB:
> draft-iet f-ipcdn-mcns-bpi-mib-02.txt
> 
> 
> 	I disagree.
> 	The reason for that is that it is possible for a CMTS 
> to support a
> CM in BPI mode using the BPI+ MIB.  For the Base, Auth, and 
> TEK tables, all
> of the objects included in the BPI MIB are also included in 
> the BPI+ MIB.
> The BPI+ MIB merely expands some of these tables to add some 
> new objects
> (which simply aren't populated for a BPI CM).  In fact, one of the new
> objects indicates whether a modem is running BPI or BPI+, 
> which indicates to
> me that the table was designed to handle both types of modems
> simultaneously.  I believe there are other examples like this as well.
> 	For me, the only questions on these MIBs might relate to the
> multicast tables in the BPI MIB.  The first question is 
> whether or not a 1.1
> CMTS can restrict encrypted multicast traffic to just 1.1 BPI+ CMs (as
> referenced by Rich) and still be conformant to the spec.  I'd 
> really like to
> hear some comments on that, since I've been trying to find an 
> answer in the
> specs to that question without much luck.  The next question would be
> whether or not the multicast tables in the BPI+ MIB could 
> support 1.0 CMs if
> that capability was implemented.  At a quick glance, it 
> appears that they
> probably could, as long as the SAID in the BPI+ table 
> translates to the SID
> of the BPI table.
> 	Thoughts?
> 
> Matt 
> 
> -----Original Message-----
> From: Rich Woundy [mailto:[email-masked]]
> Sent: Thursday, November 09, 2000 7:40 PM
> To: Holborow, Clive (SD-EX); Ziper, Anna
> Cc: [email-masked]; [email-masked]
> Subject: RE: [ipcdn] possible issue with new version of BPI MIB:
> draft-ietf-ipcdn-mcns-bpi-mib-02.txt
> 
> 
> Clive,
> 
> You make a good argument. A DOCSIS 1.1 CMTS probably ought to 
> implement 
> both the BPI MIB and the BPI+ MIB, in anticipation of the 
> simultaneous 
> management of both DOCSIS 1.0 and 1.1 modems on the CMTS 
> side. That would 
> include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and 
> docsBpiCmtsTEKTable, but hopefully *not* 
> docsBpiIpMulticastMapTable nor 
> docsBpiMulticastAuthTable (assuming that downstream multicast 
> encryption is 
> restricted to DOCSIS 1.1/BPI+ CMs).
> 
> Does anyone disagree?
> 
> However, my statement ("a DOCSIS 1.1 CMTS is only required to 
> support the 
> BPI+ MIB") is still literally true, until someone submits an 
> ECR against 
> the DOCSIS 1.1 OSS spec.
> 
> I think this issue has to be resolved on the docsis-oss mailing list.
> 
> -- Rich
> 
> At 06:15 PM 11/9/00 -0500, Holborow, Clive (SD-EX) wrote:
> >It seems the OSS spec. writers need to talk to the BPI+ spec writers.
> >See p146 of sp-bpi+-i05-000714.  Item b) says in part:
> >"..., a CMTS with Baseline Privacy Plus MUST be capable of 
> falling back
> into
> >a Baseline Privacy compatible mode of operation."
> >
> >Is this possible without support of the BPI MIB?
> >The BPI MIB is all 1.0 CMs know about, and it has always 
> been required that
> >a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs.
> >
> >The diagram on p37 of the 1.1 OSS spec makes it clear that 
> 1.1 CMs must
> >support both BPI and BPI+ MIBs.
> >It doesn't make sense to me that the 1.1 CMTS does not also 
> need to support
> >both MIBs, since it should support a 1.1 CM operating in 
> 1.0/BPI mode.
> >
> >Clive Holborow
> >Motorola
> >
> > >  -----Original Message-----
> > >  From: Rich Woundy [mailto:[email-masked]]
> > >  Sent: Thursday, November 09, 2000 12:22 PM
> > >  To: Ziper, Anna; [email-masked]
> > >  Subject: RE: [ipcdn] possible issue with new version of BPI MIB:
> > >  draft-iet f-ipcdn-mcns-bpi-mib-02.txt
> > >
> > >
> > >  Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+
> > >  MIB, per the
> > >  DOCSIS OSS specification.
> > >
> > >  See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714,
> > >  <http://www.cablemodem.com/SP-OSSIv1.1-I02-000714.pdf>.
> > >
> > >  -- Rich
> > >
> > >  At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote:
> > >
> > >  >Hi,
> > >  >
> > >  >A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and
> > >  not BPI MIB.
> > >  >Is it right?
> > >  >
> > >  >Thanks,
> > >  >Anna
> > >  >
> > >  >-----Original Message-----
> > >  >From: Rich Woundy [mailto:[email-masked]]
> > >  >Sent: Monday, November 06, 2000 3:11 PM
> > >  >To: [email-masked]
> > >  >Subject: [ipcdn] possible issue with new version of BPI MIB:
> > >  >draft-ietf-ipcdn-mcns-bpi-mib-02.txt
> > >  >
> > >  >
> > >  >Folks,
> > >  >
> > >  >I just submitted a new version of the BPI MIB,
> > >  >draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft.
> > >  This revision
> > >  >is as a result of a review with the IETF MIB doctor. Most
> > >  of the changes
> > >  >were minor textual changes, and will be listed in a 
> separate email.
> > >  >
> > >  >However, I did want to point out a particular 
> modification to the
> > >  >DESCRIPTION of two MIB objects. In particular, I added the
> > >  sentence, "There
> > >  >is no restriction on the ability to change values in this
> > >  row while the row
> > >  >is active", to the two RowStatus objects in the multicast
> > >  portion of the
> > >  >BPI MIB:
> > >  >
> > >  >docsBpiIpMulticastMapControl    OBJECT-TYPE
> > >  >SYNTAX                          RowStatus
> > >  >MAX-ACCESS                      read-create
> > >  >STATUS                          current
> > >  >DESCRIPTION
> > >  >"This object controls and reflects the IP multicast 
> address prefix
> > >  >mapping entry. There is no restriction on the ability to
> > >  change values
> > >  >in this row while the row is active."
> > >  >::= { docsBpiIpMulticastMapEntry 4 }
> > >  >
> > >  >docsBpiMulticastAuthControl     OBJECT-TYPE
> > >  >SYNTAX                          RowStatus
> > >  >MAX-ACCESS                      read-create
> > >  >STATUS                          current
> > >  >DESCRIPTION
> > >  >"This object controls and reflects the CM authorization for each
> > >  >multicast SID. There is no restriction on the ability to change
> > >  >values in this row while the row is active."
> > >  >::= { docsBpiMulticastAuthEntry 3 }
> > >  >
> > >  >According to the definition of "RowStatus" in RFC 2579, the
> > >  DESCRIPTION
> > >  >clause of a RowStatus column needs to "specify whether the
> > >  status column
> > >  >must not be `active' in order for the value of some other
> > >  column of the
> > >  >same conceptual row to be modified."
> > >  >
> > >  >I followed the example of the Cable Device MIB, RFC 2669,
> > >  which typically
> > >  >specifies that values in a row of a table can be changed
> > >  while the row is
> > >  >active. For example, see docsDevNmAccessStatus,
> > >  docsDevFilterLLCStatus,
> > >  >docsDevFilterIpStatus, and docsDevFilterTosStatus. A
> > >  counter-example is the
> > >  >docsIfQosProfStatus in RFC 2670, which does not permit
> > >  modifications when
> > >  >there are dependencies from the docsIfCmServiceTable and
> > >  >docsIfCmtsServiceTable on the docsIfQosProfileTable.
> > >  >
> > >  >My opinion was to follow the lead of the Cable Device MIB.
> > >  >
> > >  >Does anyone on the mailing list disagree?
> > >  >
> > >  >-- Richard Woundy
> > >  >
> > >  >
> > >  >_______________________________________________
> > >  >IPCDN mailing list
> > >  >[email-masked]
> > >  >http://www1.ietf.org/mailman/listinfo/ipcdn
> > >
> > >
> > >
> > >  _______________________________________________
> > >  IPCDN mailing list
> > >  [email-masked]
> > >  http://www1.ietf.org/mailman/listinfo/ipcdn
> > >
> 

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

---

From: "Kaz Ozawa" <[email-masked]>
Date: Fri, 10 Nov 2000 13:00:52 -0700

Greg,

I supposed that the CMTS could (and must) manage the relation
between SAIDs for 1.1 CMs with BPI+ and SIDs for 1.0 CMs with
BPI.

The docsBpi2CmtsTEKTable is supposed to contain both the entries
for 1.1 CMs with BPI+ and 1.0 CMs with BPI. In case of the entry
for the 1.0 CM, docsBpi2CmtsTEKSAId will have the value for the
SID instead of SAID. Because docsBpi2CmtsTEKSAId is one of the
indeces of the table, it must be unique. That is, all the SID
values must be different from all the SAID values.
Is this a problem?

Thanks,
kaz

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Nakanishi, Greg
> Sent: Friday, November 10, 2000 12:43 PM
> To: 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive (SD-EX); Ziper, Anna
> Cc: [email-masked]; [email-masked]; [email-masked]'