Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS
draft-ietf-ccamp-gmpls-ted-mib-15

[Ballot comment]
No objections to the publication of this document. I'm actually in favor of it.
Dan Romascanu, in his OPS-DIR brought a couple of good points, which I support.
At the very minimum, the point 4 should be addressed

1. In Section 2:

>  This MIB module should be used in conjunction with OSPFv2 MIB, OSPF
  v3 MIB and ISIS MIB as well as other MIBs defined in [RFC3812],
  [RFC3813], [RFC4802], [RFC4803] for the management of MPLS/GMPLS
  based traffic engineering information. 


It would have been useful to develop this a section that explains the
relation of the TED-MIB with other MIB modules that model MPLS-TE and
GMPLS devices. Are all these MIB modules required on the same device at
the same time? Being more precise here would help implementers and
switch designers in planning the resources required to implement and run
this MIB module.

2. Runing id-nits results in a number of warnings related to unused
references:

  == Unused Reference: 'RFC2328' is defined on line 1552, but no
explicit
    reference was found in the text
    '[RFC2328] J. Moy, " OSPF version2 ", RFC2328, April 1998....'

  == Unused Reference: 'RFC4001' is defined on line 1566, but no
explicit
    reference was found in the text
    '[RFC4001]  M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder,
"...'

  == Unused Reference: 'RFC4801' is defined on line 1579, but no
explicit
    reference was found in the text
    '[RFC4801] T. D. Nadeau and A. Farrel, Ed., "Definitions of Textual
C...'

  == Unused Reference: 'RFC5340' is defined on line 1587, but no
explicit
    reference was found in the text
    '[RFC5340] R. Coltun, D. Ferguson, J. Moy, A.Lindem " OSPF for
IPv6",...'

  == Unused Reference: 'RFC6340' is defined on line 1593, but no
explicit
    reference was found in the text
    '[RFC6340] R. Presuhn, "Textual Conventions for the Representation
of...'

  == Unused Reference: 'ISO10589' is defined on line 1596, but no
explicit
    reference was found in the text
    '[ISO10589] ISO 10589, "Intermediate system to Intermediate system
ro...'

  == Unused Reference: 'RFC4220' is defined on line 1625, but no
explicit
    reference was found in the text
    '[RFC4220] M. Dubuc, T. D. Nadeau and J. Lang, " Traffic
Engineering...'

Actually the references are used, but they appear in the DESCRIPTION or
REFERENCE clauses in the MIB module, and in a format (no brakets) that
makes them to pass undetected by id-nits. It would be useful to group at
lease the references that contain MIB modules in a short section prior
to the MIB module, so that implmenters and operators deploying the MIB
have an easy access to the documents that indicate what MIB modules need
to be compiled or loaded together with the TED-MIB. Add to these RFC4802
mentioned in the IMPORTS. 

3. The example provided in section 6 is ipv4 only. It would be useful to
add an ipv6 example.

4. Expanding the example to detail what would be a typical or
recommended operational flow used by an operator when working with the
MIB module would have been useful. How is the MIB modules supposed to be
used. What an operator can do with this MIB module? Download the
topology? How often? Verify that the switch was properly configured and
debug problems in the network using the objects in the tedTable,
tedRemoteTable and tedSwCapTable? What is the functionality and how can
be used the tedSrlgTable?

5. Notifications throttling is discussed and implemented and this is a
good thing. However, there is a potential issue here. The notifications
tedEntryCreated and tedENtryDeleted are supposed to be sent when an
entry was created or deleted in the TED table. However, the writeable
object that sets the notifications rate is set by default at 1
notification/minute, a value that many operators will leave as is. This
means that whenever more than one row is created or deleted in one
minute, just one notification will be sent. I think that an explicit
warning should be included about this situation, so that operators are
aware that in order to make sure that all changes were detected when a
notification was received, the whole table needs to be traversed.

6. There is no indication or hints to the operators about using the
objects in this MIB module for faults management or alerting about the
status of the network. For example can the tedUnreservedBandwidth per
priority objects be used to detect problems in capacity or in
configuration?

