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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Aug 2012 10:15:38 +0100

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

---

From: "Masanori Miyazawa" <[email-masked]>
Date: Thu, 23 Aug 2012 12:51:07 +0900

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:[email-masked]]
> Sent: Wednesday, August 22, 2012 6:16 PM
> To: 'Masanori Miyazawa';
> [email-masked]
> Cc: [email-masked]
> Subject: RE: AD review of draft-ietf-ccamp-gmpls-ted-mib
> 
> Hi,
> 
> > > 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?
> 
> 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.
> 
> > > I'm having some trouble with the use of 2119 language in the
> > > Description for tedLinkInformationData.
> > >
> > > Two examples...
> > >
> > # At this time, we do not have a detailed situation to vary change to
> > the value unknown (0).
> > > 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]
> > >          "This entry contains the IP address information of the
> > > local TE
> > >    link."
> > > 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.
> 
> > > 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]
> > 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...
> > >