Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-fastreroute-mib-15.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 5 Dec 2010 22:08:12 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft (draft-ietf-mpls-fastreroute-mib-15). The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-mpls-fastreroute-mib-15.txt 
Reviewer: Ben Niven-Jenkins Review Date: 3 December 2010
 IETF LC End Date: Not Known
 Intended Status: Standards Track

Summary: I have one major issue which is related to an omission from the MIB and some minor concerns about this document that I think should be resolved before publication.

Comments: My review was restricted to whether the MIBs specified in the document capture the necessary elements of MPLS FRR (RFC 4090), for example I did not attempt to compile the MIB to check for syntax errors etc. The document in general is easy to read but I feel there is still room for improvement that would add additional clarity for individuals trying to understand how to make use of the MIB. I feel that some of the items I list under "Minor Issues" are more than just minor but not significant enough to be classed as Major because they are comments against the descriptive text in the document and not the MIB definitions themselves.

Major Issues: 
1) There is no way in the MIB to read or set a value for "SE Style preferred" as defined in RFC4090 Section 4.3. This means there is no way to tell from looking at an instance of the MIB whether the ingress node is allowed to reroute the protecting LSP without tearing it down. Equally there is no way to read or set a value for "Bandwidth protection desired" as defined in RFC4090.

Minor Issues:
1) The document defines three MIB modules but it only provides an example of how it could be used for the MPLS-FRR-ONE2ONE-STD-MIB. Personally I find examples of how to use MIBs extremely helpful when I have had to make use of a MIB for configuration or diagnostics. I would suggest adding examples of usage for the other two MIBs specified in the document.

2) Section 4.2.2 explains how to identify a a detour LSP in the MIB, however the fields used for identification differ from those described in RFC4090 Section 6.1 so it is not clear to me how one could map between an RSVP-TE message and the corresponding MIB entry for that detour LSP. I would suggest including some wording to clarify how this could be done.

3) Section 4.2.2. includes the following two paragraphs:

      A detour LSP is also considered as an instance of a protected
      TE tunnel. Therefore, each detour LSP SHOULD have an entry in
      the mplsTunnelTable (defined in the MPLS-TE-STD-MIB[RFC3812]).

      In the mplsTunnelTable, the higher 16 bits of the tunnel instance
      SHOULD be used as a detour instance. Note that for the protected
      TE tunnel instances, the higher 16 bits of the tunnel instance
      MUST all be set to zero.

The first paragraph is fine and included here for context. The second paragraph is extremely difficult to parse, partly because it is not explicit as to when it is referring to a detour LSP Vs a protected LSP. If my interpretation is correct what you mean is that for protected LSPs the high order 16 bits should be set to 0 and for protecting LSPs the high order 16 bits should be used as a detour instance. So in the case of a detour LSP, it has two mplsTunnelTable entries - one with the high order bits set to 0 and one with the high order bits set to the detour instance?

4) Section 4.2.3. The example in this section places the mplsTunnelInstance for the protected LSP in the high order bits and the mplsTunnelInstance for the detour LSP in the low order bits. However section 4.2.2 specifics that they should be the other way round, i.e. protected LSP instance in the low order bits and detour LSP instance in the high order bits.

Ben