Multiprotocol Extensions for BGP-4
Note: This ballot was opened for revision 10 and is now closed.
(Ross Callon) 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.
(Bill Fenner) (was No Objection, Discuss, Yes) Yes
(Alex Zinin) Yes
(Jari Arkko) No Objection
(Brian Carpenter) No Objection
(Margaret Cullen) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
(Ted Hardie) No Objection
(Sam Hartman) No Objection
(Scott Hollenbeck) No Objection
(Russ Housley) No Objection
(Cullen Jennings) No Objection
(David Kessens) (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.
(Allison Mankin) No Objection
(Jon Peterson) No Objection
(Dan Romascanu) No Objection
(Mark Townsley) 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"."
Magnus Westerlund (was Discuss) No Objection
(Bert Wijnen) No Objection
Comment (2005-12-01 for -)
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.