Outbound Route Filtering Capability for BGP-4
draft-ietf-idr-route-filter-17

[Ballot comment]
The security considerations section in both documents is correct in noting "does not change
the underlying security issues" but lacks a reference to the unchanged information.  Please
add a reference to RFC 4271.

[Ballot comment]
From Tom Yu's SecDir review:

Should the document say that even if you send route filters to the
other end, you still need to apply the filters locally (even though
normally the other end won't send you routes that get filtered)? Or is
this obvious to most readers?

[Ballot comment]
draft-ietf-idr-route-filter-16, Section 6., paragraph 0:
> 6. Operation

  I think all the SHOULDs in this section should be changed to MUSTs, or
  the document should to describe under which conditions it is
  appropriate to deviate from the SHOULDs.


draft-ietf-idr-route-filter-16, Section 6., paragraph 11:
>    The set of ORF entries that the speaker sends to the peer expresses
>    the speaker's local preference, that the peer MAY or MAY NOT decide
>    to honor.

  MAY NOT is not an RFC2119 terms - rephrase


draft-ietf-idr-route-filter-16, Section 4, paragraph 1:
>    [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y.,
>    "Multiprotocol Extensions for BGP-4", draft-ietf-idr-rfc1858bis-
>    10.txt.

  This means to cite 2858bis, now published as RFC4760.


draft-ietf-idr-bgp-prefix-orf-04, Section 4, paragraph 1:

>    [BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
>    "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

  Obsoleted by RFC4760 - should probably cite the replacement.

[Ballot discuss]
I am missing any considerations concerning manageability. From the WG charter I get that MIB extensions should be included in a BGPv2 MIB, which is fine, but I think that this document should include a list of any configuration or statistics objects that must be part of the instrumentation, so that the future MIB work can use them. Also, if there are any events like state changes that need to be reeflected in notifications they should also be mentioned here.

[Ballot discuss]
This is a great set of documents and a much needed function. I will
move to Yes position as soon as the one simple mistake below is
corrected:

The document says:

  This document imposes the following requirement on the values of
  these fields:

          0 <= Length < Minlen <= Maxlen

However, it seems to me that this cannot be imposed when MinLen or
MaxLen are unspecified. For instance, the document later states that
if MinLen and MaxLen are unspecified, then NLRI.length = ORF.length
results in a match, no matter what that length is. For length 24,
for instance, we'd get

          0 <= 24 < 0 <= 0

Which is clearly false. There are two possible ways to fix this: get
rid of the unspecified values and simply use 0 and 32/128. Or, the
simpler way:

OLD:
          0 <= Length < Minlen <= Maxlen
NEW:
          0 <= Length < Minlen <= Maxlen

  However, tests related to Minlen or Maxlen should be omitted
  when Minlen or Maxlen (respectively) is unspecified.

[Ballot discuss]
The document says:

  This document imposes the following requirement on the values of
  these fields:

          0 <= Length < Minlen <= Maxlen

However, it seems to me that this cannot be imposed when MinLen or
MaxLen are unspecified. For instance, the document later states that
if MinLen and MaxLen are unspecified, then NLRI.length = ORF.length
results in a match, no matter what that length is. For length 24,
for instance, we'd get

          0 <= 24 < 0 <= 0

Which is clearly false. There are two possible ways to fix this: get
rid of the unspecified values and simply use 0 and 32/128. Or, the
simpler way:

OLD:
          0 <= Length < Minlen <= Maxlen
NEW:
          0 <= Length < Minlen <= Maxlen

  However, tests related to Minlen or Maxlen should be omitted
  when Minlen or Maxlen (respectively) is unspecified.

[Ballot comment]
s/NLRI.legnth/NLRI.length/

In the abstract, make the following change so that the subsequent
use of the acronym ORF is explained:
OLD:
  This document defines a new Outbound Router Filter type for BGP,
NEW:
  This document defines a new Outbound Router Filter (ORF) type for BGP,

[Ballot comment]
In the abstract, make the following change so that the subsequent
use of the acronym ORF is explained:
OLD:
  This document defines a new Outbound Router Filter type for BGP,
NEW:
  This document defines a new Outbound Router Filter (ORF) type for BGP,

[Ballot comment]
From the Gen-ART Review of draft-ietf-idr-route-filter-16 by
  Joel Halpern: I believe that the intention for removing ORF entries
  is that the remove request shall contain the full and exact ORF to
  be removed. However, the text merely refers to the "specified entry"
  without explicitly stating how it is specified.

IANA correction:

Rather than assign a new BGP Capability called "Outbound Route Filtering Capability," value TBD, IANA will change the name of the Capability associated with value 3 from "Cooperative Route Filtering Capability" to "Outbound Route Filtering Capability." The reference will be changed to this document.

IANA Last Call comments:

NOTE: BGP Capability 3 is already assigned to the Cooperative Route
Filtering Capability. This document will not be assigned capability
number 3.

QUESTION: Do you want/need a registry of 'when-to-refresh' fields?
(Section 4)

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "Capability Codes" registry at
http://www.iana.org/assignments/capability-codes

Value  Description                          Reference
------- -----------------------------------  ---------
[tbd]  Outbound Route Filtering Capability  [RFC-idr-route-filter-16]


Action 2:

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD

Registry Name: BGP ORF Type
Reference: [RFC-idr-route-filter-16]
Range    Registration Procedures              Notes
--------- -----------------------------------  ------
1-63      Standards Action or Early Allocation
64-127    First Come First Served
128-255  Reserved for Vendor-specific        IANA does not assign

Registry:
Value    Description                  Reference
-------  ----------------------------  ---------
0        Reserved                      [RFC-idr-route-filter-16]
1-127    Unassigned
128-255  Reserved for Vendor-Specific  [RFC-idr-route-filter-16]


We understand the above to be the only IANA Actions for this
document.

From: Yakov Rekhter
Subject: BGP ORF and Prefix-ORF to Proposed Standard
Date: Wed, Jul 5 10:06:22
To: Bill Fenner
Cc: skh@nexthop.com, idr@ietf.org, iesg@ietf.org

Bill,

The IDR WG asks to advance the following Internet Drafts to
Proposed Standard:

  draft-ietf-idr-route-filter-14.txt
  draft-ietf-idr-bgp-prefix-orf-03.txt

Implementation report is draft-chen-bgp-orf-survey-00.txt (it
covers both of the above drafts).

Yakov.