Subject: Re: draft-kuhfeld-sonet-aps-mib-01

From: Lauren Heintz <[email-masked]>
Date: Fri, 17 Sep 1999 15:28:31 -0700

Hi,

I'm trying to come up to speed on sonet APS, and have a few questions and
comments regarding this draft, which, by the way, I think is very valuable,
so thanks to all who contributed to it so far.

If any of my comments are way off-base, consider that I'm just thinking out
loud :-) and corrections and insights are highly welcomed.

By the way, are there any draft MIBs out there for BLSR or UPSR?  I couldn't
find any.

Regards and thanks,
Lauren

- How do you intend that a given protection group is created (or destroyed) in
this MIB via SNMP?  Which entries in which tables are created first such that
inter-table inconsistencies are always avoided?  First, I presume that the
apsLineTable entries are created as side-effects to entry creations in the other
two tables (but even that's not clear).  However, things get tricky after this.
For example, it seems there should be a RowStatus column for the apsChannelTable
to allow explicit creation and destruction of individual channels for a given
aps group.  Without a RowStatus column in the apsChannelTable (as currently
designed), one might instead assume an entry creation in the apsChannelTable is
an implicit side-effect of creating an active entry in the apsGroupTable, but
this design has problems.  For example, how does an agent determine how many
apsChannelTable entries (channels) are implicitly created since N is not
specified in the corresponding apsGroupTable entry?  And even if entries for
all possible channels (16 entries) are implicitly created, which default
values are selected for, say, apsChannelLineId, and how does the implementation
know when the newly created entries (which would only contain suggested values
at creation time, and in some cases might even be duplicates of similar objects
in other channel entries) are ready for activation?  Anyway, unless I've totally
missed something here, I would strongly suggest adding RowStatus to the
apsChannelTable as a sole means of, a) determining which channels exist for a
given protection group, b) indicating which channels are configured and
active, and c) which channels are inactive and in the process of being
configured. Whether you would have to explicitly/implicitly create/destroy
the NULL channel (or even the extra channel) is another matter.

