Enhanced Route Refresh Capability for BGP-4
draft-ietf-idr-bgp-enhanced-route-refresh-10

[Ballot comment]
Thanks for addressing my previous discuss to add in a reference to the
appropriate Security Considerations section of an existing RFC that covers the
list of known security considerations and addressing previous comments.

Changes to the Security Considerations are in version 10.
IANA Note has been added to address IANA concerns.

Waiting for check on DISCUSS being sufficiently addressed.

[Ballot comment]
The risk noted in Stephen's DISCUSS is worth considering.  I suspect the answer lies in how a BGP speaker handles a dropped session.  Everything is fine if either it discards any incomplete refresh or it discards all BGP state associated with the session.  In the former case, this document would need to specify the behavior; in the latter, assuming the behavior is documented elsewhere, a citation and note would be helpful.

[Ballot discuss]


I have a quick question to discuss, and will clear if you
tell me I've read the draft wrong, or that this isn't new or
that this is just too boring to even think about:-)

Is the following not a new security consideration even with
authenticated BGP? If an attacker can see the BoRR go by,
and can then force the TCP connection down before the EoRR
is seen (and stop new TCP connections coming up for as long
as the purge timer), the receiver marking the routes as
stale with a timeout before purging could cause the receiver
to purge all the sender's routes.  I guess receivers could
maybe detect this (because they're no longer hearing from
the sending peer and have only marked the routes as stale
because of the BoRR) and not purge the routes in that
specific case, but I'm not sure if it'd be worth noting
that. Or perhaps this is not a new threat?

[Ballot comment]

- section 4: I don't get why you need to say that stuff "MAY
be logged" - is that really needed? Are there real
conventions for what to not log with BGP? If so, I could
understand these statements, but absent such, I don't see
you need 'em. Equally, there's no problem saying that, it
just jumped out as an odd thing to say.

[Ballot discuss]
This should be very easy to resolve, could you add in a reference to the appropriate Security Considerations section of an existing RFC that covers the list of known security considerations?  It would be good to know exactly where to look as opposed to just saying no more are added.

[Ballot comment]
I have a couple of tiny nits that should be pretty easy to address.

This would read easier if the acronyms were handled a little differently, could this be changed from:
          0 - Normal route refresh request [RFC2918]
                  with/without ORF [RFC5291]
          1 - Demarcation of the beginning of a route refresh operation.
              Also known as a "BoRR message" or just a "BoRR".
          2 - Demarcation of the ending of a route refresh operation.
              Also known as a "EoRR message" or just a "EoRR".
To:
          0 - Normal route refresh request [RFC2918]
                  with/without ORF [RFC5291]
          1 - Demarcation of the beginning of a route refresh (BoRR) operation.
              Also known as a "BoRR message" or just a "BoRR".
          2 - Demarcation of the ending of a route refresh operation (EoRR).
              Also known as a "EoRR message" or just a "EoRR".

Maybe it's just me, but I had to read it twice without that, if you change this, you could drop the "or just a "BoRR"" and "or just a "EoRR"" clauses.

Section 4,
Could you expand on ? 

Looks like it is in Section 3 of RFC5291, I had to look them up and I am sure from how it is described that they are really well-known acronyms.

[Ballot discuss]
Just to be clear: it is your intention that this document updates 2918
such that the function defined here is part of the core BGP-4
specification, and new implementations of BGP-4 are expected to
include support for this function as standard.

If this is your intention I would like you to note this fact in the
Introduction to clarify the "Updates" tag.

If this is not your intention, I think you will need to remove the
"Updates" tag.

In either case, once this and my other issues are resolved, I will be
happy to move to a "Yes" ballot.

---

In Section 3.1 you have

  The "Enhanced Route Refresh Capability" is a new BGP capability
  [RFC5492].  IANA has assigned a Capability Code of 70 for this
  capability.

In section 6 you have

  This document defines the Enhanced Route Refresh Capability for BGP.
  The Capability Code 70 has been assigned by the IANA.

I think that Section 6 needs to give IANA an explicit instruction to
update the registry (which registry?) to point to this document when it
is published as an RFC.

---

In Section 6 you mark the range 3-255 as Reserved. I think you need to
reflect in the table the same information that you have in the text.
Thus...

  Value  Code                Reference
  0      Route-Refresh      [RFC2918], [RFC5291]
  1      BoRR                [draft-ietf-idr-bgp-enhanced-refresh-06.txt]
  2      EoRR                [draft-ietf-idr-bgp-enhanced-refresh-06.txt]
  3-127  Unassigned
  128-254 Unassigned
  255    Reserved            [draft-ietf-idr-bgp-enhanced-refresh-06.txt]

Similarly

  Value  Code                    Reference
  0      Reserved
  1      Invalid Message Length  [draft-ietf-idr-bgp-enhanced-refresh-06.txt]
  2-127  Unassigned
  128-255 Unassigned

[Ballot comment]
I just have a couple of minor, non-blocking comments that I'd like you to please consider:

-- Section 1 --

  It is sometimes necessary to perform routing consistency validations
  such as checking for possible missing withdraws between BGP speakers

"Withdraw" is not a noun; the noun should be either "withdrawal" or "withdrawn route".  Both are consistent with usage in RFC 4271.

-- Section 4 --

  A BGP speaker that supports the message subtypes for the ROUTE-
  REFRESH message and the related procedures SHOULD advertise the
  "Enhanced Route Refresh Capability".

Why "SHOULD"?  Under what conditions might such a BGP speaker not advertise it?  I think what you really mean here doesn't need 2119 key words at all: change "SHOULD advertise" to "advertises".

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-bgp-enhanced-route-refresh-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are four actions which IANA must complete.

