Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute
RFC 6445
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2017-05-16
|
21 | (System) | Changed document authors from "Riza Cetin, Thomas Nadeau" to "Riza Cetin, Thomas Nadeau, Kiran Koushik" |
|
2015-10-14
|
21 | (System) | Notify list changed from mpls-chairs@ietf.org, to (None) |
|
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-11-16
|
21 | Amy Vezza | State changed to RFC Published from RFC Ed Queue. |
|
2011-11-16
|
21 | (System) | RFC published |
|
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 <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <mpls@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-mpls-fastreroute-mib-15.txt> (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' <draft-ietf-mpls-fastreroute-mib-15.txt> 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 |