- apsChannelLineId - Note that the InterfaceIndex TC (as defined in rfc2233)
does not allow the value of 0, so you can't set it to 0, despite the description
otherwise, and again, this points to the possible need of a RowStatus column
in this table.  As a digression (I throw this opinion out whenever the
opportunity avails itself :), I really don't know why conventional IETF wisdom
tries to have STD TCs and such to forbid the value 0 (or zero-length strings).
I think it causes more problems than it solves (but let's not go there :).

- apsGroupOperStatus - Why BITs?  Since bits are not being or'ed together, why
not an enumerated INTEGER as in the case of several other objects in this same
MIB (e.g. apsChannelSwitchCommand)?  The same applies to apsChannelStatus.

- apsChannelStatus - Seems that a "unswitched" (or something) status is required
during times that none of the other states apply, which may be the normal case
if I understand things correctly.

- apsGroupWaitToRestoreTime - gr1500 says it is "sufficient" to specify this in
minute increments, however, I believe implementations are free to specify more
refined values (i.e. partial minutes or seconds).  So, either allow these values
to be specified in seconds, or indicate whether an agent should round up or down
(i.e. is 5.X minutes reported as 5 or 6?).

- Regarding the null or extra apsChannelTable entries, I'm wondering which
columns won't apply for either case, and whether this should be clarified in
relevant descriptions?

- What is the value reported for apsGroupOperStatus if there is no extra traffic
being carried and the other failure indications do not apply (i.e. none of the
channels have errors and none are being switched)?  Seems that another value
like "ok" or "noExtra" or "lineFree" or "bornFree" (sorry) needs to be added.

- apsChannelSwitchCommand and apsChannelControlCommand - add the value
"noCommand(0)" to both, that way MIB browsers and SNMP mgrs can report
"noCommand" to the user instead of the utterly unintuitive value of "0".

- apsChannelControlCommand - does setting this to lockoutWorkingChannel WHILE
the line is already switched (as opposed to before it is switched), cause the
working line to be switched out?  If so, the description needs clarification.
And why must this object return only 0 for an SNMP GET?

- Some kind of an apsLastChangeTime scalar for each table may be valuable in
reducing the amount of SNMP mgr polling in this MIB.

- A TestAndIncr scalar may be useful to coordinate the actions of multiple
managers (for example, see vacmViewSpinLock in rfc2575).

- This MIB design sort of forces the SNMP mgr applications/users to have
significant and detailed prior knowledge of which sonet lines are available
in a given vendor product for use as protection, working, extra, etc., even
though some vendor products might place hard-to-remember constraints on which
sonet lines can be used for protection lines, or working lines, or even which
lines (working and protected) may be used together in a given protection group.
It would be a great benefit to APS app' designers and users if this knowledge
were instead exported from this MIB itself, and in a way that was vendor
independant and easy to provide.

Here is a hastily conceived (i.e. not completely thought out or specified)
example of how such a feature might be provided:

First define a TC (please excuse the shorthand):

ApsAvailableType, INTEGER (protection(1), working(2), extra(3))

Now a table (using abbreviated concise MIB notation):

apsAvailabilityTable
	- ifIndex InterfaceIndex (INDEX) not-accessible
	- apsAvailabilityType ApsAvailableType (INDEX) not-accessible
	- apsAvailabilityIfIndex InterfaceIndex (INDEX) read-only

So, if a given sonet line X was available to be configured as a working line,
and a given product only allowed line X to be protected by certain protection
groups, say, A, B, C, then the following entries would exist:

X.2.A
X.2.B
X.2.C

Similarly, if a given sonet line Y was available to be configured
as a protection line, and a given product only allowed lines D, E, F
to be working lines of line Y, then the following entries would exist:

Y.1.D
Y.1.E
Y.1.F

And so on.

Note that once a given sonet line has been configured into an active/enabled
protection group, one or more entries in the apsAvailabilityTable that reference
that line might be removed.  For example, from the above examples, the entries
referencing line Y would be removed if line Y was actually configured instead as
a working line for a different group Z.

But there may be better ways of providing such a feature -- the above is just
what quickly came to mind.  The main thing at this time is to get the idea
considered.

Ken Chapman wrote:
> 
> I like the work done by Jeff and Jim on the SONET APS MIB.
> However, I'd like to suggest some changes.
> - While I read somewhere recently that MIB tables should be
>   indexed by names (DisplayString), I find it hard to accept
>   that that is the "simplest" approach.  In the case of this MIB,
>   I find that using an already well established (albeit not very
>   easy to implement) index in the form of the ifIndex to be the
>   most straightforward approach.
> - Another small change is to combine the config and status tables;
>   from my implementation experience, the fewer the tables, the
>   less the work!
> - Another thing I would suggest changing is to expand some of the
>   "cryptic" encoded object into more user-friendly objects.
> 
> Rather than try to suggest a whole raft to specific changes to
> draft-kuhfeld-sonet-aps-mib-01, I've put together a complete
> separate submission.  I'll leave it to the WG to decide how to
> "merge" the two, but I'd suggest picking one as a starting point
> and then pick it appart.  :^)
> 
>         Ken
> 
>   --------------------------------------------------------------------------------
> 
>    draft-kchapman-sonet-aps-mib-00.txtName: draft-kchapman-sonet-aps-mib-00.txt
>                                       Type: Plain Text (text/plain)
> 
>   --------------------------------------------------------------------------------
> 
> ================================================
> Ken Chapman                 Argon Networks, Inc.
> tel: +1-978-486-0665 x146   25 Porter Road
> fax: +1-978-486-9379        Littleton, MA  01460
> mailto:[email-masked]   http://www.Argon.com
> ================================================

---

From: Ken Chapman <[email-masked]>
Date: Mon, 20 Sep 1999 11:12:40 -0400