First, in the Capability Codes registry in Border Gateway Protocol (BGP) Parameters at

http://www.iana.org/assignments/capability-codes/

code 70 has been assigned temporarily to [draft-ietf-idr-bgp-enhanced-refresh]. This registration will be made permanent and the reference changed to [ RFC-to-be ].

Second, a new registry will be created under Border Gateway Protocol (BGP) Parameters at

http://www.iana.org/assignments/capability-codes/

Registry: "BGP Route Refresh Subcodes"
Reference: [ RFC-to-be ]
Registration Procedure(s): Values 0-127 Standards Action, values
128-254 First Come, First Served, Value 255 reserved

Value Code Reference
0 Route-Refresh [RFC2918], [RFC5291]
1 BoRR [ RFC-to-be ]
2 EoRR [ RFC-to-be ]
255 Reserved

Third, in the BGP Error Codes registry at

http://www.iana.org/assignments/bgp-parameters/

a new error code is to be registered as follows:

Value: [ TBD-at-registration ]
Name: NOTIFICATION
Reference: [ RFC-to-be ]

Fourth, in the BGP Error Subcodes registry group also in the Border Gateway Protocol (BGP) Parameters registry at

http://www.iana.org/assignments/bgp-parameters/

a new BGP Error Subcodes sub-registry is to be created as follows:

Registry: "BGP ROUTE-REFRESH Message Error subcodes"
Reference: [ RFC-to-be ]
Registration Procedure(s): Values 0-127 Standards Action, values
128-255 First Come, First Served

Value Code Reference
0 Reserved
1 Invalid Message Length [ RFC-to-be ]

IANA understands that these four actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Enhanced Route Refresh Capability for BGP-4) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Enhanced Route Refresh Capability for BGP-4'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-06-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  In this document we enhance the existing BGP route refresh mechanisms
  to provide for the demarcation of the beginning and the ending of a
  route refresh.  The enhancement can be used to facilitate correction
  of BGP RIB inconsistencies in a non-disruptive manner.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh/ballot/


No IPR declarations have been submitted directly on this I-D.

RFC 4858 template:

Revision 2: 3/20/14
Note: Submitted to AD while early reviews come in:

Document shepherd: Susan Hares
Responsible AD: Alia Atlas


(1) RFC type: Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  In this document we enhance the existing BGP route refresh mechanisms
  to provide for the demarcation of the beginning and the ending of a
  route refresh.  The enhancement can be used to facilitate correction
  of BGP RIB inconsistencies in a non-disruptive manner.

Working Group Summary

  WG discussion was extremely active and produced
changes that were fed back into the implementations of
3 router vendors.

Document Quality

Debate provided good feedback and refinement for 3 implementations.
2 Implementations (Cisco and NTT I3) are described the implementation report:
http://tools.ietf.org/html/draft-ietf-idr-enhanced-refresh-impl-00

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

Editorial review was done, and should result in -07 version.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No, the extremely active WG list discussion had implementers,
operations people, and carriers.


(5) Additional Reviews in Progress
1) IANA Early review requested
2) OPS-DIr Early review requested

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

NO IPR has been claimed on this draft. 

(8) IPR disclosures: None

(9) WG Consensus:Strong WG Consensus with vibrant and constructive
comments resulting in operational fixes that vendors implemented.
3 implementations reported. Two document in:
http://tools.ietf.org/html/draft-ietf-idr-enhanced-refresh-impl-00


(10) Appeals and Discontent: None

(11) Nits: Exist
Following nits and editorial issues will result in revision -07 (pending from authors)
a) too-long lines
b) RFC 2119 boiler plate issues
c) editorial issues


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Document needs IANA due to assignment. It needs OPS-DIR and RTG-DIR review due to  Route Refresh deployments.  Early reviews have been requested, and
this shepherd write-up will be updated as the Early reviews are done.

(13)/(14)/(15) Normative/informative References:
All up-level, an Checked

(16) Will publication of this document change the status of any
existing RFCs?

RFC 2918 is being modified.  Version 07 of this draft should have this change.
(this note will be removed

(17) IANA Considerations (Shepherd's review)

All protocol registries and assignments are correct, but an early IANA review has been requested.

  This document defines the Enhanced Route Refresh Capability for BGP.
  The Capability Code 70 has been assigned by the IANA.  This document
  also defines two new subcodes for the Route Refresh message.  They
  need to be registered with the IANA. 

18 - New registries:
IANA will need to create a registry for the Route Refresh message subcodes as follows:

      Under "Border Gateway Protocol (BGP) Parameters":
      Registry: "BGP Route Refresh Subcodes"
      Reference: [draft-ietf-idr-bgp-enhanced-refresh-06.txt]
      Registration Procedure(s): Values 0-127 Standards Action, values
      128-254 First Come, First Served, Value 255 reserved

      Value  Code                Reference
      0      Route-Refresh      [RFC2918], [RFC5291]
      1      BoRR                [draft-ietf-idr-bgp-enhanced-refresh-06.txt]
      2      EoRR                [draft-ietf-idr-bgp-enhanced-refresh-06.txt]
      255    Reserved

2nd new registries:

      Under "BGP Error Subcodes":
      Registry: "BGP ROUTE-REFRESH Message Error subcodes"
      Reference: [draft-ietf-idr-bgp-enhanced-refresh-06.txt]
      Registration Procedure(s): Values 0-127 Standards Action, values
      128-255 First Come, First Served

      Value  Code                    Reference
      0      Reserved
      1      Invalid Message Length  [draft-ietf-idr-bgp-enhanced-refresh-06.txt]


(18) List any new IANA registries that require Expert Review for future
allocations. 
These are standard's registries so the IDR WG will need to work.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not applicable.