Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ted-mib

["Masanori Miyazawa" <[e-mail]>]

Ho, Adrian

Thank you for sending your comments.
I understood your comments and agreed.

I will update the document to reflect your comments, and post it as latest
version.

Regards,
Masanori

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Wednesday, August 22, 2012 6:16 PM
> To: 'Masanori Miyazawa';
> [e-mail]
> Cc: [e-mail]
> Subject: RE: AD review of draft-ietf-ccamp-gmpls-ted-mib
> 
> Hi,
> 
> I'm sorry! I missed this email.
> 
> Please see in line.
> 
> > > Could you please sort out "MIB" versus "MIB module". There is only
> > > one MIB. There are many MIB modules - this document defines a MIB
> > > module
> > >
> > [Masanori Miyazawa]
> > # I could not understand above comment. You mean that descriptions of
> > "MIB modules" exit in this document?
> 
> Mainly you should talk about "the MIB module defined in this document".
> 
> The MIB module defined in this document forms part of "the MIB" i.e. all
> the data in the whole world:-)
> 
> > > You need to avoid using citations (e.g. [RFC3630]) within the MIB
> > > module itself. MIB modules are extracted from their documents and
stand
> alone.
> 
> This means that you are allowed to use square brackets between in the MIB
> module itself.
> 
> Some example changes are...
> 
> OLD
>    tedTable OBJECT-TYPE
>       SYNTAX       SEQUENCE OF TedEntry
>       MAX-ACCESS   not-accessible
>       STATUS       current
>       DESCRIPTION
>         "This table indicates multiple TED information which has been
>    supported by [RFC3630]."
>    ::= { tedObjects 1 }
> NEW
> tedTable OBJECT-TYPE
>       SYNTAX       SEQUENCE OF TedEntry
>       MAX-ACCESS   not-accessible
>       STATUS       current
>       DESCRIPTION
>         "This table indicates multiple TED information which has been
>          supported by RFC 3630."
>       REFERENCE
>         "Traffic Engineering (TE) Extensions to OSPF Version 2,
>          RFC 3630."
>    ::= { tedObjects 1 }
> END
> 
> 
> OLD
>    tedLocalRouterId OBJECT-TYPE
>        SYNTAX       TedRouterIdTC
>        MAX-ACCESS   not-accessible
>        STATUS       current
>        DESCRIPTION
>          "This object represents the router ID of the router originating
>    the LSA. If OSPF is used to advertise LSA, this represents a Router
>    ID. If ISIS is used, this represents a System ID. Otherwise, this
>    represents zero."
>        REFERENCE
>          " OSPF Version 2, [RFC2328], C.1
>            OSPF for IPv6, [RFC5340], C.1
>            [ISO10589], Section 7.1 "
>    ::= { tedEntry 2 }
> NEW
>    tedLocalRouterId OBJECT-TYPE
>        SYNTAX       TedRouterIdTC
>        MAX-ACCESS   not-accessible
>        STATUS       current
>        DESCRIPTION
>          "This object represents the router ID of the router originating
>    the LSA. If OSPF is used to advertise LSA, this represents a Router
>    ID. If ISIS is used, this represents a System ID. Otherwise, this
>    represents zero."
>        REFERENCE
>          "1. OSPF Version 2, RFC 2328, C.1
>           2. OSPF for IPv6, RFC 5340, C.1
>           3. Intermediate system to Intermediate system routeing
>              information exchange protocol for use in conjunction with
>              the Protocol for providing the Connectionless-mode Network
>              Service (ISO 8473), ISO10589, Section 7.1."
>    ::= { tedEntry 2 }
> END
> 
> 
> OLD
>    tedLinkType OBJECT-TYPE
>        SYNTAX       INTEGER {
>                     pointToPoint (1),
>                     multiAccess (2)
>                     }
>        MAX-ACCESS   read-only
>        STATUS       current
>        DESCRIPTION
>          "This indicates the type of the link such as point-to-point or
>    multi-access."
>        REFERENCE
>          " Traffic Engineering (TE) Extensions to OSPF Version 2, [RFC
>    3630], 2.5.1"
>    ::= { tedEntry 8 }
> NEW
>    tedLinkType OBJECT-TYPE
>        SYNTAX       INTEGER {
>                     pointToPoint (1),
>                     multiAccess (2)
>                     }
>        MAX-ACCESS   read-only
>        STATUS       current
>        DESCRIPTION
>          "This indicates the type of the link such as point-to-point or
>    multi-access."
>        REFERENCE
>          "Traffic Engineering (TE) Extensions to OSPF Version 2,
>           RFC 3630, 2.5.1"
>    ::= { tedEntry 8 }
> END
> 
> 
> > > I'm having some trouble with the use of 2119 language in the
> > > Description for tedLinkInformationData.
> > >
> > > Two examples...
> > >
> > >           If tedLinkInformationSource has the value unknown(0), this
> > >        object SHOULD contain a value of zeroDotZero.
> > >
> > > Under what circumstances can this use of "SHOULD" be varied?
> > [Masanori Miyazawa]
> > # At this time, we do not have a detailed situation to vary change to
> > the value unknown (0).
> > Should we delete the word "SHOULD"? or should the value unknown (0) be
> > deleted in this MIB if it is not used?
> 
> This looks like it needs to read...
> 
>         If tedLinkInformationSource has the value unknown(0), this
>         object MUST contain a value of zeroDotZero.
> 
> > >           If tedLinkInformationSource has the value
> > >        locallyConfigured(1), this object MAY contain the identifier
> of
> > >        the corresponding row entry in the teLinkTable of TE-LINK-STD-
> > >        MIB[RFC4220], the identifier of the corresponding row in a
local
> > >        proprietary TE link MIB module, or the value of zeroDotZero
> > >        otherwise.
> > >
> > > The use of "MAY" here implies that an implementation can choose to
> > > fill in the row pointer if it likes, but this is entirely an
> > > implementation choice. Is this what you are saying, or do you want
> > > to constrain the behavior more forcefully if TE-LINK-STD-MIB is
> implemented?
> > >
> > [Masanori Miyazawa]
> > # No, we think the implementation of this object is not constrained
> > forcefully.  If the pointer is needed, we think this object should be
> used.
> 
> OK.
> How about making it...
> 
>            If tedLinkInformationSource has the value
>         locallyConfigured(1), an implementation can use this object to
>         supply the identifier of the corresponding row entry in the
>         teLinkTable of TE-LINK-STD-MIB (RFC 4220), the identifier of
>         the corresponding row in a local proprietary TE link MIB module,
>         or the value of zeroDotZero.
> 
> > >    tedLocalIfAddrEntry OBJECT-TYPE
> > >        SYNTAX       TedLocalIfAddrEntry
> > >        MAX-ACCESS   not-accessible
> > >        STATUS       current
> > >        DESCRIPTION
> > >          "This entry contains the IP address information of the
> > > local TE
> > >    link."
> > >        INDEX { tedLinkIndex, tedLocalIfAddr }
> > >    ::= { tedLocalIfAddrTable 1 }
> > >
> > >    TedLocalIfAddrEntry ::= SEQUENCE {
> > >        tedLocalIfAddrType    InetAddressType,
> > >        tedLocalIfAddr        InetAddress
> > >
> > >        }
> > >
> > > What would it look like to walk this table by increasing index value?
> > > Would all the shorter v4 addresses show first, or would the
> > > numerically smaller v6 addresses get mixed in with the v4 addresses?
> > >
> > > If the latter is possible, you should use the address type as an
> > > index as well.
> > >
> > [Masanori Miyazawa]
> > # As you know, note that tedLocalIfAddrTable as well as
> > tedRemoteIfAddrTable are independently defined, because the Interface
> > IP Address sub-TLV may appear more than once within the same Link-TLV.
> > Therefore, if the address is only used as index, another arbitrary
> > index such as tedIndex would be also needed to represent the
> > relationship with tedTable.
> 
> OK. Understood.
> 
> > > tedStatusChangeNotificationMaxRate and
> > > tedCreatedDeletedNotificationMaxRate
> > >
> > > I am surprised that the Defval for these is 0 (no throttling) since
> > > the text recognises that this is a risky situation that may cause
> > > the box to blow up. Surely the default should be some safe setting.
> > >
> > > But then I wondered what a suitable safe setting would be and
> > > realised it would be "No Notifications". Except there is no way to
> > > say this with these objects.
> > >
> > > What do you think?
> > [Masanori Miyazawa]
> > #The reason for setting 0 as defval is to prevent sudden increase in
> > notification information. If we set the value as 10, the SNMP manager
> > would receive a number of alarms which is proportional to number of
> > routers. For instance, same ospf domain consists of 5 routers, the
> > SNMP manager would receive up to 50 alarms. So, I think that the optimal
> value of defval is 1.
> 
> OK. Make that change.
> 
> > > For completeness, we usually get asked to state in the Security
> > > section what the risks are with write access objects. In this case
> > > it is really easy...
> > >
> > >    There are only two write-access objects in this MIB module:
> > >    tedStatusChangeNotificationMaxRate and
> > >    tedCreatedDeletedNotificationMaxRate.  Malicious modification of
> > >    these objects could cause the management agent, the network, or the
> > >    router to become overloaded with Notifications in cases of high
> > >    churn within the network.
> > [Masanori Miyazawa]
> > # You mean that we only need to describe the above sentence in section
> > 8[security consideration]?
> 
> Yes.
> 
> Thanks,
> Adrian
>