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

[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.

[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.

[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"."

[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.

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.

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

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

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.

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

[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.

[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.

[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.

[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.

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