Skip to main content

Multiprotocol Extensions for BGP-4
RFC 4760

Yes

(Alex Zinin)
(Bill Fenner)

No Objection

Lars Eggert
(Allison Mankin)
(Brian Carpenter)
(Cullen Jennings)
(Dan Romascanu)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Margaret Cullen)
(Russ Housley)
(Sam Hartman)
(Scott Hollenbeck)
(Ted Hardie)

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

Lars Eggert No Objection

(Alex Zinin; former steering group member) Yes

Yes ()

                            

(Bill Fenner; former steering group member) (was No Objection, Discuss, Yes) Yes

Yes ()

                            

(Ross Callon; former steering group member) Yes

Yes (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.

(Allison Mankin; former steering group member) No Objection

No Objection ()

                            

(Bert Wijnen; former steering group member) No Objection

No Objection (2005-12-01)
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

No Objection ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) (was Discuss) No Objection

No Objection (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).

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

No Objection (2006-05-11)
s/Obsoles/Obsoletes/

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection (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"."

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) No Objection

No Objection ()

                            

(Scott Hollenbeck; former steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection ()