Multiprotocol Extensions for BGP-4
RFC 4760
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Lars Eggert No Objection
(Alex Zinin; former steering group member) Yes
(Bill Fenner; former steering group member) (was No Objection, Discuss, Yes) Yes
(Ross Callon; former steering group member) Yes
Regarding the comment:
The specification includes support for "Subnetwork Points of Attachment"
(SNPA). Implementation report seems to indicate that no one has
implemented this support, and if so, ...
This has been removed from the most recent version of the spec.
(Allison Mankin; former steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
The first comment below better gets addressed. The 2nd comment (I think) is known, and it is OK that way. From MIB Doctor Mike Heard: > o draft-ietf-idr-rfc2858bis-07.txt > Multiprotocol Extensions for BGP-4 (Draft Standard) - 4 of 22 > Token: Bill Fenner The doc has exactly the same abstract as 2858, except for the last sentence of the latter. Seems to me that the abstract needs to be updated, since the spec has been around a while and routers do now support this stuff (as evidenced by sufficient implementations to go to Draft). Also the abstract does not say it obsoletes RFC 2858, which it should do. Note that the current BGP-4 MIB (draft-ietf-idr-bgp4-mib-15.txt, now in RFC Ed queue to replace RFCs 1269 and 1657) does not support this extension, but the new version (draft-ietf-idr-bgp4-mibv2-05.txt, still under construction) will.
(Brian Carpenter; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) (was Discuss) No Objection
Comments received from the Ops directorate by Pekka Savola: Obsoles RFC2858 Yakov Rekhter (Juniper Networks) ==> the fact that this doc obsoletes 2858 should probably be mentioned in the body as well (typically both in Abstract and Introduction, but either one is fine with me at least). Abstract Currently BGP-4 is capable of carrying routing information only for IPv4. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. ==> the first sentence is no longer true. Remove (its information value isn't that high in the first place) or reword. To identify individual Network Layer protocols associated with the next hop information and semantics of NLRI this document uses a combination of Address Family, as defined in [RFC1700], and Subsequent Address Family (as described in this document). ==> RFC1700 has been obsoleted, so maybe you should just point to http://www.iana.org/assignments/address-family-numbers instead (similar references later in the document). 16. Normative References [BGP-CAP] "Capabilities Advertisement with BGP-4", R. Chandra, J. Scudder, RFC2842, May 2000 ==> this is PS and would be a downref; luckily enough, RFC3392 which is DS obsoletes 2842, so just replace the ref with 3392. [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. ==> you should probably refer to the new bgp-4 spec instead.
(Jari Arkko; former steering group member) No Objection
s/Obsoles/Obsoletes/
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
(Margaret Cullen; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
One of the principal uses of these extensions today are for enabling RFC4364 L3VPNs, though the abstract indicates that the extensions exist for enabling "IPv6, IPX, etc..." Perhaps this should be updated accordingly. Any chance either of the MAY/SHOULDs quoted below can be made MUSTs based on known implementation? "In addition, the speaker MAY terminate the BGP session over which the Update message was received. The session SHOULD be terminated with the Notification message code/subcode indicating "Update Message Error"/"Optional Attribute Error"."
(Russ Housley; former steering group member) No Objection
(Sam Hartman; former steering group member) No Objection
(Scott Hollenbeck; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection