Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
10 (System) post-migration administrative database adjustment to the Yes position for Bill Fenner
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Magnus Westerlund
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for David Kessens
2006-11-03
10 (System) IANA Action state changed to Waiting on RFC Editor from RFC-Ed-Ack
2006-11-02
10 (System) IANA Action state changed to RFC-Ed-Ack from In Progress
2006-11-02
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2006-11-02
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2006-11-02
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2006-11-02
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2006-11-02
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2006-11-01
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2006-11-01
10 (System) IANA Action state changed to In Progress from Waiting on WGC
2006-10-31
10 (System) IANA Action state changed to Waiting on WGC from In Progress
2006-10-31
10 (System) IANA Action state changed to In Progress from Waiting on WGC
2006-10-26
10 (System) IANA Action state changed to Waiting on WGC from Waiting on ADs
2006-10-16
10 (System) IANA Action state changed to Waiting on ADs from In Progress
2006-09-29
10 (System) IANA Action state changed to In Progress
2006-07-24
10 Bill Fenner State Change Notice email list have been change to idr-chairs@tools.ietf.org from yakov@juniper.net, skh@nexthop.com
2006-06-19
10 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-06-12
10 Amy Vezza IESG state changed to Approved-announcement sent
2006-06-12
10 Amy Vezza IESG has approved the document
2006-06-12
10 Amy Vezza Closed "Approve" ballot
2006-05-12
10 (System) Removed from agenda for telechat - 2006-05-11
2006-05-11
10 Bill Fenner State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Bill Fenner
2006-05-11
10 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza
2006-05-11
10 (System) [Ballot Position Update] Position for David Kessens has been changed to no from discuss by IESG Secretary
2006-05-11
10 Ross Callon
[Ballot comment]
Regarding the comment:
    The specification includes support for "Subnetwork Points of Attachment"
    (SNPA).  Implementation report seems to indicate that …
[Ballot comment]
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.
2006-05-11
10 Ross Callon
[Ballot comment]
Regarding the comment:
The specification includes support for
"Subnetwork Points of Attachment" (SNPA).  Implementation report seems
to indicate that no one has implemented …
[Ballot comment]
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, it
certainly hasn't been interop-tested.  RFC2026 doesn't allow advancing
to Draft Standard unless this is implemented and tested or removed.
I'd suggest considering removing the unused feature.
2006-05-11
10 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon by Ross Callon
2006-05-11
10 Jari Arkko [Ballot comment]
s/Obsoles/Obsoletes/
2006-05-11
10 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-05-11
10 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert
2006-05-10
10 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to Yes from No Objection by Bill Fenner
2006-05-10
10 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund
2006-05-10
10 Mark Townsley
[Ballot comment]
One of the principal uses of these extensions today are for enabling RFC4364 L3VPNs, though the abstract indicates that the extensions exist for …
[Ballot comment]
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"."
2006-05-10
10 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu
2006-05-09
10 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings
2006-05-09
10 Magnus Westerlund
[Ballot discuss]
Section 8:

Res. - Reserved (8 bit) field. SHOULD be set to 0 by the sender
        and ignored by …
[Ballot discuss]
Section 8:

Res. - Reserved (8 bit) field. SHOULD be set to 0 by the sender
        and ignored by the receiver.

Only specifying a reserved field as SHOULD be set to 0 creates interoperability issues if one was to ever try to use the field for anything in the future.

So why is this not MUST set it to 0? Please motivate when it could be set to other than 0.
2006-05-09
10 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-05-08
10 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-05-04
10 Bill Fenner
Responses to Pekka's review:

1. While the BGP ID is 4 octets, it's not carried by BGP, it's an aspect of a given connection.  This …
Responses to Pekka's review:

1. While the BGP ID is 4 octets, it's not carried by BGP, it's an aspect of a given connection.  This document is talking about data that is carried across the network by BGP.

2. SNPAs have been removed in the update.

3. It's inappropriate to write down the values in this document.  We were planning on communicating the values to the IANA at the same time as this document is approved.  Of course any list is going to be out of date if the IANA considerations for this field don't get updated.

I believe all of the items in the "comment"s are addressed by the RFC Editor note.
2006-05-04
10 Bill Fenner State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Bill Fenner
2006-05-04
10 Bill Fenner Placed on agenda for telechat - 2006-05-11 by Bill Fenner
2006-03-24
10 (System) New version available: draft-ietf-idr-rfc2858bis-10.txt
2006-03-06
09 (System) New version available: draft-ietf-idr-rfc2858bis-09.txt
2006-01-27
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-01-27
08 (System) New version available: draft-ietf-idr-rfc2858bis-08.txt
2006-01-23
10 Bill Fenner
Just a note, Ravi is out of office until, Monday, February 6th, 2006; the updated authors addresses are
To: tbates@cisco.com,rchandra@sonoasystems.com,dkatz@juniper.net, …
Just a note, Ravi is out of office until, Monday, February 6th, 2006; the updated authors addresses are
To: tbates@cisco.com,rchandra@sonoasystems.com,dkatz@juniper.net,yakov@juniper.net
2006-01-23
10 Bill Fenner State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Bill Fenner
2006-01-23
10 Bill Fenner
To: tbates@cisco.com,rchandra@redback.com,dkatz@juniper.com,yakov@juniper.com
Subject: RFC2858bis: IESG evaluation
Cc: skh@nexthop.com
Fcc: +iesg

The full evaluation is at

https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1228&filename=draft-ietf-idr-rfc2858bis 
 
Please review it, it's not very long.

The biggest issue raised is that the implementation report doesn't
explicitly talk about implementation of SNPA; my reading from
section 3 is that Cisco and NextHop do implement them but it's
not explicitly mentioned.  Technically if we don't have multiple
implementations of a given option it has to be removed in order
to move to Draft.  I don't know if a revised implementation report
is feasible or (assuming my assumption is right) we should just try
to push back on the discussion of SNPA.
 
The list to give IANA to answer Pekka's point about the used
values is the list that Bill, Yakov, Pedro and Jeff came up with
during WG Last Call, so while I forgot to put it in the Last
Call message like I said, I don't think this is an issue.

My suggestions on the remaining issues:
- The abstract says "Currently BGP-4 is capable of ..." - perhaps
  just delete this sentence to update it.  Add a sentence at the
  end saying that it updates RFC 2858.

- Update the RFC 1700 reference

- Update [BGP-CAP] and [BGP-4] references

- Decide if it's worth doing anything about the BGP ID (it's clear
  to me that the list in the document is the fields that are sent
  around in routes, and BGP ID is local to the session) - maybe
  mention that it's currently an IPv4 address and there is work
  in progress (with an info ref to idr-bgp-identifier) to change
  that.

  Bill
2006-01-23
10 Bill Fenner State Change Notice email list have been change to yakov@juniper.net, skh@nexthop.com from
2006-01-23
10 Bill Fenner
IANA issues tracked under
Subject: RE: [I06-051004-0007]Re: Evaluation: draft-ietf-idr-rfc2858bis-07.txt to Draft Standard
The plan is that we share the list with IANA seperately since it …
IANA issues tracked under
Subject: RE: [I06-051004-0007]Re: Evaluation: draft-ietf-idr-rfc2858bis-07.txt to Draft Standard
The plan is that we share the list with IANA seperately since it didn't seem appropriate to put the list in the document.
2006-01-23
10 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner
2005-12-01
10 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2005-12-01
10 Michelle Cotton
IANA Comments:
Upon approval of this document the IANA will make some small updates to the SAFI Namespace registry according to this document.
The registry …
IANA Comments:
Upon approval of this document the IANA will make some small updates to the SAFI Namespace registry according to this document.
The registry can be found at the following:
http://www.iana.org/assignments/safi-namespace
2005-12-01
10 Bill Fenner Removing from telechat agenda; all the positions are in and we don't need to discuss the DISCUSSes on the call.
2005-12-01
10 Alex Zinin [Ballot Position Update] New position, Yes, has been recorded for Alex Zinin by Alex Zinin
2005-12-01
10 Bill Fenner [Ballot discuss]
Holding for IANA to evaluate - expect evaluation today.
2005-12-01
10 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to Discuss from Yes by Bill Fenner
2005-12-01
10 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-12-01
10 Bert Wijnen
[Ballot comment]
The first comment below better gets addressed.
The 2nd comment (I think) is known, and it is OK that way.

From MIB Doctor …
[Ballot comment]
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.
2005-12-01
10 David Kessens
[Ballot discuss]
I received the following comments from the Ops directorate by Pekka Savola that need to be addressed/discussed in one way or another:

The …
[Ballot discuss]
I received the following comments from the Ops directorate by Pekka Savola that need to be addressed/discussed in one way or another:

The drafts says in '2. Overview':

  The only three pieces of information carried by BGP-4 [BGP-4] that
  are IPv4 specific are (a) the NEXT_HOP attribute (expressed as an
  IPv4 address), (b) AGGREGATOR (contains an IPv4 address), and (c)
  NLRI (expressed as IPv4 address prefixes).

The BGP specification includes 'BGP identifier' which is a 4-octet field.
Currently, it is set to an IPv4 address. (see also: draft-ietf-idr-bgp-identifier-06.txt).

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, it
certainly hasn't been interop-tested.  RFC2026 doesn't allow advancing
to Draft Standard unless this is implemented and tested or removed.
I'd suggest considering removing the unused feature.

