Subject: Re: [CCAMP] MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07

From: Lou Berger <[email-masked]>
Date: Tue, 01 Mar 2011 11:31:42 -0500

Masanori,
	What about representing the other states defined for interface status 
in the Interface MIB (RFC2863)?

Lou

On 2/28/2011 10:32 AM, Masanori Miyazawa wrote:
> Please discuss.
>
> "Thank you for your comment. We think the definition of tedInfosStatus in
> previous version was wrong, as you indeicated . It took into account only a
> state/status of this MIB itself, not link information. In order to take into
> account the operational status of TE link, we think it is necessary to
> create new object such as, for example, "tedLinkState" in tedTable as shown
> below. If you have comments, please let us know. "
>
> tedLinkState OBJECT-TYPE
>      SYNTAX        INTEGER {
>                     up(1),
>                     down(2)
>                     }
>      MAX-ACCESS    read-only
>      STATUS        current
>      DESCRIPTION
>       " "
> ::={ tedEntry X }
>

---

From: "Masanori Miyazawa" <[email-masked]>
Date: Thu, 3 Mar 2011 23:54:28 +0900

Lou,

Thank you for your comment. You mean that, for example, the state
information defined in ifOperStatus should be added in the state of
tedLinkSate as below. 

tedLinkState OBJECT-TYPE
      SYNTAX        INTEGER {
                     up(1),
                     down(2),
                     testing(3),
                　　 unknown(4),  
                     dormant(5),
                     notPresent(6)
                     }
      MAX-ACCESS    read-only
      STATUS        current
      DESCRIPTION
       " "
::={ tedEntry X }

Regards,
Masanori

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Wednesday, March 02, 2011 1:32 AM
> To: Masanori Miyazawa
> Cc: 'Joan Cucchiara'; [email-masked]; 'MIB Doctors (E-mail)'; 'Tomohiro
> Otani'; [email-masked]; 'Thomas D. Nadeau'; 'Dan Romascanu
> (E-mail)'
> Subject: Re: [CCAMP] MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07
> 
> 
> Masanori,
> > previous version was wrong, as you indeicated . It took into account
only
> a

---

From: Lou Berger <[email-masked]>
Date: Thu, 03 Mar 2011 15:22:05 -0500

I think this is reasonable.  Although this does not address how
OperStatus of the TE link is set.

Lou

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 15 Mar 2011 21:57:37 -0500

Masanori,

Thank you for your responses.
I have deleted the many items where we have reached agreement and
have a couple comments inline below:

Thank you,
   -Joan

----- Original Message ----- 
From: "Masanori Miyazawa" <[email-masked]>
To: "'Joan Cucchiara'" <[email-masked]>; <[email-masked]>; "'MIB 
Doctors (E-mail)'" <[email-masked]>; "'Tomohiro Otani'" 
<[email-masked]>; <[email-masked]>; "'Thomas D. Nadeau'" 
<[email-masked]>
Cc: "'Dan Romascanu (E-mail)'" <[email-masked]>
Sent: Monday, February 28, 2011 10:32 AM
Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07

> Hi, Joan
>
> Thank you for your comments.
> In accordance with your comments, I am revising the documents.
> Please see our answer to your comments as below and let us know if you 
> have
> any question
>
> With best regards,
> Masanori
>
> COMMENTS ON MIB MODULE
> --------------------------------------------
>
>
"
>
>
> *)  tedInfoStatus object
>
> I think there is still some confusion about my request for status/state
> information.
> Obviously, if there are rows in these tables, then
> the MIB has been configured by some means other than SNMP, and granted
> notifications are sent (unless
> they are dropped due to throttling or lost), but what is the Operational
> Status
> link?
>
> The RowPointer object, tedLinkInformationData, might provide this
> information, however,
> the DESCRIPTION clause makes it sound completely optional since it looks
> like 0.0
> can be entered under any circumstance, so again, I have to ask, how is an
> operator
> supposed to know if the TE link is acting as intended?
>
> If tedLinkInformationData is supposed to provide this, then it needs to be
> rewritten to
> be mandatory.  That means that there are dependencies on other MIBs also.
> That is
> unclear in this document.
>
> In summary, tedInfoStatus object does not provide any additional
> information, as
> I can see if the MIB is populated.  What I'm asking for is Operational
> Status/State
> information.
>
>
> Please discuss.
>

I would need to see the DESCRIPTION to fully understand the above object, 
however,
yes, it would seem this object addresses my concerns.

>
>
> *) tedNotificationAreaId and tedNotificationRouterId
>
> Not sure why these are needed.  Couldn't you include
> an object from the tedTable (such as tedLinkInformationSource)
> rather than have these accessible for Notify objects.  Seems like
> extra work on all parts and not sure I see the advantage when
> you already have this info in a table.
>
> Please discuss.
>
> " In version 6 of ted mib, tedAreaId, tedRouterId and tedLinkStateId were
> utilzed as the Index of notification because it is useful to treat as the
> notification with unique value by using combination of these objects. 
> But,
> it cause some error on SMICngPro as shown below.
> Therefore, we decided to
> utilize new objects such as tedNotificationAreaId, tedNotificationRouteId
> and tedNotificationLinkStateId. We think we want to use tedAreaId,
> tedRouterId and tedLinkStateId as the index of notification again. What do
> you think?"
>

Basically, you are looking for a way to get rid of the warnings from the MIB 
compiler
and include the values of the three indices (tedAreaId, tedRouterId, and 
tedLinkStateId) with
the notification.   There are two (maybe more) ways to accomplish this:

1)  If an object from the tedTable (for example, tedLinkInformationSource) 
were included in the
notification, then the receiver of the notification could parse the OID and 
extract the values
of  tedAreaId, tedRouterId and tedLinkStateId (i.e. the indices of this 
object are included in the OID).

2) Duplicate these index values in accessible-for-notify objects, (or even
managed objects).

Pros vs. Cons of each way.

1.  Pro:  The tedTable is already there.  Including an object from the table 
in the notification
is relatively straightforward.
Con:  not sure I see one

2.  Pro:  ??
Con:  duplicating information and slightly more coding, and testing.

Anyway, I still don't see a benefit (i.e. "pro" ) for #2.   If you could let 
me know, that would
be helpful.    It is not incorrect to solve the problem with #2, but I do 
think that #1 is simpler.

Thanks,
  -Joan

---

From: "Masanori Miyazawa" <[email-masked]>
Date: Sat, 19 Mar 2011 23:31:22 +0900

Joan,

Thank you for your responses.
I have a answer for your comments inline below.

Regards,
Masanori

only
> yes, it would seem this object addresses my concerns.

We added the DESCRIPTION as below. And also, the unknown(3) state is added
in accordance with a comment from Lou. Although there are some states in
Interface MIB, for example testing, dormant and so on, we think that three
types of states are enough in this tedLinkState.

tedLinkState OBJECT-TYPE
      SYNTAX        INTEGER {
                     up(1),
                     down(2),
                　　 unknown(3) -- status can not be determined for some
reason

                     }
      MAX-ACCESS    read-only
      STATUS        current
      DESCRIPTION
       " This object represents the actual operational state of this TE
link. The up(1) state indicates that the TE link is administratively changed
to up. If the TE link information is managed by the routing protocol, e.g.
OSPF(v2 and v3) and ISIS, it should remain in the up(1) state. Otherwise, if
local configuration is used, when this link is administratively change to
down, this object should be down(2) state."
::={ tedEntry X }

> think that #1 is simpler.

Thank you for providing useful comments. We also think #1 is better to solve
the problem. So, we decided to use tedLinkInformationSource as the index of
notification as below. Do you have any comments regarding the notification?

tedStatusChange NOTIFICATION-TYPE
    OBJECTS  {
      tedLinkInformationSource
      }
    STATUS   current
    DESCRIPTION
      "This notification signifies that there has been change in TE
information of tedTable, tedLocalIfAddrTable, tedRemoteIfAddrTable,
tedSwCapTable and tedSrlgTable. For example, this should be generated when
tedUnreservedBandwidth is changed to create or delete LSP using registered
TE link. "
::= { tedNotifications 1 }

tedCreation NOTIFICATION-TYPE
    OBJECTS  {
      tedLinkInformationSource
      }
    STATUS   current
    DESCRIPTION
      " This notification signifies that there has been new registration in
ted table by receiving new TE link information. For example, this should be
generated when new index (tedAreaId, tedRouterId and tedLinkStateId) is
registered in TED table."
::= { tedNotifications 2 }

tedDeletion NOTIFICATION-TYPE
    OBJECTS  {
      tedLinkInformationSource
      }
    STATUS      current
    DESCRIPTION
      "This notification signifies that there has been deletion of existing
entries in ted table. For example, this should be generated when one of
existing entries is deleted in TED table."
::= { tedNotifications 3 }

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 22 Mar 2011 10:42:33 -0500

> Sent: Saturday, March 19, 2011 9:31 AM

Hello Masanori

Thanks, please see inline for a couple of minor comments.
I think we have reached agreement, so please see below and
if there are no questions/comments, then please update the doc.

Thanks,
  -Joan

>>> > If tedLinkInformationData is supposed to provide this, then it needs 
>>> > to
>>> be
>>> > rewritten to
>>> > state/status of this MIB itself, not link information. In order to 
>>> > take
>>> > into

Should renumber these enums as:
(Please refer to Section 4.6.1.1 of RFC4181 for integer-valued enums.)
   unknown(0)
   up (1)
   down (2)

The description looks as if the "admin" status is being combined here
with "oper" status.

As a very simple example, if a row is added to the tedTable, but there is 
not
yet a physical link, then the link will operationally be "down".  Once a
physical connection is made, then link would be operationally "up", right?
So, need to write the above object to reflect an "operational" status only.

If you want to add a new object to reflect a read-only admin Status, that is
fine, but that would be a separate object.

>>> > tedRouterId and tedLinkStateId as the index of notification again. 
>>> > What
>>> do
>>> > you think?"
>>> >
>>>

The above Notification seems reasonable...although, think that the intent
is for any change to trigger this notification, so should say,
"tedSwCapTable and/or tedSrlgTable", rather than just "and".

>> ::= { tedNotifications 3 }

Could the above be renamed to tedEntryCreated and tedEntryDeleted?
Should be singular, so:

s/deletion of existing entries in ted table/deletion of an entry in the ted 
table/

Thanks,
  - Joan

---

From: "Masanori Miyazawa" <[email-masked]>
Date: Fri, 1 Apr 2011 01:21:44 +0900

Joan,

Many thanks for your time and help.
I will update the doc with the discussion with you and have a comments
inline below.

> fine, but that would be a separate object.

I think that the object is enough for representing the state of TE link, so
revised the description as below.

tedLinkState OBJECT-TYPE
      SYNTAX        INTEGER {
                     unknown(0),
                     up(1),
                　　 down(2) 
                     }
      MAX-ACCESS    read-only
      STATUS        current
      DESCRIPTION
       " This object represents the actual operational state of this TE
link. For instance, if a row is created in the tedTable, but the actual TE
link is not available for some reason (e.g. when there is not yet physical
link or manually disable), then the object would be down(2) state. In
contrast, if a row is added and the TE link is available, this would be
operationally up(1). "  
"
::={ tedEntry X }