[Ballot comment]
Isn't the following missing from the security considerations (penultimate para) because it's part of the generic MIB Dr. boilerplate:

  Implementations MUST provide the security features described by the
  SNMPv3 framework (see [RFC3410]), including full support for
  authentication and privacy via the User-based Security Model (USM)
  [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
  MAY also provide support for the Transport Security Model (TSM)
  [RFC5591] in combination with a secure transport such as SSH
  [RFC5592] or TLS/DTLS [RFC6353].

[Ballot comment]

The *MaxRate settings (on p23) are read-write and allow up to
2^32-1 notifications per second in theory. Should you note that
implementations MAY or SHOULD have a limit that they impose on
these values so that if someone tries to set them to >LIMIT, an
error results?

If you wanted to say something about this, that could be done
on p23 where they're defined or in section 8 I guess.

If this is just some generic MIB thing that's already handled
everywhere, then sorry for bothering you with it:-)

[Ballot comment]
A number of minor editorial comments wre made in the Routing Directorate review by Young Lee. These will need to be applied before publication.

http://www.ietf.org/mail-archive/web/rtg-dir/current/msg01793.html

[Ballot comment]
-- Section 8 --
  There is a number of management objects defined in this MIB module
  that has a MAX-ACCESS clause of read-write.

While technically "a number of Xes" is singular, in actual usage that's very odd English, and seems wrong.  The RFC Editor can fix this, of course, but if you're editing the document anyway you might change it to plural usage by making it "There are" and "that have".  If that bothers you, you can also change "a number of" to "several", and you'll be correct both in common usage and technically.

IANA has reviewed draft-ietf-ccamp-gmpls-ted-mib-14 and has the following comments:

IANA understands that, upon approval of this document, there is
a single action which IANA must complete.

In the SMI Network Management MGMT Codes Internet-standard MIBsubregistry
of the Network Management Parameters registry located at:

http://www.iana.org/assignments/smi-numbers

a new MIB will be registered as follows:

Decimal: [ TBD by IANA at time of registration ]
Name: TED-MIB
Description: Traffic Engineering Database Support
References: [ RFC-to-be ]

IANA understands this to be the only action required of IANA upon
approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS) to Proposed Standard


The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'Traffic Engineering Database Management Information Base in support of
  MPLS-TE/GMPLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-10-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo defines the Management Information Base (MIB) objects in
  order to manage traffic engineering database (TED) information with
  extension in support of Multi-Protocol Label Switching (MPLS) with
  traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use
  with network management protocols.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ted-mib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ted-mib/ballot/


No IPR declarations have been submitted directly on this I-D.

AD Review
========

Hi,

I have carried out my normal AD review of your draft. There is no cause
for alarm!

This looks to be a sound document, but as always with MIB modules it is
possible to find a number of nits and questions. I would appreciate a
revision of the document before we move it forward so that it will get a
smoother ride through the rest of the process. I will put the document
into "Revised ID needed" state in the tracker.

As always, all issues and questions are open for discussion.

Thanks,
Adrian

---

Per idnits, please change the header
OLD
Intended status: Standards Truck
NEW
Intended status: Proposed Standard
END

---

I am not comfortable with the two definitions
  OAM:  Operations and Management
  OA&M:  Operations, Administration and Maintenance.
This is counter to RFC 6291which, although only guidelines, should be
followed unless there is a good reason. That RFC has...
  o  O&M - OAM and Management
  o  OAM - Operations, Administration, and Maintenance
Fortunately neither term is used in your document, and so they can be
deleted.

---

There are some acronyms in 3.3 that are not used in the rest of the
document: FSC, LDP, LSC, LSR, OAM, OA&M, RSVP,

---

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.

---

Section 6 is missing a close brace "}" for tedTable

---

The copyright date in the MODULE-IDENTITY is 2011.

---

You need to avoid using citations (e.g. [RFC3630]) within the MIB module
itself. MIB modules are extracted from their documents and stand alone.

---

The DESCRIPTION for the tedTable is
  "This table indicates multiple TED information which has been
  supported by [RFC3630]."

This seems to imply this doesn't apply to ISIS. Maybe update the text?

Similarly, a number of objects only give references to OSPF or OSPF-TE.
Not referencing the corresponding IS-IS specs looks like the object only
has meaning for OSPF.