Lauren,
Thanks for your commnets.
>By the way, are there any draft MIBs out there for BLSR or UPSR?  I couldn't
I'm not aware of any.
>two tables (but even that's not clear).
That was the intent.
> However, things get tricky after this.
>aps group.
Good point; an oversight on my part.
>  Without a RowStatus column in the apsChannelTable (as currently
You point is well taken!
>I think it causes more problems than it solves (but let's not go there :).
Again, an oversight; should be InterfaceIndexOrZero.  (I'm glad that
someone is
actually interested in this enough to find these things.  ;^)
>MIB (e.g. apsChannelSwitchCommand)?  The same applies to apsChannelStatus.
It was not clear to me in reading the specs that these conditions were
mutually
exclusive.  (I'm not an SONET/APS guru; I just like to write MIBs!)
>if I understand things correctly.
True only if we change this from BITS to INTEGER.  In this case, I beleive
that
more than one of these conditions can be present at one time, in which case
BITS 
is the appropriate syntax.  An argument can be made for breaking this up into 
multiple, more focused status variables.
>(i.e. is 5.X minutes reported as 5 or 6?).
I was not aware of that.  I have no problem changing the semantics to seconds.
>columns won't apply for either case, and whether this should be clarified in
I don't have the answer, but I agree that it should be clarified.
>like "ok" or "noExtra" or "lineFree" or "bornFree" (sorry) needs to be added.
Again, this is the difference in the semantics of BITS vs. INTEGER.  If it 
remains BITS, a value of zero(0), means none of the conditions are present.
>"noCommand" to the user instead of the utterly unintuitive value of "0".
Good idea.
>working line to be switched out?  If so, the description needs clarification.
I don't have an answer, but, your right, it needs clarification.
>And why must this object return only 0 for an SNMP GET?
I suppose it may be possible for an implementation to return the oldest
pending 
commmand, or "noCommand" if none are pending.  However, I didn't think that
was
terribly useful information and would be hard to implement, but I can be 
convinced otherwise.
>reducing the amount of SNMP mgr polling in this MIB.
Good idea.
>managers (for example, see vacmViewSpinLock in rfc2575).
WRT assigning apsChannelNumber?  Do you really think more than one manager
would
be trying to add more channels to a particular group at the same time?  Seems
like overkill to me.
>what quickly came to mind.  The main thing at this time is to get the idea
Good idea.  I have no problem adding such a table.

Thanks for your comments, Lauren.  I'm not sure what the next step is, since I
was only commenting on the original proposal from RedBack.  It is up to the WG
to decide if we want to progress this, who the editor is, etc...
So, I guess we need to hear from Kaj. 
	Ken

>> and then pick it appart.  :^)
----------------------------------------------------------------------------
----
>>                                       Type: Plain Text (text/plain)
----------------------------------------------------------------------------
----

---

From: bordia <[email-masked]>
Date: Mon, 20 Sep 1999 20:42:09 -0700 (PDT)

Unsubscribe

---

From: Lauren Heintz <[email-masked]>
Date: Tue, 21 Sep 1999 09:19:27 -0700

Hi,

I just looked at the charter
(http://www.ietf.org/html.charters/atommib-charter.html)
of this WG and noticed it does not mention any Sonet-related work at all, even
though
there are a few such RFCs and drafts published as a result of this groups
efforts.

I also noticed under Goals and Milestones that the latest item is way back in
Oct 95.

So, does this WG plan to meet in DC in November?

Does this WG's charter include development of Sonet-related MIBs (including
linear- or ring-based protection architectures), and will these items be
put on the agenda and discussed?

Are there a lot of people on this list interested in working in said areas?

Thanks,
Lauren

---

From: Kaj Tesink <[email-masked]>
Date: Tue, 21 Sep 1999 14:47:54 -0400

hi lauren,

>I also noticed under Goals and Milestones that the latest item is way back in

the charter is out of date - i was going to update it but simply
got snowed under. in essence, the revised charter calls for
- maintenance of existing RFCs (sonet/sdh, atm, atm test, accounting)
- sonet/sdh aps
- supplemental sonet/sdh (e.g., the continuous counts issues, usrHistory
approach)
- wdm (not sure)

>So, does this WG plan to meet in DC in November?

i dont think there's much to discuss that cant be done via this list

>put on the agenda and discussed?

there has been aps discussion and two drafts - see the archives.
work is underway to consolidate the existing drafts
any comments are encouraged and much appreciated

>Are there a lot of people on this list interested in working in said areas?

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies (formerly Bellcore)
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
       Red Bank, NJ 07701
       USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/