Skip to main content

Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute
draft-ietf-mpls-fastreroute-mib-21

Revision differences

Document history

Date Rev. By Action
2012-08-22
21 (System) post-migration administrative database adjustment to the No Objection position for Stewart Bryant
2012-08-22
21 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
21 (System) post-migration administrative database adjustment to the No Objection position for David Harrington
2011-09-26
21 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-09-16
21 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2011-09-16
21 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-09-13
21 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-09-12
21 (System) IANA Action state changed to In Progress
2011-09-12
21 Amy Vezza IESG state changed to Approved-announcement sent
2011-09-12
21 Amy Vezza IESG has approved the document
2011-09-12
21 Amy Vezza Closed "Approve" ballot
2011-09-09
21 Adrian Farrel Approval announcement text changed
2011-09-09
21 Adrian Farrel Approval announcement text regenerated
2011-09-09
21 Adrian Farrel Ballot writeup text changed
2011-09-09
21 David Harrington [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss
2011-09-02
21 (System) New version available: draft-ietf-mpls-fastreroute-mib-21.txt
2011-08-24
21 Adrian Farrel Ballot writeup text changed
2011-07-12
21 David Harrington
updated for -20-

my concerns mentioned for -18- have not been addressed, even the simple ones:

13) mplsFrrGeneralConstraintsIfIndexOrZero "That ifIndex of the underlying physical interface …
updated for -20-

my concerns mentioned for -18- have not been addressed, even the simple ones:

13) mplsFrrGeneralConstraintsIfIndexOrZero "That ifIndex of the underlying physical interface will be used as mplsFrrGeneralConstraintsIfIndexOrZero in this table to protect the LSPs or tunnel instances determined earlier." mplsFrrFacilityDBTable persistence is recommended, but ifIndex might not be persistent. It is perfectly legal to not support ifIndex persistence. I think this MIB module, as written, will not work correctly in any device that does not support ifIndex persistence across reboots. Ergo, it is not true that mplsFrrFacilityProtectedIfIndex "Uniquely identifies the interface configured for FRR protection." If the ifIndex values change upon device or management system reinitialization, then FRR protection might be applied to the wrong interface. What happens if, during a reboot, an interface is removed from the system, but mplsFrrGeneralConstraintsIfIndexOrZero or mplsFrrFacilityProtectedIfIndex point to that interface? The text RECOMMENDs that IfIndex persistence be implemented. I think this is inadequate. The Interfaces MIB provides mechanisms, such as ifAlias, to help re-sync dependencies on non-persistent ifIndex assignments. see RFC 2863 section 3.1.5 Use of those mechanisms would make this MIB module more viable across reboots.

16) what is the persistence of mplsFrrFacilityDBTable? what happens to mplsFrrFacilityDBEntry if ifIndex is not persistent across reinitializations of the system or the management system? It is perfectly legal to not support ifIndex persistence. I think this MIB module, as written, will not work correctly in any device that does not support ifIndex persistence across reboots. However, this MIB module could be made more robust by using the mechanisms defined in RFC2863.

20) The name of the MIB module is MPLS-FRR-GENERAL-STD-MIB FullCompliance clause references MPLS-FRR-GENERA-LSTD-MIB (this looks a typo during the edit.)

21) mplsFrrGeneralConstraintsTable is read-create, and is used by an administrator to set adminstrative policy about contraints. The description recommends persistence. If persistence makes protocol sense, then shouldn't this be a MUST? If it is only RECOMMENDS, please document the acceptable exceptions to the rule.

22) section 4.3.1 says "This table MUST be supported when facility backup is used." "supported" is rather ambiguous. This makes it sound like this table need not be supported when facility backup is not used. The table should be mandatory-to-implement, so the sentence isn't needed if "supported" means implemented. and presumably the values should be filled in when facility backup is "used". I am not sure what this sentemce is suppose to refer to in terms of support.
2011-06-16
21 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss
2011-06-15
20 (System) New version available: draft-ietf-mpls-fastreroute-mib-20.txt
2011-06-13
21 Dan Romascanu
[Ballot discuss]
1. The latest change in the MIB module fixed the pre-allocation problem but introduced another one. The LAST-UPDATED and REVISION clauses remained unchanged …
[Ballot discuss]
1. The latest change in the MIB module fixed the pre-allocation problem but introduced another one. The LAST-UPDATED and REVISION clauses remained unchanged at the level of the 2009 version. Now there are two sets of MIB modules with the same dates in these clauses but different contents. This is not acceptable. Please issue a new version with these clauses updated.

2. Make sure that the content of the OID place-holder is in synch with the comment that requests allocation from IANA (xxx, yyy, zzz).

3. Inform IANA about the change, so that they are aware about the allocations they need to make.
2011-06-02
19 (System) New version available: draft-ietf-mpls-fastreroute-mib-19.txt
2011-06-02
21 David Harrington
[Ballot comment]
7) (downgraded from discuss)
mplsFrrGeneralConstraintsRowStatus says no objects can be modified by the agent, but the rows are read-create; is the manager allowed …
[Ballot comment]
7) (downgraded from discuss)
mplsFrrGeneralConstraintsRowStatus says no objects can be modified by the agent, but the rows are read-create; is the manager allowed to modify objects in the row? (and see previous note about agent/manager terminology)

The text is specific - "no objects in the row can be modified by"
**the agent**
I recommend dropping the "by the agent" from this, to make it clear
nobody can modify it.



20) Comment - no action required, but I think it would improve the
document:
the naming of the clause is also inconsistent, for no apparent reason.
Compare:
MPLS-FRR-GENERAL-STD-MIB (which has an STD in it for some reason) and
mplsFrrGeneralModuleFullCompliance (which dropped the Std part, and
added Module).
I actually prefer eliminating the STD part (and Module part) since it
doesn't add anything.
But that's just a personal preference.
2011-06-02
21 David Harrington
[Ballot discuss]
update for rev 18

13) mplsFrrGeneralConstraintsIfIndexOrZero "That ifIndex of the underlying physical interface will be used as mplsFrrGeneralConstraintsIfIndexOrZero in this table to protect …
[Ballot discuss]
update for rev 18

13) mplsFrrGeneralConstraintsIfIndexOrZero "That ifIndex of the underlying physical interface will be used as mplsFrrGeneralConstraintsIfIndexOrZero in this table to protect the LSPs or tunnel instances determined earlier."
mplsFrrFacilityDBTable persistence is recommended, but ifIndex might not be persistent.
It is perfectly legal to not support ifIndex persistence. I think this MIB module, as written, will not work correctly
in any device that does not support ifIndex persistence across reboots.
Ergo, it is not true that mplsFrrFacilityProtectedIfIndex "Uniquely identifies the interface configured for FRR
          protection."

