Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership
RFC 4972

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

(Ross Callon) Yes

(Jari Arkko) No Objection

(Brian Carpenter) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) No Objection

Comment (2007-01-10 for -)
No email
send info
I can't help but wonder whether automated establishment of RSVP-TE
LSPs will increase the management complexity of security association
and under RFC 4107 analysis require new mechanisms thta do not exist
today.  However this document has been carefully crafted to rule any
such consideration out of scope.  This is yet another document where
it feels like we're getting only part of the story necessary for real
engineering and interoperability.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Kessens) Abstain

Comment (2007-01-10 for -)
No email
send info
The working group summary says:

  There has been some discussion of the wisdom 
  of putting this information in an IGP (rather than BGP or somewhere
  else) within the routing directorate and a few other relevant folks
  (eg, chairs of IS-IS and/or OSPF WGs).

I wonder whether this was more of a majority decision where people with the minority view simply gave up facing a very heavy train approaching at high speed or whether real rough consensus was reached. 

I for one have serious doubts about the wisdom of 
this approach myself and cannot support this document.