Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs
Note: This ballot was opened for revision 07 and is now closed.
(Lars Eggert) (was No Objection) Yes
Magnus Westerlund Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Ralph Droms) No Objection
(Lisa Dusseault) No Objection
(Pasi Eronen) No Objection
(Adrian Farrel) (was Discuss) No Objection
Thanks very much for addressing so much of my Discuss and Comment. We made very substantial progress and improved the document significantly. I have cleared my Discuss and relegated my issue to a Comment. My remaining issue is mainly philosophy, and I will probably continue to disagree on this point regardless of further discussions. At least it is now clear to me what the purpose and objectives are. IMHO, there is no need for this feature. My view is that it is possible to identify the state and RSVP addressing context from the existing RSVP message, the incoming interface, and the IP header. IMHO, no further additions are necessary. But I see that the proposed extension is not mandatory so people can continue to deploy RSVP over MPLS L3VPN without using it. That is good enough for me.
(Russ Housley) No Objection
Alexey Melnikov No Objection
Comment (2009-11-18 for -** No value found for 'p.get_dochistory.rev' **)
3.6. Other RSVP Messages Comment: not using RFC 2119 keywords? The same comment probably applies to other sections, but this is where I've noticed.