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

From: "White, David" <[email-masked]>
Date: Fri, 10 Nov 2000 11:07:30 -0600

Not only do I just disagree, I vehemently disagree. The BPI+ MIB was
designed to handle both 1.0 and 1.1 CMs and replace the BPI MIB for
1.1 CMTSs. Requiring both MIBs would open the window to inconsistencies,
require extra CMTS vendor work, extra CableLabs testing work, and
most importantly, confuse customers. Until someone explains to me a
concrete benefit of a 1.1 CMTS supporting both the BPI+ MIB and the BPI
MIB, I will continue to vehemently disagree.

David

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Friday, November 10, 2000 10: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: "Ziper, Anna" <[email-masked]>
Date: Sat, 11 Nov 2000 16:13:51 -0800

Kaz,

To support BPI Multicast Mib in BPI+ Multicast Mib 
is very complicate and expensive in development.
The question is how benefit the multicast feature in Bpi,
and it is reasonable to leave this feature separated in BPI and BPI+. 

see my comments inline <anna>

Thank you, 
Anna

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, November 10, 2000 1:03 PM
To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; '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-ietf-ipcdn-mcns-bpi-mib-02.txt

Greg,

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Nakanishi, Greg
> Sent: Friday, November 10, 2000 1:19 PM
> To: 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive
> (SD-EX); Ziper, Anna
> Cc: [email-masked]; [email-masked]; [email-masked]
> Kaz,
> Isn't what you're suggesting essentially equivalent of getting rid of the
> concept of SAIDs and just using SIDs like it was in BPI?

Well..., yes and no.
1.0/BPI CM have to continue to rely on the SIDs. And the 1.1
CMTS which MUST be compatible to 1.0/BPI have to handle them.
And the 1.1 CMTS must not use the same number for both SID and
SAID. But, other than that, the SIDs and the SAIDs are
isolated by definition.

<anna> It is very good idea to use different numbers for SID and SAID,
(only primary SAID is equal to SID),
I'd separate between static and dynamic SAIDs ranges too.

>
> Another thing I noticed was that the index for the IP multicast mapping
> table will not allow two entries with the same IP address. That is, there
> couldn't be an entry that maps an IP address to an SAID and another entry
> that maps the same IP address to a SID.

This is a good point.
Because of the difference of the key management rules between the BPI and
the BPI+, it's not realistic to use the same number as both the SAID and the
SID.
The addition of the new object for the SID may be the solution.

<anna> The object with type of Said can be very helpful, not even either SID
or Said,
but distinguish between dynamic, static and primary SAID.

Thanks,
kaz

> greg
> > From: Kaz Ozawa [mailto:[email-masked]]
> > Sent: Friday, November 10, 2000 12:01 PM
> > To: Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy'; Holborow, Clive
> > (SD-EX); Ziper, Anna
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > 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
> > > 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
> > >
> > >
> > > > Sent: Friday, November 10, 2000 8:03 AM

---

From: "Schmitt, Matt" <[email-masked]>
Date: Mon, 13 Nov 2000 11:08:45 -0600

Anna,
	A few comments...
	Admittedly, I'm not a developer.  But on the CMTS side, I'd think it
would be a lot easier to implement just one set of MIB tables that handle
all modems regardless of BPI or BPI+, vs. having separate tables for each
type of modem.  It also makes an operators job and life easier if they're
combined.  And I think this is the way the CMTS tables were designed.
	Regarding the benefit of BPI encrypted multicast, I think there's
probably very little.  As I understand it, there are very few (if any) MSO's
using multicast with 1.0 systems, because of the lack of good support and
definition.  If that's true, it's unlikely that there will be much (if any)
demand for using multicast with 1.0 modems, and I think it would be a wholly
legitimate 1.1 CMTS implementation not to support multicast to 1.0 CMs at
all (or at least no support for encrypted multicast to 1.0 CMs).  If we can
come to that conclusion, it might make a lot of this discussion a lot
easier.
	As for different ranges for different types of SAIDs, I'd look at
that as an implementation issue rather than a spec issue.
	And as for distinguishing between different types of SAIDs, there
actually is already a MIB object in the TEK table that does this.  The
docsBpi2CmtsTEKSAType object has options for none, Primary, Static, or
Dynamic.  What's interesting to note is that in the description of the
object, there is a statement to the effect that "Dynamic does not apply to
CMs running in BPI mode."  The implication, of course, is that the types of
Primary and Static DO apply to CMs running in BPI mode.  In other words,
setting up a static SAID is the same as setting up a SID for multicast
traffic on a 1.0 modem.  So perhaps that's the right answer -- the static
SAID and the 1.0 SID for multicast encryption are the same, which would
allow usage of the BPI+ MIB in place of the BPI MIB on the CMTS.

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Saturday, November 11, 2000 6:14 PM
To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy';

Kaz,

Thank you, 
Anna

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, November 10, 2000 1:03 PM
To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy';

Greg,

Well..., yes and no.

This is a good point.

Thanks,
kaz

---

From: "Ziper, Anna" <[email-masked]>
Date: Mon, 13 Nov 2000 11:26:35 -0800

Matt,

	I agree with you that NOT supporting DOCSIS1.0 multicast issue in
DOCSIS1.1 CMTS simplifies things. 
	Kaz, what is your opinion?
	
	Multicast SAID type in the TEK table does not help a lot. The table
IpMulticastTable maps multicast Ip address to a SAID. The question: how do
you know which multicast it is when you create row in the table? The TEK
table gets knowledge about type of SAID, but not about type of multicast
address.

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 9:09 AM
To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich
Woundy'; Holborow, Clive (SD-EX)
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

Anna,
	A few comments...

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Saturday, November 11, 2000 6:14 PM
To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy';

Kaz,

Thank you, 
Anna

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, November 10, 2000 1:03 PM
To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy';

Greg,

Well..., yes and no.

This is a good point.

Thanks,
kaz

---

From: "Schmitt, Matt" <[email-masked]>
Date: Mon, 13 Nov 2000 17:06:55 -0600

My understanding of the definition of a static SAID is that it's one
that's statically provisioned in the table.  On the flip side, a dynamic
SAID is automatically generated from learned information -- no operating
input is involved.  So by that defintion, if you're setting anything in the
multicast MAP table, it's static.  If it's populated by some other external
action, then it's dynamic.
	Or put another way, for a static SAID, you populate the table, and
for a dynamic SAID, the CMTS populates the table.
	BTW, when you mention "you've created entry for the SAID in the TEK
table", do you mean when you the operator adds an entry, or when the CMTS
adds an entry?  Because my assumption is that once the SAID is created
(either by static or dynamic means), a TEK state machine should be initiated
on the CMTS, and the TEK table should automatically be populated by the CMTS
as a part of that process.

	As for the Primary SAID issue...  My assumption is that if the SAID
# that you enter into the MulticastMapTable is the same as a Primary SAID,
then it'll use the keying material for that Primary SAID.  If so, this
illustrates the potentially extreme danger of using static SAIDs -- if you
accidentally use a Primary SAID when you don't mean to, I'm not quite sure
what would happen.  I guess you could think of that as a sharp stick for the
operator.

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 4:37 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

The BPI+ mib for docsBpiCmtsIpMulticastMapTable says
"This table maps multicast IP addresses to SAIDs.
It is intended to map BOTH dynamic and static multicast IP addresses."
It is also says:
"For dynamic multicast IP addresses, create access does not apply."

It is clear that after you have the Ip multicast address mapping to SAID
and you've created entry for the SAID in the TEK table you can find the type
of SAID.
But how you configure both tables. 
For example, CMTS gets snmpset for docsBpiCmtsIpMulticastMapTable 
for the multicast address, how do you know what kind of SAID this multicast
address
is going to use and if you should create it by yourself or wait for setting.

An additional question: if this table can use primary SAID. I haven't found
opposite,
so I assume yes. 

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 2:14 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

	As far as I'm aware, a multicast address is a multicast address --
it isn't static or dynamic.  Static or dynamic just refers to the type of
SAID being used:  Static SAIDs are input into the table manually, and
Dynamic SAIDs are added automatically.  So as long as we've got a mapping
from the multicast address to a SAID, we can use the TEK table to map that
to the SA Type.
	Please, someone correct me if I'm going down the wrong road here. :)

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 3:29 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

I guess multicast address can be static or dynamic as well 
as type of Said. I think static or dynamic it is like type of application.

Am I right?

Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:16 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Anna,
	I'm not sure I quite follow you...  What are you referring to by
"type of multicast address"?
	Thanks.

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:27 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt,

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 9:09 AM
To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich

Anna,
	A few comments...

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Saturday, November 11, 2000 6:14 PM
To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy';

Kaz,

