Skip to main content

Multiprotocol Extensions for BGP-4
draft-ietf-idr-rfc2858bis-10

Yes

(Alex Zinin)
(Bill Fenner)

No Objection

(Allison Mankin)
(Brian Carpenter)
(Cullen Jennings)
(Dan Romascanu)
(Jon Peterson)
(Lars Eggert)
(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.

Alex Zinin Former IESG member
Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
(was No Objection, Discuss, Yes) Yes
Yes () Unknown

                            
Ross Callon Former IESG member
Yes
Yes (2006-05-11) Unknown
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 IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection (2005-12-01) Unknown
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 IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
(was Discuss) No Objection
No Objection (2005-12-01) Unknown
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 IESG member
No Objection
No Objection (2006-05-11) Unknown
s/Obsoles/Obsoletes/
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection (2006-05-10) Unknown
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 IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection () Unknown