The draft says in 'IANA Considerations'

  - SAFI values 128 through 240 are part of the previous "private
    use" range. Of this space, allocations which are currently in use
    are to be recognized by IANA. Unused values, namely 130, 131, 135
    through 139, and 141 through 240 should be considered reserved, in
    order to avoid conflicts.

IANA does not know about what those 'currently in use' allocations
are, as they are not recorded, and hence does not know how they should
be recognized.  This document should probably list the number,
describe what it's used for and provide a reference.  By the way -- is
the list above even up to date anymore?  A vendor could have started
using other values since the above was writen.
2005-12-01
10 David Kessens
[Ballot comment]
Comments received from the Ops directorate by Pekka Savola:

Obsoles RFC2858                    Yakov Rekhter …
[Ballot comment]
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.
2005-12-01
10 David Kessens
[Ballot discuss]
I received the following comments fromt he Ops directorate by Pekka Savola that need to be addressed/discussed in one way or another:

High …
[Ballot discuss]
I received the following comments fromt he Ops directorate by Pekka Savola that need to be addressed/discussed in one way or another:

High level comment: the document (and BGP4 spec) assumes that every
router must have at least one IPv4 address (for 'BGP identifier'
field).  While this is not an issue right now it might be something
worth looking at sometime within the next 5 years.

A substantial 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, it
certainly hasn't been interop-tested.  RFC2026 doesn't allow advancing
to Draft Standard unless this is implemented and tested or removed.
I'd suggest considering removing the unused feature.
2005-12-01
10 David Kessens [Ballot Position Update] New position, Discuss, has been recorded for David Kessens by David Kessens
2005-11-30
10 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-11-30
10 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-11-30
10 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-11-29
10 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2005-11-28
10 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2005-11-28
10 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-11-25
10 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2005-11-23
10 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-11-22
10 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-11-02
10 Bill Fenner State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Bill Fenner
2005-11-02
10 Bill Fenner Placed on agenda for telechat - 2005-12-01 by Bill Fenner
2005-11-02
10 Bill Fenner [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner
2005-11-02
10 Bill Fenner Ballot has been issued by Bill Fenner
2005-11-02
10 Bill Fenner Created "Approve" ballot
2005-11-02
10 Bill Fenner Note: IETF Last Call comment regarding the term "semi-octet"
2005-10-07
10 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2005-09-23
10 Amy Vezza Last call sent
2005-09-23
10 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-09-22
10 Bill Fenner Last Call was requested by Bill Fenner
2005-09-22
10 Bill Fenner State Changes to Last Call Requested from AD Evaluation by Bill Fenner
2005-09-22
10 (System) Ballot writeup text was added
2005-09-22
10 (System) Last call text was added
2005-09-22
10 (System) Ballot approval text was added
2005-08-30
10 Bill Fenner State Changes to AD Evaluation from Publication Requested by Bill Fenner
2005-08-23
10 Bill Fenner
Minor updates required:
- RFC 1700 references need to change (to do: check with IANA as to whether to refer to registry directly)
- rfc2842 …
Minor updates required:
- RFC 1700 references need to change (to do: check with IANA as to whether to refer to registry directly)
- rfc2842 reference needs to change to 3392
These could be done with an RFC-Editor's note.

Implementation report now posted at http://www.ietf.org/IESG/Implementations/mp-bgp-implementation-report.txt
2005-08-23
07 (System) New version available: draft-ietf-idr-rfc2858bis-07.txt
2005-08-20
10 Bill Fenner The implementation report is in draft-hares-idr-rfc2858bis-survey-00.txt.
2005-03-24
10 Bill Fenner Note field has been cleared by Bill Fenner
2005-03-24
10 Bill Fenner Shepherding AD has been changed to Bill Fenner from Alex Zinin
2004-08-31
10 Alex Zinin [Note]: 'This will have wait until the IESG approval of the base BGP spec' added by Alex Zinin
2004-07-23
10 Dinara Suleymanova State Changes to Publication Requested from AD is watching by Dinara Suleymanova
2004-07-23
10 Dinara Suleymanova Intended Status has been changed to Draft Standard from None
2004-05-25
06 (System) New version available: draft-ietf-idr-rfc2858bis-06.txt
2004-03-31
05 (System) New version available: draft-ietf-idr-rfc2858bis-05.txt
2004-03-16
04 (System) New version available: draft-ietf-idr-rfc2858bis-04.txt
2004-01-21
10 Alex Zinin Draft Added by Alex Zinin
2003-07-25
03 (System) New version available: draft-ietf-idr-rfc2858bis-03.txt
2002-04-26
02 (System) New version available: draft-ietf-idr-rfc2858bis-02.txt
2002-03-25
01 (System) New version available: draft-ietf-idr-rfc2858bis-01.txt
2002-01-08
00 (System) New version available: draft-ietf-idr-rfc2858bis-00.txt