If the ifIndex values change upon device or management system reinitialization, then FRR protection might be applied to the wrong interface.

What happens if, during a reboot, an interface is removed from the system, but mplsFrrGeneralConstraintsIfIndexOrZero or mplsFrrFacilityProtectedIfIndex point to that interface?

The text RECOMMENDs that IfIndex persistence be implemented.
I think this is inadequate.
The Interfaces MIB provides mechanisms, such as ifAlias, to help re-sync
dependencies on non-persistent ifIndex assignments. see RFC 2863 section 3.1.5
Use of those mechanisms would make this MIB module more viable across reboots.

16) what is the persistence of mplsFrrFacilityDBTable?
what happens to mplsFrrFacilityDBEntry if ifIndex is not persistent across reinitializations of the system or the management system?
It is perfectly legal to not support ifIndex persistence. I think this MIB module, as written, will not work correctly
in any device that does not support ifIndex persistence across reboots.
However, this MIB module could be made more robust by using the mechanisms defined in RFC2863.

20) The name of the MIB module is MPLS-FRR-GENERAL-STD-MIB
FullCompliance clause references  MPLS-FRR-GENERA-LSTD-MIB
(this looks a typo during the edit.)

21) mplsFrrGeneralConstraintsTable is read-create, and is
used by an administrator to set adminstrative policy about contraints.
The description recommends persistence. If persistence makes protocol sense, then shouldn't this be a MUST?
If it is only RECOMMENDS, please document the acceptable exceptions to the rule.

22) section 4.3.1 says "This table MUST be supported when facility backup is used."
"supported" is rather ambiguous.
This makes it sound like this table need not be supported when facility backup is not used.
The table should be mandatory-to-implement, so the sentence isn't needed if "supported" means implemented.
and presumably the values should be filled in when facility backup is "used".
I am not sure what this sentemce is suppose to refer to in terms of support.
2011-06-02
21 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-06-02
18 (System) New version available: draft-ietf-mpls-fastreroute-mib-18.txt
2011-05-17
21 Adrian Farrel State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup.
2011-05-16
21 David Harrington
[Ballot comment]
7) (downgraded from discuss)
mplsFrrGeneralConstraintsRowStatus says no objects can be modified by the agent, but the rows are read-create; is the manager allowed …
[Ballot comment]
7) (downgraded from discuss)
mplsFrrGeneralConstraintsRowStatus says no objects can be modified by the agent, but the rows are read-create; is the manager allowed to modify objects in the row? (and see previous note about agent/manager terminology)

The text is specific - "no objects in the row can be modified by"
**the agent**
I recommend dropping the "by the agent" from this, to make it clear
nobody can modify it.


10) mplsFrrGeneralModuleFullCompliance supports the MPLS-FRR-GENERALSTD-MIB
    mplsFrrGeneralModuleReadOnlyCompliance supports MPLS FRR MIB
Shouldn't these be consistent in naming the MIB they support?

I think this is still wrong.
The name of the MIB module is MPLS-FRR-GENERAL-STD-MIB (see the BEGIN
statement)
but the FullCompliance clause references the MPLS-FRR-GENERALSTD-MIB
module.

20) Comment - no action required, but I think it would improve the
document:
the naming of the clause is also inconsistent, for no apparent reason.
Compare:
MPLS-FRR-GENERAL-STD-MIB (which has an STD in it for some reason) and
mplsFrrGeneralModuleFullCompliance (which dropped the Std part, and
added Module).
I actually prefer eliminating the STD part (and Module part) since it
doesn't add anything.
But that's just a personal preference.
2011-05-16
21 David Harrington
[Ballot discuss]
update for rev 17

I removed the points that have been resolved.

3) mplsFrrGeneralConstraintsEntry talks about what agents must allow. SNMPv3 moved away …
[Ballot discuss]
update for rev 17

I removed the points that have been resolved.

3) mplsFrrGeneralConstraintsEntry talks about what agents must allow. SNMPv3 moved away from the agent/manager terminology to discussion of specific application functionality, such as Command Responders, because the SNMPv1 concept of agent was no longer valid after Informs were defined.

The new text changes from "agent" to "Command responder", without considering
context. That was a mistake. I was pointing out that the terminology had
been changed; I was not suggesting a simple 1:1 swap of terminology.
The context needs to be considered. For example:

a) the "Compliance statements for Command Responder" is wrong; a
compliance statement refers to a whole snmp engine, not just the
command responder application.

b) in mplsFrrGeneralConstraintsEntry, "Command responders must only
allow" is wrong; this should be "SNMP engines must only allow"

There are still instances of "agent" in the text.

6) The MIB does not discuss the persistence of tables and objects across reboots. That will have an effect in a number of places.

I don't think StorageType addresses my question.
For example, mplsFrrGeneralConstraintsTable is read-create, and is
used by an administrator to set adminstrative policy about contraints.
Presumably, if this is a general policy, you would like this policy to
persist across reboots, so when the device restarts, the contraints
are still followed. On the other hand, if each row describes the
constraints for a specific link that goes away when the device reboots,
then you don't need to keep the link-specific constraint; you would
define the constraint when a new link is defined.

The table description, the entry description, and the storagetype do
not discuss cross-reboot persistence.
I recommend it be discussed in the table or entry description.

mplsFrrGeneralConstraintsEntry does contain some discussion of
persistence, but it is about ifIndex persistence. I will discuss that
in point 13 below.

9) mplsFrrGeneralTunnelARHopProtectTypeInUse seems to only support IPv4. Why?

The new text is slightly wrong. In a BITS object, you can set one, none,
all, or any combination of bits.
Your new text only allows one, none, or all; It woiuldn't allow for, say, two bits to be set. That is wrong.

12) what happens if mplsFrrGeneralConstraintsEntry is created, but the corresponding row in MplsTunnelIndex does not exist?

Solving the deletion anomaly does not solve the addition anomaly.
You need to state that the row cannot be created if a corresponding
row in MplsTunnelIndex does not already exist.
Or you need to state that creation of this row forces creation of a
corresponding row in MplsTunnelIndex (and for this option, you need to
make sure enough info would be available to create the other row).

13) mplsFrrGeneralConstraintsIfIndexOrZero "That ifIndex of the underlying physical interface will be used as mplsFrrGeneralConstraintsIfIndexOrZero in this table to protect the LSPs or tunnel instances determined earlier."
What happens if the ifIndex values used in ifStackTable change upon device or management system reinitialization? What is the persistence of mplsFrrGeneralConstraintsTable?