Thank you, 
Anna

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, November 10, 2000 1:03 PM
To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy';

Greg,

Well..., yes and no.

This is a good point.

Thanks,
kaz

---

From: "Schmitt, Matt" <[email-masked]>
Date: Mon, 13 Nov 2000 16:14:01 -0600

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 3:29 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Am I right?

Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:16 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Anna,

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:27 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt,

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 9:09 AM
To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich

Anna,
	A few comments...

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Saturday, November 11, 2000 6:14 PM
To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy';

Kaz,

Thank you, 
Anna

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, November 10, 2000 1:03 PM
To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy';

Greg,

Well..., yes and no.

This is a good point.

Thanks,
kaz

---

From: "Ziper, Anna" <[email-masked]>
Date: Mon, 13 Nov 2000 14:37:25 -0800

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 2:14 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 3:29 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Am I right?

Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:16 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Anna,

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:27 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt,

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 9:09 AM
To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich

Anna,
	A few comments...

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Saturday, November 11, 2000 6:14 PM
To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy';

Kaz,

Thank you, 
Anna

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, November 10, 2000 1:03 PM
To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy';

Greg,

Well..., yes and no.

This is a good point.

Thanks,
kaz

---

From: "Schmitt, Matt" <[email-masked]>
Date: Mon, 13 Nov 2000 10:55:25 -0600

Kaz,
	Maybe I'm overlooking something, but I don't understand why a CMTS
can't use the same number for a SID and a SAID.  In fact, if a multicast
SAID can be the same as the SID for a DS multicast flow, I don't see why the
table in the BPI+ MIB can't be used for both BPI and BPI+ multicast.

	My apologies to everyone, but I need to kind of walk through this
from the beginning, because I want to touch on some unicast and multicast
issues with this.  With unicast flows in DOCSIS 1.1, the SAID for all
unicast traffic is the Primary SAID, which is equal to the SID of the
primary US flow, and is used for all unicast US and DS traffic.  In the 1.0
world, the SID (an US construct) is used as the security identifier for both
US and DS traffic (though it is theoretically possible to have multiple SIDs
in 1.0, I have the impression that the spec was written assuming 1, which is
used for the DS as well).  This makes the SID essentially the same as the
Primary SAID, and I don't see a reason why in the unicast tables the 1.0 SID
can't be used in the fields that call for the SAID.
	As for multicast, in 1.0, a SID is created specifically as a
security identifier for a DS multicast traffic flow -- it has not US
component.  In 1.1, we create a SAID specifically as a security identifier
for a DS multicast traffic flow.  Excepting the fact that SAIDs come in two
flavors (dynamic and static), is a multicast SID and a multicast SAID
essentially the same thing?  And why wouldn't it be possible to report a
multicast SAID to a  1.0 CM as a multicast SID?  And populate the tables in
the BPI+ MIB with just the SAID, which would be seen by a 1.0 CM as a SID?
	Of course, the biggest issue is that of dynamic vs. static SAIDs,
and their relationship to multicast SIDs.  Thinking off the top of my head,
I can see a couple of possible implementations.  One would be to only
associate static SAIDs with multicast SIDs (ie, a 1.0 CM can only do
encrypted multicast with static SAIDs).  Another would be for the CMTS to
not differentiate between the two when reporting SIDs for multicast flows to
a CM -- it reports the static one on the auth renewal after it's been input,
and reports the dynamic one on the auth renewal after it's been generated in
the CMTS.
	As I said, maybe I'm missing something, but I think this would work,
and would appear to be a simple implementation than trying to maintain two
completely separate functions.  To be usable, they need to be merged
together somehow on the CMTS end, IMHO.

	Then again, there's another, even much bigger issue -- the whole
concept of a 1.1 CMTS doing encrypted multicast with a 1.0 CM.  Is that
capability even realistic?  Is it desireable?  For that matter, is it even
required?  Reading through the specs, I'm not convinced that it is required.
I think it's unlikely that anyone's actually going to want to use such a
function either.  If that's the case, I'm less worried about spending a lot
of time defining this.  So before arguing anything else, perhaps those are
the questions we really need to answer first.

Matt

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, November 10, 2000 3:03 PM
To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy';

Greg,

Well..., yes and no.

This is a good point.

Thanks,
kaz

---

From: "Schmitt, Matt" <[email-masked]>
Date: Mon, 13 Nov 2000 15:16:15 -0600

Anna,

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:27 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt,

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 9:09 AM
To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich

Anna,
	A few comments...

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Saturday, November 11, 2000 6:14 PM
To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy';

Kaz,

Thank you, 
Anna

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, November 10, 2000 1:03 PM
To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy';

Greg,

Well..., yes and no.

This is a good point.

Thanks,
kaz

---

From: "Schmitt, Matt" <[email-masked]>
Date: Mon, 13 Nov 2000 17:56:46 -0600

1.  I can't say I'm familiar with how this would be implemented, but that
sounds plausible.

2.  In the BPI+ MIB (ver. 03), I think the equivalent to this is the
PrefixLength parameter.  My assumption is that for a dynamic SAID, this
would most likely be 255.255.255.255.

3.  Interesting point...

	As for the SAID ranges, I understand the logic -- it would protect
operators.  The question is, do we need to mandate that in the spec?  Or is
a sharp stick, and an opportunity for vendor differentiation (ie, an
implementation issue)?  I don't see why someone couldn't implement things
this way, but I don't think they have to either.

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 5:32 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt,

The way you are describing, it is implicit way to learn if the SAID is 
static or dynamic. I guess, it works.
But I still have a few points that I don't understand.

1. How you can make your table read-only only for dynamic SAIDs.
   So every time you access to the docsBpiCmtsIpMulticastMapTable
   you should check in the TEK table if the SAID is dynamic or static. 
2. There is a parameter called filter in docsBpiCmtsIpMulticastMapTable.
   It is a mask on Ip multicast addresses. In case of dynamic SAID
   this parameter is not used?
3. In the way the docsBpiCmtsIpMulticastMapTable is built, 
   it is possible that different ifIndexes 
   for the same Ip multicast address use different SAID. 
   This state complicates things.

About primary SAIDs...
In case there are different ranges between SID (primary SAID), static SAID
and dynamic SAID,
their usage cannot be confused. What for I want to separate ranges.

About TEK machine...
I agree with your definition.

thanks, 
Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 3:07 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

as a part of that process

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 4:37 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 2:14 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 3:29 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Am I right?

Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:16 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Anna,

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:27 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt,

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 9:09 AM
To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich

Anna,
	A few comments...

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Saturday, November 11, 2000 6:14 PM
To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy';

Kaz,

Thank you, 
Anna

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, November 10, 2000 1:03 PM
To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy';

Greg,

Well..., yes and no.

This is a good point.

Thanks,
kaz

---

From: "Ziper, Anna" <[email-masked]>
Date: Mon, 13 Nov 2000 13:28:49 -0800

Am I right?

Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:16 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Anna,

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:27 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt,

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 9:09 AM
To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich

Anna,
	A few comments...

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Saturday, November 11, 2000 6:14 PM
To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy';

Kaz,

Thank you, 
Anna

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, November 10, 2000 1:03 PM
To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy';

Greg,

Well..., yes and no.

This is a good point.

Thanks,
kaz

---

From: "Ziper, Anna" <[email-masked]>
Date: Mon, 13 Nov 2000 15:31:45 -0800

Matt,

About primary SAIDs...

About TEK machine...

thanks, 
Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 3:07 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 4:37 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 2:14 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 3:29 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Am I right?

Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:16 PM
To: 'Ziper, Anna'; Schmitt, Matt; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Anna,

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:27 PM
To: 'Schmitt, Matt'; Ziper, Anna; 'Kaz Ozawa'; Nakanishi, Greg; 'Rich

Matt,

thanks, Anna

-----Original Message-----
From: Schmitt, Matt [mailto:[email-masked]]
Sent: Monday, November 13, 2000 9:09 AM
To: 'Ziper, Anna'; 'Kaz Ozawa'; Nakanishi, Greg; Schmitt, Matt; 'Rich

Anna,
	A few comments...

Matt

-----Original Message-----
From: Ziper, Anna [mailto:[email-masked]]
Sent: Saturday, November 11, 2000 6:14 PM
To: 'Kaz Ozawa'; Nakanishi, Greg; 'Schmitt, Matt'; 'Rich Woundy';

Kaz,

Thank you, 
Anna

-----Original Message-----
From: Kaz Ozawa [mailto:[email-masked]]
Sent: Friday, November 10, 2000 1:03 PM
To: Nakanishi, Greg; 'Kaz Ozawa'; 'Schmitt, Matt'; 'Rich Woundy';

Greg,

Well..., yes and no.

This is a good point.

Thanks,
kaz