Last Call Review of draft-ietf-mpls-tp-te-mib-09

Request Review of draft-ietf-mpls-tp-te-mib
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-12-08
Requested 2014-11-28
Authors Venkatesan Mahalingam, Kannan Sampath, Sam Aldrin, Thomas Nadeau
Draft last updated 2014-12-11
Completed reviews Genart Last Call review of -09 by Elwyn Davies (diff)
Opsdir Last Call review of -09 by Niclas Comstedt (diff)
Assignment Reviewer Elwyn Davies
State Completed
Review review-ietf-mpls-tp-te-mib-09-genart-lc-davies-2014-12-11
Reviewed rev. 09 (document currently at 11)
Review result Not Ready
Review completed: 2014-12-11


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-mpls-tp-te-mib-09.txt
Reviewer: Elwyn Davies
Review Date: 10 December 2014
IETF LC End Date: 8 December 2014
IESG Telechat date: (if known) -


Not  ready.  I am not a MIB expert nor an MPLS(-TP) configuration 

expert, so I have

assumed that the details of the MIB specification have been addressed by

Joan's MIB Doctor review and the configuration examples have been 

checked by an

MPLS-TP expert.  However, the introductory text needs significant work 

to make it

easier for people who are not MPLS-TP experts to come to grips with the 


The major issue with this document is that it appears to go against the 

current IETF view

that SNMP is not a satisfactory solution for configuring networks. The 

document has

effectively reiterated the RFC 3812 situation from 10 years ago when the 

IETF held its nose

and said that SNMP  was the only game in town even if security sucked. 

As I mention below, this was extensively discussed a year ago but I 

couldn't determine whether this draft was given

a special dispensation even though consensus seemed to be that writeable 

MIBs were

considered inappropriate.  If this is the case, it will be sufficient to 

adapt the end of s1.

AFAICS this draft has not had the 'grammar review' recommended by its AD 

about a year

ago and there are a number of areas in the object descriptions where 


improvements would be desirable in addition to notes given here. That is 

it still needs

the grammar review.

There are some more minor issues, particularly as regards the 

description of the types

of tunnel in s1, the discussion of the contents of the MIBs in s6 and 

possibly in regard to

the interaction with the standard interface table.

Major issues:

Support for configuration:

The issue of SNMPset (write) support was discussed at length in the 

context of

the MIB doctors' review of v-05 of this draft. The consensus at that 

time appeared

to be that provision of write support in new MIBs should be strongly 


I am unclear what the outcome of that discussion in the context of this 

draft was,

but it is clear that the draft is very much written from the point of 

using the MIB

as a configuration tool, especially in s9 (examples of usage). Whilst 

this technique

reflects the equivalent section is RFC 3813, that document was written 

over 10 years

ago and considerable effort has been devoted to providing alternative 

and more secure

ways of configuring networks in the intervening time. The body of the 

document has not

been altered to reflect the discussion that occurred.

"Lip service" is paid to the discouragement of the use of SNMPset by the 

addition of

para 3 of s1:

It is understood that SNMP SET is not used for MPLS configuration these
days, however the read-write and read-create option is still specified
for some objects as a way to provide the information model.

It is not clear to me why providing read-write or read-create options 

enhance the

MIB or are "a way to provide the information model".

I note that despite the extensive discussion of this topic by WG members 

and MIB specialists

back in December 2013, this issue was not flagged up in the Shepherd's 

write up.

If it has now been agreed that the configuration "flavour" is to be 

accepted as WG consensus

in spite of being contrary to current practice, it appears to me that 

the word "configuration"

should be removed from the last sentence of para 2 of s1 and the last 

para of s1 rewritten to

explain why write capabilities are used in a more convincing manner.

Minor issues:

Abstract/s1: Needs to be clear in both places that is is intended for 

MPLS-TP, this:

-- Abstract and s1: s/transport networks./MPLS networks conforming to 

the MPLS Transport Profile (MPLS-TP)./

s1: What is a Non-MPLS-TP (transport) network?

s1: The explanation of what the MIB extensions in this document actually 

do is not clear to the

general reader. I suggest replacing para 2 completely:

The existing MPLS Traffic Engineering (TE) Management Information Base
(MIB) [RFC3812] and Generalized Multiprotocol Label Switching (GMPLS)
Traffic Engineering Management Information Base [RFC4802] do not support
the management of transport network requirements of Tunnel end points
with non-IP based identifiers and static bidirectional tunnels. This
document focuses on static bidirectional MIB modules that should be used
in conjunction with [RFC3812] and companion document [RFC3813] for MPLS
Transport Profile (MPLS-TP) path configuration and management.


As described in the MPLS Traffic Engineering (TE) Management Information 

Base (MIB) definition [RFC3812], MPLS traffic engineering is concerned 

with the

creation and management of MPLS tunnels. This term is a shorthand for a

combination of one or one or explicitly routed LSPs (ERLSPs) linking an 


and an egress LSR. Several types of point-to-point MPLS tunnels may be 


between a pair of LSRs A and B:

- Unidirectional with a single LSP (say) from A to B.

- Associated bidirectional consisting of two separately routed ERLSPs, 

one linking

A to B and the other linking B to A. Together the pair provide a single 


bidirectional transport path.

- Corouted bidirectional consisting of an associated bidirectional 

tunnel but with

the second ERLSP from B to A following the reverse of the path of the ERLSP
from A to B, in terms of both nodes and links.

Tunnels may be either statically configured by management action or 

dynamically created using

a LSP management protocol.

The existing MPLS TE MIB [RFC3812] and the Generalized Multiprotocol 

Label Switching (GMPLS) Traffic Engineering Management Information Base 

[RFC4802] address only a subset of the

combinations of statically and dynamically configured tunnel types, 

catering for statically

configured unidirectional tunnels together with dynamically configured 

unidirectional and

corouted bidirectional tunnels. They are alsorestricted to to end point 

LSRs identified

by IP addresses.

The MPLS-TP TE MIB defined in this document extends the MIB defined in 

[RFC3812] to cover

all six combinations (that is adding support for statically configured 

associated and

corouted bidirectional plus dynamically configured associated 

bidirectional tunnels). It also

extends support to end points that are identified other than with IP 


This support is provided by a suite of four MIB modules that are to be 

used in conjunction

with the MIBS defined in [RFC3812] and the companion document [RFC3813] 

for MPLS

Transport Profile (MPLS-TP) TE path [configuration and]* management.


* Note: Using the term 'configuration' is inconsistent with the 

discussion in para 3.

See Major Issues above

s5, bullet 1: s8 in RFC 3812 discusses the use of the Interface Table 

with MPLS. It should be

made clear here:

1. Whether, if the MPLS-TP Tunnel is treated as an interface, there is 

any difference in the usage

of the ifTable fields as compared with standard MPLS. In particular if a 

different interface type

should be applicable.

2. Are there any issues if all or (more especially) a subset of the 

tunnels are not treated as


Row pointer usage: s9 of RFC 3812 considers Row Pointer usage - are 

there any differences or

additional considerations for these MIBs?

s6: Sections 6.1 to 6.4 are not MIBs (as indicated by the title and 

prologue) but MIB objects in

the MPLS-TE-EXT-STD-MIB MIB. Please reorganize s6 accordingly. Looking 

back at RFC3812, the

structure of the document in sections 5 and 6 appears to be more helpful 

to the new reader with a

summary of the four MIB modules in one section (expanded from ss6.5 - 

6.7) followed by notes on

the key MIB objects in each MIB as necessary. It would also be helpful 

to clarify where objects in

this MIB are expected to parallel those in the basic (RFC 3812) and note 

that they are indexed

equivalently (notably in the case of mplsTunnelTable and 


Nits/editorial comments:

General: Consistent use of bi-directional or bidirectional: Please 

choose one and use it throughout.

General: The qualifier "sparse" is used incorrectly in several places 

(e.g., sparsely extended).

Presumably the intention is that the extensions are "slight" or 

"limited" . In most cases the term

can be deleted: The degree of extension will ultimately be in the eyes 

of the implementer!

(s5 - 2 cases, s6.4, s7 - 2 cases, s8, s9.1.6, s9.2.9, s9.3.6, s12 - 3 


General: The figures need number and captions. The numbers should be 

used to refer to the figures.

s4, para 1: s/unidirectional tunnel/unidirectional tunnels/

s4, para 1, last sentence: s/re-use/re-use and extend/

s4, para 2:
retained in the same document, instead of a separate document.
all defined in this document, rather than split over several documents.

s5, para 1: s/This document identifies/The MIBs in this document satisfy/

s5, para 2: s/The MIB module supports/The MIB modules, taken together, 


s5, para 2: s/static and signaled/statically configured and dynamically 


s5, bullet 4: s/sparsely extended/extended/

s9.1.6, s9.2.9, s9.3.6: s/a sparse augmentation/a limited augmentation/

s5, bullet 5: It would be helpful to explain how node identification 

differs from

standard MPLS to understand why this mapping is needed. There appears to 

be text in s6.1 that might help

but it is too late to make it easy to understand this section.

ss10-13: It is conventional to give the RFCs used as references in the 

docuement s/RFC 3812/[RFC3812]/ etc.

s14: This is a near duplicate of the security considerations in RFC 

3812. It might be easier to reference

that section and add a note that extra tables may provide further 

sensitive information.

A brief discussion of whether the non-IP case makes any difference would 

be useful.

s16: At the very least RFC 3811, RFC 3812 and RFC 3813 are normative. 

RFC 6923 probably is.

RFC 6370 and RFC 4802 may also be.