The new text RECOMMENDs that IfIndex persistence be implemented.
I think this is inadequate.
ifIndex persistence or non-persistence is an engineering design
choice, largely based on whether hot-swapping is permitted in the
device, and it can be difficult to know whether an interface detected on startup
is the same interface that existed before reboot, and to keep the same ifIndexes
assigned to the same interfaces. It is perfectly legal to not support ifIndex persistence. I
think this MIB module, as written, will not work in any device that
does not support ifIndex persistence across reboots.

The Interfaces MIB provides mechanisms, such as ifAlias, to re-sync
dependencies on non-persistent ifIndex assignments. see RFC 2863 section 3.1.5
Use of those mechanisms would make this MIB module more viable across
reboots.
Failure to do so can cause entries in this MIB module to be applied to
the wrong interfaces after a reboot.


14) should mplsFrrOne2OnePlrSenderAddrType and mplsFrrOne2OnePlrSenderAddr be read-write rather than read-create? If read-create, shouldn't there be a rowstatus object? if read-create, what happens if one of these objects is deleted?

I'm not aksing you to blindly change this to
read-write. I am asking you to consider whether read-write is a better
choice than read-create, and if read-create is appropriate, does it
need additional support such as rowstatus?

16) what is the persistence of mplsFrrFacilityDBTable?
what happens to mplsFrrFacilityDBEntry if ifIndex is not persistent across reinitializations of the system or the management system?

I recommend stating explciitly that this table is not persistent so nobody evers tries to extend the
table with a read-write object.

19) (upgraded from comment #8)
mplsFrrGeneralTunnelARHopEntry 

The new text says this table MUST be supported when RRO is supported.
Using a MUST makes this a compliance requirement.
You need to deal with compliance requirements in a compliance clause.
Typically, we avoid using conditional-compliance because it adds
complexity with little gain.
If you want RRO-suppoorted complaince, and RRO-not-supported
compliance, then you would need to define complaince clauses for
FullCompliance, FullReadOnlyCompliance, FullexceptRROcomplliance,
FullexceptRROReadOnlyComplaince, and so on.

I recommend just removing the sentence and let everybody implement the
object whether RRO is supported or not.
And you should specify the values of the objects when RRO is not
supported (preferably in the object descriptions).
2011-05-06
21 Stewart Bryant [Ballot comment]
2011-05-06
21 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss
2011-05-05
21 Dan Romascanu
[Ballot discuss]
The document used a process which is not recommended pre-assigning mib-2 OIDs for the roots of the three MIB modules in sections 8.1 …
[Ballot discuss]
The document used a process which is not recommended pre-assigning mib-2 OIDs for the roots of the three MIB modules in sections 8.1 to 8.3. We discourage this practice, as one MIB document designer does not necessarily know what other authors are doing in their documents. The allocation request in this document must be changed and final allocation of OIDs left only to IANA.
2011-04-25
21 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-04-25
17 (System) New version available: draft-ietf-mpls-fastreroute-mib-17.txt
2011-01-22
21 Adrian Farrel State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup.
2011-01-18
21 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-01-18
16 (System) New version available: draft-ietf-mpls-fastreroute-mib-16.txt
2010-12-17
21 David Harrington Request for Telechat review by TSVDIR Completed. Reviewer: David Harrington.
2010-12-17
21 David Harrington Request for Telechat review by TSVDIR is assigned to David Harrington
2010-12-17
21 David Harrington Request for Telechat review by TSVDIR is assigned to David Harrington
2010-12-17
21 (System) Removed from agenda for telechat - 2010-12-16
2010-12-16
21 Amy Vezza State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2010-12-16
21 Stewart Bryant
[Ballot discuss]
These issues are based on the RTG Area review.

I understand that the reviewers and editors have agreed text. I will clear when …
[Ballot discuss]
These issues are based on the RTG Area review.

I understand that the reviewers and editors have agreed text. I will clear when the next version is posted.

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.

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. This should be described.

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. Do you mean 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?

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.
2010-12-16
21 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2010-12-16
21 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2010-12-15
21 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded
2010-12-15
21 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2010-12-15
21 Dan Romascanu
[Ballot discuss]
Item #2 in the DISCUSS was modified following input from IANA.

1. David Harrington made a number of comments in his DISCUSS and …
[Ballot discuss]
Item #2 in the DISCUSS was modified following input from IANA.

1. David Harrington made a number of comments in his DISCUSS and COMMENT which I support. Especially issues #2 (SNMPv3 specific error messages) and #18 (security considerations template) must absolutely be resolved before this document can be approved.

2. The document used a process which is not recommended pre-assigning mib-2 OIDs for the roots of the three MIB modules in sections 8.1 to 8.3. We discourage this practice, as one MIB document designer does not necessarily know what other authors are doing in their documents. In this case the MIB authors request the allocation of OIDs already in use:

mib-2 numbers 187-189 have already been assigned:

    187  forcesMIB          FORCES-MIB                  [RFC5813]
    188  pwTcStdMIB        PW-TC-STD-MIB              [RFC5542]
    189  sshtmMIB          Secure Shell Transport Model MIB  [RFC5592]

The allocation request in this document must be changed and final allocation of OIDs left only to IANA.

3. It is not clear to me the reason of defining DEFVAL values for read-only objects (mplsFrrIncomingDetourLSPs, mplsFrrOne2OneDetourOriginating, and other). Although bot explicitly forbidden by the SMI rules, read-only objects are filled in as soon as the agent can complute a meaningful value, so default values are in effect for a very short time at initialization and typically not used. If there is any special need in this case it should be described and explained.
2010-12-14
21 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2010-12-14
21 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2010-12-14
21 Sean Turner
[Ballot comment]
#1 Spell out first use of LSR.

#2) On page 7:

a) Need "--" before mplsFrr...?

        -- The first …
[Ballot comment]
#1 Spell out first use of LSR.

#2) On page 7:

a) Need "--" before mplsFrr...?

        -- The first value would be:
                          mplsFrrOne2OneDetourActive.1.6553601


b) Need comma after "= 0" in the following?

    mplsFrrOne2OneDetourMergedDetourInst  = 0
      }
2010-12-14
21 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2010-12-14
21 Dan Romascanu
[Ballot comment]
1. It is not clear to me what the follwing text means in the DESCRIPTION clause of mplsFrrGeneralTunnelARHopTable

          …
[Ballot comment]
1. It is not clear to me what the follwing text means in the DESCRIPTION clause of mplsFrrGeneralTunnelARHopTable

          Note that object
          availability in this table is governed by the support of
          the Record Route Object in the RSVP-TE signaling of the
          implementation.

Does this apply to all objects in the table? How does an operator know that the fact that this table is not populated is due to the lack of support of the Record Route Object?

2. OBJECT        mplsFrrGeneralConstraintsRowStatus
      MIN-ACCESS    read-only
      DESCRIPTION
        "Write access is not required."

Not requiring write access for a RowStatus object means that the respective table does not support dynamic row creation. How is it populated? I think that some explanation is needed for this case.

3. Specifying just RFC4090 with no clause as REFERENCE  like for mplsFrrOne2OnePlrAvoidNodeAddr seems very vague and not useful. Same for RFC3812 provided as REFERENCE for mplsFrrFacilityProtectingTunnelIndex.
2010-12-14
21 Dan Romascanu
[Ballot discuss]
1. David Harrington made a number of comments in his DISCUSS and COMMENT which I support. Especially issues #2 (SNMPv3 specific error messages) …
[Ballot discuss]
1. David Harrington made a number of comments in his DISCUSS and COMMENT which I support. Especially issues #2 (SNMPv3 specific error messages) and #18 (security considerations template) must absolutely be resolved before this document can be approved.

2. The document used a process which is not recommended pre-assigning mib-2 OIDs for the roots of the three MIB modules in sections 8.1 to 8.3. We discourage this practice, as one MIB document designer does not necessarily know what other authors are doing in their documents. I would recommend that IANA confirms  that { mib-2 187 } { mib-2 188 } { mib-2 189 } are indeed not assigned or not in process of being assigned for other purposes and that this assignment can be reserved until the document is published.

3. It is not clear to me the reason of defining DEFVAL values for read-only objects (mplsFrrIncomingDetourLSPs, mplsFrrOne2OneDetourOriginating, and other). Although bot explicitly forbidden by the SMI rules, read-only objects are filled in as soon as the agent can complute a meaningful value, so default values are in effect for a very short time at initialization and typically not used. If there is any special need in this case it should be described and explained.
2010-12-14
21 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded
2010-12-13
21 David Harrington
[Ballot comment]
8) I am not sure what "object availability" means in mplsFrrGeneralTunnelARHopEntry 

10) mplsFrrGeneralModuleFullCompliance supports the MPLS-FRR-GENERALSTD-MIB
    mplsFrrGeneralModuleReadOnlyCompliance supports MPLS FRR MIB …
[Ballot comment]
8) I am not sure what "object availability" means in mplsFrrGeneralTunnelARHopEntry 

10) mplsFrrGeneralModuleFullCompliance supports the MPLS-FRR-GENERALSTD-MIB
    mplsFrrGeneralModuleReadOnlyCompliance supports MPLS FRR MIB
Shouldn't these be consistent in naming the MIB they support?

s/agents/Command Responders/ ??

15) mplsFrrOne2OneModuleFullCompliance supports MPLS-FRR-ONE2ONE-STD-MIB
    mplsFrrOne2OneModuleReadOnlyCompliance supports MPLS FRR ONE2ONE MIB
shoudn't these be consistent?

17) RFC4181 says abbreviations should be consistent. mplsFrrFacilityBackupTunnelEgressLSRId  and mplsFrrFacilityInitialBkupTunnelInvoked  are inconsistent.
This makes it harder for operators to remember whether an name contains "Backup" or "Bkup".
2010-12-13
21 David Harrington
[Ballot discuss]
1) I think the following is invalid. Is it legal to have different max-access for different enumerations in the same object?

  mplsFrrGeneralProtectionMethod …
[Ballot discuss]
1) I think the following is invalid. Is it legal to have different max-access for different enumerations in the same object?

  mplsFrrGeneralProtectionMethod OBJECT-TYPE
      SYNTAX        INTEGER {
                              unknown(1),
                              oneToOneBackup(2),
                              facilityBackup(3)
                            }
      MAX-ACCESS    read-write
      STATUS        current
      DESCRIPTION
        "Indicates which protection method is to be used for fast
          reroute on this device. Some devices may require a reboot
          if this variable is to take affect after being modified.
          The value of unknown(1) is read-only and cannot be set.
          If the value of unknown(1) is set an inconsistentValue error
          MUST be returned. It is provided to correct any
          misconfiguration."
      ::= { mplsFrrGeneralObjects 1 }


2) This error processing would seem to be invalid. inconsistentValue is an SNMPv3 error code; this object could not be used with SNMPv1 or SNMPv2c. That would violate RFC1052 and RFC3410 architectural separation of the protocol from the MIB.

3) mplsFrrGeneralConstraintsEntry talks about what agents must allow. SNMPv3 moved away from the agent/manager terminology to discussion of specific application functionality, such as Command Responders, because the SNMPv1 concept of agent was no longer valid after Informs were defined.

4) I am not sure how agents know what the LSP signalling allows, especially in a master/subagent architecture implementation.

5) mplsFrrGeneralConstraintsEntry : [citations] are not allowed in MIB modules because a MIB module is often distributed separately from the surrounding document. A REFERENCE clause, or textual mention of an RFC# is acceptable.

6) The MIB does not discuss the persistence of tables and objects across reboots. That will have an effect in a number of places.

7) mplsFrrGeneralConstraintsRowStatus says no objects can be modified by the agent, but the rows are read-create; is the manager allowed to modify objects in the row? (and see previous note about agent/manager terminology)

9) mplsFrrGeneralTunnelARHopProtectTypeInUse seems to only support IPv4. Why?

11) what happens to mplsFrrOne2OnePlrEntry if the corresponding row in the mplsTunnelTable is deleted?

12) what happens if mplsFrrGeneralConstraintsEntry is created, but the corresponding row in MplsTunnelIndex does not exist?

13) mplsFrrGeneralConstraintsIfIndexOrZero "That ifIndex of the underlying physical interface will be used as mplsFrrGeneralConstraintsIfIndexOrZero in this table to protect the LSPs or tunnel instances determined earlier."
What happens if the ifIndex values used in ifStackTable change upon device or management system reinitialization? What is the persistence of mplsFrrGeneralConstraintsTable?

14) should mplsFrrOne2OnePlrSenderAddrType and mplsFrrOne2OnePlrSenderAddr be read-write rather than read-create? If read-create, shouldn't there be a rowstatus object? if read-create, what happens if one of these objects is deleted?

16) what is the persistence of mplsFrrFacilityDBTable?
what happens to mplsFrrFacilityDBEntry if ifIndex is not persistent across reinitializations of the system or the management system?

18) There is a security template for MIB modules that was written to meet exact requirements. Authors often think they can improve upon the wording, but almost always get it wrong.

The template has been modifed in this document, in a manner that is inappropriate. This text is inappropriate because a MIB should not require a specific version of SNMP be used, or specific SNMPv3 MIB modules be used:
        The use of stronger
        mechanisms such as SNMPv3 security should be considered where
        possible.  Specifically, SNMPv3 VACM and USM MUST be used with
        any v3 agent which implements these MIB modules.
