Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-05.txt

From: [email-masked]
Date: Fri, 11 May 2001 07:12:44 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over Cable Data Network Working Group of the IETF.

	Title		: Management Information Base for DOCSIS Cable Modems 
                          and Cable Modem Termination Systems                  
                          for Baseline Privacy Plus
	Author(s)	: S. Green
	Filename	: draft-ietf-ipcdn-bpiplus-mib-05.txt
	Pages		: 66
	Date		: 10-May-01
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines a set of managed objects for SNMP-based
management of the Baseline Privacy Plus features [17] of
DOCSIS1.1-compliant[16] Cable Modems and Cable Modem Termination
Systems.
This memo specifies a MIB module in a manner that is compliant to the
SNMP SMIv2 [5][6][7].  The set of objects are consistent with the
SNMP framework and existing SNMP standards.
This memo is a product of the IPCDN working group within the Internet
Engineering Task Force.  Comments are solicited and should be
addressed to the working group's mailing list at [email-masked]
and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipcdn-bpiplus-mib-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Daniel Hegglin" <[email-masked]>
Date: Tue, 15 May 2001 16:58:13 -0700

A few questions regarding the mib:

1. The docsBpi2CmtsIpMulticastTable now has information in it that is
redundant with the TEK table, specifically:
- DataEncryptAlg
- DataAuthentAlg
- SAType
Is there a reason these variables were added to the table?

2. IpMulticastSAId has a range of 0..16383.  This is incorrect as it also
includes non-multicast SIDs.

3. When a CM requests a mapping for a multicast IP address that does NOT
exist, we send the CM the appropriate reject message.  The problem is that
we don't have an entry in this table if there is no mapping, hance the
SAMapRejectErrorCode can never be set to noAuthForRequestedDSFlow(9), making
it superfluous.  Am I missing something?

4. What was the motivation to change the indexing to this table?

thanks!
dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Friday, May 11, 2001 4:13 AM
> To: IETF-Announce:; @ietf.org@manet
> Cc: [email-masked]
> Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-05.txt
>
>

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

---

From: "Daniel Hegglin" <[email-masked]>
Date: Wed, 16 May 2001 17:18:43 -0700

Stuart,

> If a CMTS implements "create access" for a new multicast SAID,
> these 3 fields need to be specified.

Hmmm, I agree on the dataEncryptAlg & dataAuthentAlg, but why the SAType?
Is it ok if I set the type to be primary if the SAId is in the multicast
range?  I guess there's other places in the spec where the operator can set
unreasonable values.

I'm also a bit confused on the static/dynamic designation.  If I statically
define a multicast mapping and define a static entry in the multicast
authorization table for modem x, that makes it a static entry.  However, if
modem y sends a SAMap requesting this mapping, it is technically a dynamic
mapping for modem y, but the designation still stays static.  There are
other scenarios like this, but to me it's not very clear from the spec since
it can be static to one modem and dynamic to another.  My approach has been
to declare any entry static if there are entries statically defined in the
multicast authorization table using SNMP, even if this occurs after it is
already designated dynamic through a SAMap request.  Is this the proper
approach?

> > it superfluous.  Am I missing something?

Whoops, my bad.  What I meant is dsFlowNotMappedToSA(10).  If there is no
mapping then there is no entry in this table.  If there is no entry in this
table, then we can never set this to 10.  If there is a mapping, then we
would never set it to 10.  Does this make dsFlowNotMappedToSA superfluous?

thanks,
dan

---

From: Stuart Green <[email-masked]>
Date: Wed, 16 May 2001 19:29:14 -0400

Daniel,
  See below.
-- 
Stuart Green
Nortel Networks - Arris Venture

> includes non-multicast SIDs.

A CMTS could provide the capability of mapping a multicast IP address
to the primary SID, thus extending the SAID range. 

> it superfluous.  Am I missing something?

If the multicast IP address does not exist, the error can not be
logged in the table.  However, if the address exists then 
noAuthForRequestDSFlow could occur and should be reflected
in the table.

> 4. What was the motivation to change the indexing to this table?

IP address needed to change in order to be "IPv6 ready".
The decision to move the IP address out of the index was a
difficult one; in the end, we opted for a simple index 
rather than a complicated but (IP) ordered index.

---

From: Stuart Green <[email-masked]>
Date: Wed, 16 May 2001 19:29:14 -0400

Daniel,
  See below.

---

From: Stuart Green <[email-masked]>
Date: Fri, 18 May 2001 20:28:23 -0400

> range?  I guess there's other places in the spec where the operator can set

The table is meant to be general purpose as it is difficult to predict
exactly how multicast services will be rolled out.  Your specific 
implementation may choose not to allow multicast mapping to primary
SAIDs.

> already designated dynamic through a SAMap request.  Is this the proper

Yes I believe your implementation is acceptable and the static/dynamic
designation is arbitrary for BPI+.  

> would never set it to 10.  Does this make dsFlowNotMappedToSA superfluous?

Maybe.  Perhaps if the row status variable is "not in service"
you could get the error code to appear in the table.  However,
I believe your implementation is acceptable too.
-- 
Stuart Green
Nortel Networks - Arris Venture

---

From: Stuart Green <[email-masked]>
Date: Fri, 18 May 2001 20:28:23 -0400