---

  tedEntry OBJECT-TYPE
      SYNTAX      TedEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
      "This entry contains TED information commonly utilized in both
  MPLS and GMPLS."
      INDEX { tedLocalRouterId, tedRemoteRouterId,
  tedLinkInformationSource, tedLinkIndex }
  ::= { tedTable 1 }
   
  TedEntry ::= SEQUENCE {
      tedLinkInformationSource    INTEGER,
      tedLocalRouterId            TedRouterIdTC,
      tedRemoteRouterId            TedRouterIdTC,
      tedLinkIndex                TedLinkIndexTC,

It is unusual to list the index fields in a different order from that
which they appear in the table entry. Is this intended?

---

Tom's surname is misspelled in several of the references!

---                                                     

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?

          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?

---

  tedRouterIdAddrType OBJECT-TYPE
      SYNTAX      InetAddressType
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
        " This object indicates the TE-Router ID address type. Only
  values unknown(0), ipv4(1) or ipv6(2) must be supported. "

Do you mean s/must be/are/  ?

Similarly for tedLinkIdAddrType

---

It's a small point, but I would have preferred you to rename
tedRouterIdAddrType and tedRouterIdAddr as tedTeRouterIdAddrType and
tedTeRouterIdAddr to distinguish them from the normal router ID.

---

I don't understand what values should be returned for objects that
only apply in some circumstances. For example, in a non-GMPLS system,
what would be returned for tedLinkProtectionType? In either a non-GMPLS
system or one with numbered links, what values would be returned for
tedLocalId and tedRemoteId? What about tedSwCapIndication for non-TDM
links?

Section 6 says in these cases the objects are not supported, but I don't
think it is that simple. Or is it?

Even if it is that simple, I think the Description clauses should not
the circumstances under which the object is not supported.

(And yes, I do see the compliance statements which are very
comprehensive, but I think they say what you have to support in
specific circumstances, not how to behave if you support an object but
have no information to return.)

---   
   
  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.

---

A broader point about the use of addresses as indexes is found in
RFC 4001 in the Description of the InetAddress TC...

        When this textual convention is used as the syntax of an
        index object, there may be issues with the limit of 128
        sub-identifiers specified in SMIv2, STD 58.  In this case,
        the object definition MUST include a 'SIZE' clause to
        limit the number of potential instance sub-identifiers;
        otherwise the applicable constraints MUST be stated in
        the appropriate conceptual row DESCRIPTION clauses, or
        in the surrounding documentation if there is no single
        DESCRIPTION clause that is appropriate."

---

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?                               

---

Would the Notifications be more helpful if they indicated the index of
the entry in the tedTable to which they applied?

---

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.

Proto-write-up for: draft-ietf-ccamp-gmpls-ted-mib-13.txt

> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Standards Track.
> Why is this the proper type of RFC?

It defines a Management Information Base.

> Is this type of RFC indicated in the title page header?

Yes.

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:

Technical Summary

This memo defines the Management Information Base (MIB)
objects in order to manage traffic engineering database (TED)
information with extension in support of Multi-Protocol Label
Switching (MPLS) with traffic engineering (TE) as well as
Generalized MPLS (GMPLS) for use with network management
protocols.


> Working Group Summary
>
> Was there anything in WG process that is worth noting? For
> example, was there controversy about particular points or
> were there decisions where the consensus was particularly
> rough?

This document has been in the WG for a very long time, with
significant time/delays due to extended review and revision
cycles. There were no objections raised to it's publication.

> Document Quality
>
> Are there existing implementations of the protocol? Have a
> significant number of vendors indicated their plan to
> implement the specification? Are there any reviewers that
> merit special mention as having done a thorough review,
> e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If
> there was a MIB Doctor, Media Type or other expert review,
> what was its course (briefly)? In the case of a Media Type
> review, on what date was the request posted?

Implementation status is unknown (as is often the case). The
document has been through many review cycles, including review by
a MIB Doctor. Details are on the WG list.

> Personnel
>
> Who is the Document Shepherd? Who is the Responsible Area
> Director?

Lou Berger is the Document Shepherd. Adrian Farrel is the
Area Director.

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd. If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

To document was reviewed a number of times as it progressed
through the WG, as well as during WG last call. The document is
ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No concerns.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.

The document has been revied by a MIB Doctor.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes.

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?

The WG supports this document, but not may are passionate about it.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

No issues.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

This document has been reviewed by a, Joan Cucchiara.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

No.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in the
> Last Call procedure.

No.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

The sole IANA consideration is as follows, and appears appropriate
to the Document Shepherd:

The IANA is requested to assign {transmission XXX } to the TED-MIB
module specified in this document.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

Not applicable.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

MIB definitions were verified by the MIB Doctor.