Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)
RFC 4427
Note: This ballot was opened for revision 06 and is now closed.
(Alex Zinin) Yes
(Harald Alvestrand) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
Comment (2005-01-04 for -)
No email
send info
send info
In draft-ietf-ccamp-gmpls-recovery-analysis-04.txt, Section 7, the draft says: Hierarchies are used to build scalable complex systems. Abstraction is used as a mechanism to build large networks or as a technique for enforcing technology, topological or administrative boundaries. The same hierarchical concept can be applied to control the network survivability. In general, it is expected that the recovery action is taken by the recoverable LSP/span closest to the failure in order to avoid the multiplication of recovery actions. Moreover, recovery hierarchies can be also bound to control plane logical partitions (e.g. administrative or topological boundaries). Each of them may apply different recovery mechanisms. How does abstraction accomplish enforcement of boundaries? What does network survivability mean here? In brief, the commonly accepted ideas are generally that the lower layers can provide coarse but faster recovery while the higher layers can provide finer but slower recovery. Moreover, it is also desirable to avoid similar layers with functional overlaps to optimize network resource utilization and processing overhead. In this context, this section intends to analyze these hierarchical aspects including the physical (passive) layer(s). What does "it is also desirable to avoid similar layers with functional overlaps to optimize network resource utilization and processsing overhead" mean?
(Sam Hartman) (was Discuss) No Objection
Comment (2005-01-06)
No email
send info
send info
Discuss cleared because Alex points out that these messages will be carried in existing protocols.
(Scott Hollenbeck) No Objection
Comment (2004-12-22 for -)
No email
send info
send info
All three documents are missing an IANA Considerations section.
(Russ Housley) (was Discuss) No Objection
Comment (2005-01-04)
No email
send info
send info
draft-ietf-ccamp-gmpls-recovery-terminology, overall: I am struggling with the definition of "protection" and "recovery." Normal English usage is clearly not the intent. I do not know anything about the G-series of ITU Recommendations, and I do not plan to study them for this ballot. So, maybe I am not part of the intended audience of this document. Yet, I think all readers would be served by a little bit of overview at the very beginning of this document. draft-ietf-ccamp-gmpls-recovery-terminology, Section 2, 1st paragraph: Please drop the tail of the last sentence. (" that are under consideration by the CCAMP Working Group" is not needed or useful at this stage.) draft-ietf-ccamp-gmpls-recovery-terminology, Section 4.13: Please spell out NMS/EMS. draft-ietf-ccamp-gmpls-recovery-terminology, references: The question marks in [G.806] and [G.808.1] need to be cleaned up.
(David Kessens) No Objection
(Allison Mankin) No Objection
(Thomas Narten) No Objection
(Jon Peterson) No Objection
(Bert Wijnen) No Objection
Comment (2005-01-05 for -)
No email
send info
send info
In draft-ietf-ccamp-gmpls-recovery-analysis-04.txt (Informational RFC) I am surpsied to (all of a sudden) see (SNMP show up in the Security Considerations Section. The statement is not incorrect, but the reference to (SNMP) in paranthesis seems weird given the content of the document.