The SNMPv3 standard (STD61) has VACM and USM as mandatory-to-implement, but not mandatory-to-use. The RFC3410 architecture was designed so different access control models and different security models and different SNMP message versions can be used within an SNMP system. The security provided by the SSH Transport Model (RFC5592) or (D)TLS (RFC 5953) with the Transport Security Model (RFC5591) is equally strong as USM, and reuses existing security infrastructure. There is no reason why USM MUST be **used** with any v3 agent that supports this MIB.
2010-12-13
21 David Harrington [Ballot Position Update] New position, Discuss, has been recorded
2010-12-13
21 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2010-12-13
21 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2010-12-13
21 Stewart Bryant
[Ballot comment]
From the RtgArea review:

"The document defines three MIB modules but it only provides an example of how it could be used for …
[Ballot comment]
From the RtgArea review:

"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."
2010-12-13
21 Stewart Bryant
[Ballot discuss]
There is no way in the MIB to read or set a value for "SE Style preferred" as defined in RFC4090 Section 4.3. …
[Ballot discuss]
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.

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. This should be described.

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. Do you mean 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?

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.
2010-12-13
21 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded
2010-12-06
21 Adrian Farrel State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2010-12-06
21 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2010-12-03
21 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2010-12-03
21 Adrian Farrel Ballot has been issued
2010-12-03
21 Adrian Farrel Created "Approve" ballot
2010-12-03
21 Adrian Farrel Placed on agenda for telechat - 2010-12-16
2010-11-30
21 Samuel Weiler Request for Last Call review by SECDIR is assigned to Love Astrand
2010-11-30
21 Samuel Weiler Request for Last Call review by SECDIR is assigned to Love Astrand
2010-11-29
21 Amanda Baber
IANA has a question about the IANA Actions related to this document.

IANA understands that, upon approval of this document, there are three
IANA Actions …
IANA has a question about the IANA Actions related to this document.

IANA understands that, upon approval of this document, there are three
IANA Actions that must be completed.

First, in the SMI Network Management MGMT Codes registry [Prefix:
iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)] located at:

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

the MIB documented in Section 6.1 of the approved document is to be
registered as follows:

Decimal: TBD (see note below)
Name: mplsFrrGeneralMIB
Description: MPLS-FRR-GENERAL-STD-MIB
Reference: [RFC-to-be]

Second, in the SMI Network Management MGMT Codes registry [Prefix:
iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)] located at:

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

the MIB documented in Section 6.2 of the approved document is to be
registered as follows:

Decimal: TBD (see note below)
Name: mplsFrrOne2OneMIB
Description: MPLS-FRR-ONE2ONE-STD-MIB
Reference: [RFC-to-be]

Third, in the SMI Network Management MGMT Codes registry [Prefix:
iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)] located at:

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

the MIB documented in Section 6.3 of the approved document is to be
registered as follows:

Decimal: TBD (see note below)
Name: mplsFrrFacilityMIB
Description: MPLS-FRR-FACILITY-STD-MIB
Reference: [RFC-to-be]

IANA notes that the editors of the document have requested specific
decimal numbers for these MIBs, but that these numbers are no longer
available.

IANA Question --> May IANA simply use the next available decimal numbers
to identify the three MIBs documented in the [RFC-to-be]?

IANA understands that these three actions are all that need to be
completed upon approval of this document.
2010-11-22
21 Amy Vezza Last call sent
2010-11-22
21 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute) to Proposed Standard

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Multiprotocol Label Switching (MPLS) Traffic Engineering Management
  Information Base for Fast Reroute'
  as a 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 2010-12-06. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-fastreroute-mib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-fastreroute-mib/
2010-11-22
21 Adrian Farrel Last Call was requested
2010-11-22
21 Adrian Farrel State changed to Last Call Requested from AD Evaluation::AD Followup.
2010-11-22
21 Adrian Farrel Last Call text changed
2010-11-22
21 (System) Ballot writeup text was added
2010-11-22
21 (System) Last call text was added
2010-11-22
21 (System) Ballot approval text was added
2010-11-22
21 Adrian Farrel Ballot writeup text changed
2010-11-08
21 Adrian Farrel State changed to AD Evaluation::AD Followup from AD Evaluation by Adrian Farrel
2010-11-08
21 Adrian Farrel State changed to AD Evaluation from AD is watching by Adrian Farrel
2010-11-07
21 Cindy Morgan State changed to AD is watching from Dead by Cindy Morgan
2010-11-07
15 (System) New version available: draft-ietf-mpls-fastreroute-mib-15.txt
2010-10-09
21 (System) Document has expired
2010-04-07
14 (System) New version available: draft-ietf-mpls-fastreroute-mib-14.txt
2010-01-07
21 (System) State Changes to Dead from AD is watching by system
2010-01-07
21 (System) Document has expired
2009-09-16
21 Adrian Farrel State Changes to AD is watching from AD Evaluation by Adrian Farrel
2009-08-17
21 Adrian Farrel State Changes to AD Evaluation from Publication Requested by Adrian Farrel
2009-07-09
21 Cindy Morgan State Changes to Publication Requested from AD is watching by Cindy Morgan
2009-07-09
21 Cindy Morgan [Note]: 'Loa Andersson (loa@pi.nu) is the document shepherd.' added by Cindy Morgan
2009-07-09
21 Cindy Morgan
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he …
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Loa Andersson is the document shepherd.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document is very well reviewed, by the mpls and ccamp
working groups. The document has had an intensive MIB Doctor
review by Joan Cucchiara, who recommends publication of the
draft.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

no

(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

no

(1.e) 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?

after a long time and much worl the consensus is now very
solid

(1.f) 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
entered into the ID Tracker.)

no

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

no nits.


(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

the references are split into normative and informative
references

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists, and there are IANA
allocations to be made.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The documentis a MIB and compiles clean.

(1.k) 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
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This memo defines a portion of the Management Information Base
for use with network management protocols in the Internet
community.
In particular, it describes managed objects used to support two
fast reroute (FRR) methods for Multiprotocol Label Switching
(MPLS) based traffic engineering (TE). The two methods are
one-to-one backup method and facility backup method.


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?

No controversies, but lots of discussion that has converged on
this document, and the document has taken a rthr long time to
progress.

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?

We are aware of one implementations, but we have not polled
the working group list for other implementations.
2009-07-09
21 Cindy Morgan Responsible AD has been changed to Adrian Farrel from Ross Callon
2009-07-09
21 Cindy Morgan Intended Status has been changed to Proposed Standard from None
2009-07-06
13 (System) New version available: draft-ietf-mpls-fastreroute-mib-13.txt
2009-06-24
12 (System) New version available: draft-ietf-mpls-fastreroute-mib-12.txt
2009-03-16
21 Ross Callon State Changes to AD is watching from Dead by Ross Callon
2009-02-24
11 (System) New version available: draft-ietf-mpls-fastreroute-mib-11.txt
2008-09-29
10 (System) New version available: draft-ietf-mpls-fastreroute-mib-10.txt
2008-07-03
09 (System) New version available: draft-ietf-mpls-fastreroute-mib-09.txt
2008-05-22
21 (System) Document has expired
2008-05-22
21 (System) State Changes to Dead from AD is watching by system
2007-11-20
21 Bill Fenner Responsible AD has been changed to Ross Callon from Bill Fenner
2007-11-20
21 (System) State Changes to AD is watching from Dead by system
2007-11-19
08 (System) New version available: draft-ietf-mpls-fastreroute-mib-08.txt
2007-09-06
21 (System) State Changes to Dead from AD is watching by system
2007-09-06
21 (System) Document has expired
2007-03-05
07 (System) New version available: draft-ietf-mpls-fastreroute-mib-07.txt
2006-10-05
21 Bill Fenner Shepherding AD has been changed to Bill Fenner from Alex Zinin
2006-10-05
21 Dan Romascanu State Change Notice email list have been change to mpls-chairs@tools.ietf.org; from mpls-chairs@tools.ietf.org; jcucchiara@mindspring.com
2006-10-05
21 Dan Romascanu
10/5/2006 - MIB Doctor Review performed by Joan Cucchiara

OVERALL COMMENTs
---------------

*) MIB compiles cleanly with smiLint and
smicngPRO.


*) First overall comment has …
10/5/2006 - MIB Doctor Review performed by Joan Cucchiara

OVERALL COMMENTs
---------------

*) MIB compiles cleanly with smiLint and
smicngPRO.


*) First overall comment has to do with the organization
of the MIB module itself; a better way
to represent the objects would be to have separate MIB
modules for General, One2One and Facility. 

Even the scalar objects seem dependent on
which method is being used so seems that separate
MIB modules would help to clarify this.
Please comment.

*) I tried to be very specific about this during the
commenting, but basically would ask that the names used
be consistent with the MPLS-TE-STD-MIB.  For example,
Tunnel, Index, Instance, Ingress, Egress and other words
are spelled out when used in an object's name, but in
this MIB Module these are abbreviated.  Just looking for
some consistency with the naming conventions used in the
2 MIBs since they are tightly coupled.

COMMENTS ON DOC (as they appear in the doc)
---------------------------------------------
*) Abstract:
    In particular, it describes managed objects for Multiprotocol Label
    Switching fast rerouting.

suggestion to specify the 2 fast reroute methods:

...managed objects used to support two fast reroute (FRR) methods for
Multiprotocol Label Switching (MPLS) based traffic engineering (TE).
The two methods are one-to-one backup method and facility backup
method.

*) Date on the page headers do not match
date of document.


*) TOC
References is off by a space.

Also, the subsections 1.1, 4.1, 4.2
(maybe others) are missing from the TOC.

*) 1. Introduction

Would add RFC3811 also, i.e.
used in conjunction with [RFC3811], [RFC3812] and
[RFC3813].

*) 2. Terminology

Should state the title of the referenced docs
here.

So
This document uses terminology defined in the
"Multiprotocol Label Switching Architecture" [RFC3031]
document
and  the "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels" [RFC4090] document.

*) 4. Brief Description of the MIB Module Objects.
s/Objects./Objects
Would retitle this section:
Overview of the MIB Module

I am confused by the term "bypass" in this section.
Are you referring to the one-to-one backup method
described in [RFC4090]?  Could the terms one-to-one
and facility be used consistently?


"LSRs do not implement both facility and bypass methods
at the same time, the Agent Compliance section in this
module defined herein is divided into portions, one for
each method allowing any LSR to implement only the objects
applicable to the method they have implemneted."

Either correct the above statement:
s/Agent Compliance/Conformance
s/implemneted/implemented


or reword:

"LSRs do not implement both one-to-one backup method and
facility backup method
at the same time, thus, the Conformance section specifies
conformance based on the two fast reroute methods.  This allows
a developer to implement only the objects applicable to
the fast reroute method supported."

Additionally, RFC4090 states:
  Two methods are defined here.  The one-to-one backup method creates
  detour LSPs for each protected LSP at each potential point of local
  repair.  The facility backup method creates a bypass tunnel to
  protect a potential failure point; by taking advantage of MPLS label
  stacking, this bypass tunnel can protect a set of LSPs that have
  similar backup constraints.  Both methods can be used to protect
  links and nodes during network failure.  The described behavior and
  extensions to RSVP allow nodes to implement either method or both and
  to interoperate in a mixed network.

However, the draft states:
    ...Given that common practice has shown that
    LSRs do not implement both facility and bypass methods
    at the same time...is divided into portions, one for each method

In this regard the draft differs somewhat significantly from
RFC4090.  Could this be clarified?  In other words, could the
draft say something like, "although [RFC4090] specifies that a
node is able to support both fast reroute methods simultaneously,
common practice has shown...."


I would like to understand what is meant by common practice?
Is it that vendors don't support both methods at the same time, or
is it that operators don't mix these 2 methods in a network?

*) 4.1 mplsFrrConstTable
Please use the entire name Constraints, as in
mplsFrrConstraintsTable.

*) 4.2 mplsFrrTunARHopTable
Please use mplsFrrTunnelARHopTable to match
with mplsTunnelARHopTable.

First sentence:
s/mplsTunnelARHop table/mplsTunnelARHopTable

*) 4.3  mplsFrrOne2OnePlrTable


"The mplsFrrOne2OnePlrTable is an optional table that contains
    lists of PLRs that initiated detour LSPs to protect tunnel
    instances. As such, it is only required for LSRs implementing
    the detour backup method. In these cases, the detour LSPs
    are reflected in the mplsFrrDetourTable."

I don't understand the above. Is this table mandatory when the
one-to-one backup method is used?  If so, shouldn't that be stated.

The definition from RFC 4090 states:

"PLR: Point of Local Repair.  The head-end LSR of a backup tunnel
or a detour LSP."

So the phrase "contains lists of PLRs" is confusing.

Also, the phrase "detour backup method" is confusing, are you
referring to the one-to-one backup method?

*) 4.4 mplsFrrDetourTable

Could this be renamed to mplsFrrOne2OneDetourTable?


Is this table mandatory when the one-to-one backup method is
used?  If so, could that be stated?

"This table is optional and is only required in case   
mplsFrrOne2OnePlrTable is supported."
If you state that the table is mandatory for the backup method,
then think the above statement is not necessary.



*) 4.5 mplsFrrFacRouteDBTable
The mplsFrrDBTable

s/mplsFrrDBTable/mplsFrrFacRouteDBTable

Could this be renamed to mplsFrrFacilty

Could you state that this table is mandatory when the
facility backup method is used?

*) 5. Handling IPv6 Tunnels


draft-ietf-ccamp-gmpls-addressing-03 does not appear
as a reference, please add to Normative References.


*) 6  (MIB MODULE)

*) LAST-UPDATED and REVISION is incorrect

*) DESCRIPTION:
...This MIB module is part of RFC 4327;
see the RFC itself for full legal notices.

needs to be changed to something like
             
                This version of this MIB module is part of RFC xxxx;
                See the RFC itself for full legal notices.

-- RFC EDITOR: please replace xxxx with actual number         
-- and remove this note.


*) Please change to yyy
::= { mplsStdMIB yyy } -- RFC-editor please fill in
                          -- yyy with value assigned by IANA,
                          -- see section 18.1 for details


*) Please change
mplsFrrNotif to mplsFrrNotifications

*) Doesn't seem necessary to have
    mplsFrrScalars      OBJECT IDENTIFIER ::= { mplsFrrMIB 1 }
    mplsFrrObjects      OBJECT IDENTIFIER ::= { mplsFrrMIB 2 }

Since Scalars are objects, right?
So maybe just use mplsFrrObjects
mplsFrrObjects      OBJECT IDENTIFIER ::= { mplsFrrMIB 1 }
mplsFrrConformance  OBJECT IDENTIFIER ::= { mplsFrrMIB 2 }

*) Also, please move mplsFrrConformance under mplsFrrObjects.


*) As stated above, I believe this MIB should be organized in
3 separate MIB Modules.  This would help to clarify what
actually needs to be supported when using One2One or
Facility.

The following scalars seem to be dependent on the
type of backup method:
mplsFrrDetourIncoming
mplsFrrDetourOutgoing
mplsFrrDetourOriginating
mplsFrrConfIfs
mplsFrrActProtectedIfs
mplsFrrConfProtectionTuns
mplsFrrActProtectionTuns
mplsFrrActProtectedLSPs
mplsFrrNotifsEnabled
mplsFrrNotifMaxRate

So why are these under General Objects?



*) mplsFrrDetourIncoming
Should be put with the oneToOne objects.
Should this be a Counter32 or Gauge32?
Please rename to mplsFrrIncomingDetourLSPs

*) mplsFrrDetourOutgoing
Should be put with the oneToOne objects.
Should this be a Counter32 or Gauge32?
please rename to mplsFrrOutgoingDetourLSPs


*) mplsFrrSwitchover
Should this be a Gauge32?

*) Could mplsFrrConfIfs be
renamed to:
mplsFrrConfiguredInterfaces
Also, this should apply only to
facilityBackup, so could be
a Gauge32 or Counter32?


*) mplsFrrActProtectedIfs
What does the Act stand for?
Is this Active or Actual?
Could this be renamed to
mplsFrrActiveInterfaces/mplsFrrActualInterfaces

*) mplsFrrConfProtectionsTuns
Could this be renamed
mplsFrrConfiguredBypassTunnels ?
Also, is this a Gauge32?


*) mplsFrrActProtectionTuns
Could this be renamed to
mplsFrrActiveBypassTunnels?
Also, is this a Gauge32?


*) mplsFrrActProtectedLSPs
could this be renamed to:
mplsFrrActiveProtectedLSPs?
Also, is this a Gauge32?

*) mplsFrrProtectionMethod Scalar
should probably be moved to being the first
scalar.  Also, I think an unknown(1) should be
added.  The reason is that if a device has been
rebooted, due to a change from one fast reroute
method to another, and if something were misconfigured,
then it might be that the fast reroute method would be
"unknown" until a correction was made.  Obviously,
"unknown" would be read-only and not settable.

Would suggest:
unknown(1),
onetooneBackup(2),
facilityBackup(3)


*) mplsFrrNotifsEnabled.
Why is this object needed?

*) mplsFrrNotifMaxRate
Are there other objects which indicate
if events are being thrown away due to this
throttling?  (Would that be useful?)

Last sentence
s/notified/generated/


*) mplsFrrConstTable
Please rename to mplsFrrConstraintsTable

*)    mplsFrrConstEntry OBJECT-TYPE
Please add a REFERENCE clause and add the
reference from the DESCRIPTION clause to the
REFERENCE clause.

s/speciifed/specified

"contains at a tunnel ingress."
Should be contains a tunnel ingress.


*) RFC 3209 Does not appear in the References.
  (This reference is mentioned several times)

*) mplsFrrConstIfIndex
please rename to mplsFrrConstIfIndexOrZero

*) mplsFrrConstTunnelInstance

s/identication/identification

*)    mplsFrrConstInclAnyAffinity OBJECT-TYPE
Please rename mplsFrrConstrainsIncludeAnyAffinity


*)    mplsFrrConstInclAllAffinity OBJECT-TYPE

Please rename to mplsFrrConstraintsIncludeAllAffinity


*) mplsFrrConstExcl objects
please rename to mplsFrrConstrainsExclude



*) mplsFrrConstBandwidth
s/reserved for detour/reserved for a detour


*) MplsFrrTunARHop
please use Tunnel
Also, other object names use Protection or Protected
so please use entire word here

*) mplsFrrOne2OnePlrTable

DESCRIPTION is a little bit awkward
"...that initiated the detour LSPs that traverse this node."
maybe the last "that" is not needed?

*) mplsFrrOne2OnePlrEntry
states:
          "...An entry in
          this table is only created by an SNMP agent as instructed
          by an MPLS signaling protocol."

But there are read-create objects, so want to make sure
that these read-create objects are allowed to be
changed after a row has been created?

Please spell out Tunnel, Ingress, Egress, Index and Instance in these
names.  This is to match the MPLS-TE-STD-MIB.


*) mplsFrrOne2OnePlrRunIngrLSRId

s/identity/identify

*) mplsFrrOne2OnePlrId
Please add a REFERENCE clause


*) mplsFrrOne2OnePlrAvoidNAddrType
mplsFrrOne2OnePlrAvoidNAddr

What does the N stand for?

*) Please add REFERENCE to mplsFrrOne2OnePlrAvoidNAddr

*) mplsFrrDetourTable

Please use Tunnel, Index, Instance

*) mplsFrrDetourActive
Please add to the DESCRIPTION what true(1) means.

