IPv6 Prefix Length Recommendation for Forwarding
draft-ietf-v6ops-cidr-prefix-03

[Ballot comment]
While I find it utterly amazing that this document was even written, I have been exposed to more than a handful of IPv6 implementations that get this wrong. So, I guess we do need a tool to hit folks over the head.

[Ballot comment]
Only editorial comments here, for your consideration.  The one about "barring" is the most important one.

-- Section 1 --
In the second paragraph, I suggest removing the parentheses from "(mis)".

In the fourth paragraph, I had to read the first sentence several times in order to parse it.  The word order confused me, making me think "link routing", rather than "to link".  You can easily fix that by changing "to not link" to "not to link".

In the fifth paragraph, "barring" is ambiguous: I don't know whether you mean that because IPv6 forwarding must follow the longest-match-first rule, configuration of an overriding policy is barred (forbidden), or whether you mean that IPv6 forwarding must follow the longest-match-first rule *unless* an overriding policy is configured.  I'm guessing it's the latter, but you should reword this either way, to make it clear.

In the last paragraph, what does "a historical reminder" mean?

-- Section 2 --
In the second paragraph, I note that too many attributive nouns put together make for awkwardness and confusion.  I suggest changing "Forwarding decision-making processes" to "Decision-making processes for forwarding", so it's clear that "forwarding" is a gerund (noun), not a participle (verb).

I suggest removing the word "obviously" from the third paragraph: if it's really obvious, it needn't be said at all, and the word makes it sound haughty.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-v6ops-cidr-prefix-01, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IPv6 Prefix Length Recommendation for Forwarding) to Best Current Practice


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6 Prefix Length Recommendation for Forwarding'
  as Best Current Practice

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 2015-04-20. 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


  IPv6 prefix length, as in IPv4, is a parameter conveyed and used in
  IPv6 routing and forwarding processes in accordance with the
  Classless Inter-domain Routing (CIDR) architecture.  The length of an
  IPv6 prefix may be any number from zero to 128, although subnets
  using stateless address autoconfiguration (SLAAC) for address
  allocation conventionally use a /64 prefix.  Hardware and software
  algorithms should therefore impose no rules on prefix length, but
  implement longest-match-first on prefixes of any valid length.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/ballot/


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

1. Summary
WG: v6ops.  Also discussed extensively in 6man, but as BCP, better for v6ops.
Shepherd: Lee Howard
AD: Joel Jaeggli

This short document makes a single BCP recommendation: Hardware and software algorithms should impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length. In other words, arbitrary bit boundaries such as 64 bits are arbitrary, and should not be imposed (or slowed) by routing and forwarding engines.
It is submitted as a BCP, since it makes recommendations to implementers without updating or contravening any standard.

2. Review and Consensus
Originally discussed in 6man as draft-boucadair-6man-prefix-routing-reco, with three responsive revisions between June and September 2014.  Revised again and submitted as draft-ietf-v6ops-cidr-prefix, with an additional revision.
The document was discussed in 6man at IETF91, with several comments, and consensus that it was sensible as a recommendation, but not as a protocol update, and therefore more properly belonged in v6ops.
It had been discussed on the 6man mailing list in October 2014, with about ten participants.  There was some question about whether it was needed or useful, but after discussion objectors generally removed their objections. There was consensus that the recommendation is appropriate.
Finally, discussion on v6ops list from December 2014 through February 2015 included a few additional participants. The document was refined into a clear BCP, with one objector worrying that requiring vendors to support any length might result in fewer possible routing table entries. Others did not share this concern. One commenter provided text updates, which were reflected in the final version.
Overall, participants have been very clear in expressing their support or concerns.


3. Intellectual Property
Authors have verified that they know of no intellectual property encumbrances.

4. Other Points
No references to clean up.
No IANA considerations.
No Security or Privacy considerations.