Multiprotocol Extensions for BGP-4
RFC 4760

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

(Ross Callon) Yes

Comment (2006-05-11)
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

Comment (2006-05-11)

(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

Comment (2005-12-01)
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).


   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.

   identify individual Network Layer protocols associated with the
   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 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

Comment (2006-05-10)
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.