*) mplsFrrDetourMerging
name suggestion: mplsFrrDetourMergedStatus

      SYNTAX        INTEGER { none(1),
                              protectedTunnel(2),
                              detour(3)
                            }

Could the above labels be
changed to:

notMerged(1),
mergedWithProtectedTunnel(2)
mergedWithDetour(3)

Also the description talks of setting this, but
it is a read-only.




*) mplsFrrFacRouteDBTable

Please expand Fac to Facility, Tun to Tunnel,
Idx to Index, Inst to Instance, Ingr to Ingress
and Egr to Egress.  Also, Prot is used but other
places in this MIB spell out Protection, or Protected.


Would also take out the word Route in these
object names, so mplsFrrFacRouteDBTable becomes
mplsFrrFacilityDBTable

*) mplsFrrFacRouteDBTable
DESCRIPTION
s/mplsFrrDBTable/mplsFrrFacRouteDBTable
(The above occurs in other objects of this
table, so please check the DESCRIPTIONs.)


            The protecting tunnel is indicated by the second two
            indexes (mplsTunnelIndex and mplsTunnelInstance) and
            represents a valid mplsTunnelEntry. Note that the tunnel

The above sentence is confusing.  Are you saying that
the second two indexes in this table have the same values
as mplsTunnelIndex and mplsTunnelInstance?

*) mplsFrrFacRouteProtIfIdx
s/applies/apply


*) mplsFrrFacRouteProtTunIdx
Please add a REFERENCE clause.  In general, if the
DESCRIPTION specifies a reference, then there should
probably be a REFERENCE clause.


*) Many of the DESCRIPTIONs state:
"...on the specified interface as specified in the
mplsFrrFacRouteIfProtIdx."
Could this be reworded as:
"...on the interface specified by mplsFrrFacRouteIfProtIdx."


*) mplsFrrFacDBNumProtTunOnIf
Please supply the specified interface's name.


*) mplsFrrRacRouteDBNumProtLspOnIf
Please supply the specified interface's name.


*) mplsFrrFacRouteDBProtTunStatus
Which protected tunnel is denoted here?

*) Same question for mplsFrrFacRouteDBProtTunResvBw

*) mplsFrrFacRouteDBProtTunResvBw
Please specify which object (or objects) from
the MPLS-TE-STD-MIB are being repeated.


*) mplsFrrFacProtected
The name doesn't say much about this notification.
Could we think of a more descriptive name, e.g.
(suggestion only) mplsFrrFacilityInitialBkupTunnelInvoked?

s/network loading/network load

DESCRIPTION is a little confusing.
Could you just say that the notification needs to
be sent prior to forwarding data ?

Last paragraph:
"Note this notification only applicable..."
change to:
Note this notification is only applicable



*) mplsFrrFacUnProtected
The name doesn't say much about this notification.
Could we think of a more descriptive name, e.g.
(suggestion only) mplsFrrFacilityFinalTunnelRestored?

s/network loading/network load


Last paragraph:
"Note this notification only applicable..."
change to:
Note this notification is only applicable


Conformance
--------------

*) Full conformance
DESCRIPTION of the one-to-one or facilty methods
state:

"...and is optional for those which do not."

Why is it optional?  Is it possible to support these
objects in any meaningful way? 

*) read-only Compliance

*) Comment is misplaced since it appears before
a scalar object
      -- mplsFrrConstTable

*)  Missing from Read-only conformance:
mplsFrrNotifsEnabled
mplsFrrNotifMaxRate

mplsFrrConstSetupPrio
mplsFrrconstHoldingPrio
mplsFrrConstInclAnyAffinity
mplsFrrConstInclAllAffinity
mplsFrrConstExclAnyAffinity
mplsFrrConstBandwidth

mplsFrrOne2OnePlrSenderAddrType
mplsFrrOne2OnePlrSenderAddr

*) 7. Security Considerations
        configuration and/or performanc statistics.
        Administrators not wishing to reveal this information should
        consider these objects sensitive/vulnerable and take
        precautions so they are not revealed.

s/performanc/performance

*) 9. Acknowledgments

Please begin this section with:
This document is a product of the MPLS Working Group.

*) REFERENCES are not in order of RFC number


*) 10.1 Normative References


    [RFC4090] Pan, P., Swallow, G., Atlas, A., "Fast Reroute
              Extensions to RSVP-TE for LSP Tunnels", RFC4090,
              May 2005.

and A. Atlas,

s/RFC4090/RFC 4090

*)    [RFC3813] Srinivasan, C., Viswanathan, A. and Nadeau, T.,
            "MPLS Label Switch Router Management Information Base ",
              RFC 3813, June 2004

and T. Nadeau,

"Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)
Management Information Base"


*)    [RFC3291]  Daniele, M., Haberman, B., Routhier, S., and J.
              Schoenwaelder, "TextualConventions for Internet Network
              Addresses", RFC 3291, May 2002.

s/TextualConventions/Textual Conventions

*) 10.2 Informative References

*) RFC3031 should probably be Normative, it is currently
listed as Informative
2006-10-05
21 Dan Romascanu State Change Notice email list have been change to mpls-chairs@tools.ietf.org; jcucchiara@mindspring.com from mpls-chairs@tools.ietf.org
2006-09-10
06 (System) New version available: draft-ietf-mpls-fastreroute-mib-06.txt
2006-07-24
21 Bill Fenner State Change Notice email list have been change to mpls-chairs@tools.ietf.org from <swallow@cisco.com>, <loa@pi.se>
2006-07-14
21 (System) State Changes to AD is watching from Dead by system
2006-07-13
05 (System) New version available: draft-ietf-mpls-fastreroute-mib-05.txt
2006-03-05
21 (System) State Changes to Dead from AD is watching by system
2006-03-05
21 (System) Document has expired
2005-08-27
21 Alex Zinin State Changes to AD is watching from Dead by Alex Zinin
2005-08-22
04 (System) New version available: draft-ietf-mpls-fastreroute-mib-04.txt
2005-08-19
03 (System) New version available: draft-ietf-mpls-fastreroute-mib-03.txt
2005-08-18
02 (System) New version available: draft-ietf-mpls-fastreroute-mib-02.txt
2005-05-26
21 (System) State Changes to Dead from AD is watching by IESG Secretary
2003-04-16
21 Alex Zinin Shepherding AD has been changed to Zinin, Alex from Bradner, Scott
2002-11-06
01 (System) New version available: draft-ietf-mpls-fastreroute-mib-01.txt
2002-10-05
21 Scott Bradner Draft Added by sob
2002-07-01
00 (System) New version available: draft-ietf-mpls-fastreroute-mib-00.txt