Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
RFC 4202

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

(Alex Zinin; former steering group member) Yes

Yes ( for -)
No email
send info

(Bert Wijnen; former steering group member) Yes

Yes ( for -)
No email
send info

(Bill Fenner; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Margaret Cullen; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ned Freed; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2003-10-14)
No email
send info
COMMENT on draft-ietf-ccamp-gmpls-routing-08:
  
  The Abstract is very weak.  I propose:

       This document specifies routing extensions in support of carrying
       link state information for Generalized Multi-Protocol Label Switching
       (GMPLS).  This document enhances the routing extensions required to 
       support MPLS Traffic Engineering (TE).

  Move the single paragraph in section 1 to the top of section 2.  This
  will turn section 2 into a very good introduction.

  Spell out first use of SPF.

COMMENT on draft-ietf-ccamp-ospf-gmpls-extensions-11:

  Move the single paragraph in section 1 to the top of section 2.  This
  will turn section 2 into a very good introduction.

(Steven Bellovin; former steering group member) No Objection

No Objection (2003-10-14 for -)
No email
send info
Why is draft-ietf-ccamp-gmpls-routing Proposed instead of Informational?
(It's clear why the other document in the ballot is Proposed.)

(Thomas Narten; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Randy Bush; former steering group member) Abstain

Abstain ( for -)
No email
send info

(Ted Hardie; former steering group member) Abstain

Abstain (2003-10-14 for -)
No email
send info
Reading through gmpls-routing-08, I kept feeling like something was missing--essentially the
description of how the routing decisions get made in the presence of the new data
about Shared Risk Link Groups, protection information, and interface switching.  About
the only I thing that seemed to relate to that was the "if you're looking for diverse paths,
choose links with different SRLGs" statement.  I then decided it was probably in the OSPF doc, 
but it doesn't seem to be in OSPF-gmpls-extensions either.  Is there some other doc that talks
about how implementors should consider the interactions among these pieces of data?  
For example, what should you do when one link is listed as protected, but in the same SRLG,
where another link is a different SRLG but unprotected?  Is deterministic behavior on this not
something which is important?