Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs
RFC 6016
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert (was No Objection) Yes
(Magnus Westerlund; former steering group member) Yes
(Adrian Farrel; former steering group member) (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.
(Alexey Melnikov; former steering group member) No Objection
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.
(Dan Romascanu; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection