Skip to main content

Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)
draft-ietf-ccamp-gmpls-recovery-terminology-06

Yes

(Alex Zinin)

No Objection

(Allison Mankin)
(Bill Fenner)
(David Kessens)
(Harald Alvestrand)
(Jon Peterson)
(Margaret Cullen)
(Thomas Narten)

Note: This ballot was opened for revision 06 and is now closed.

Alex Zinin Former IESG member
Yes
Yes () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection (2005-01-05) Unknown
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.
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2005-01-04) Unknown
  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.
Sam Hartman Former IESG member
(was Discuss) No Objection
No Objection (2005-01-06) Unknown
Discuss cleared because Alex points out that these messages will be
carried in existing protocols.
Scott Hollenbeck Former IESG member
No Objection
No Objection (2004-12-22) Unknown
All three documents are missing an IANA Considerations section.
Ted Hardie Former IESG member
No Objection
No Objection (2005-01-04) Unknown
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?
Thomas Narten Former IESG member
No Objection
No Objection () Unknown