v6ops-routing-guidelines ID

[Danny McPherson <danny@tcb.net>]

[resend]

As stated at the microphone, my particular concern regarding
this draft is that making routing recommendations like this result
in both control plane and data plane issues when new address
prefixes are allocated.  We've seen this many times over the
past few years, resulting in extremely fragmented policy in ISP
networks.

2.5.  Global Unicast

   The global unicast routes (2000::/3) [RFC4291] may be advertised in
   an IGP or EGP.

   A minimal EGP routing policy should filter out routes that exceed a
   maximum length.  Determining the maximum length of a global Internet
   route is outside the scope of this document.

   A finer EGP routing policy may use only the allocated address space
   from IANA to registries as specified in
   http://www.iana.org/assignments/ipv6-unicast-address-assignments.
   This would result in better filtering since the non-allocated
   prefixes will be filtered out.

Again as we've seen, this leads to fragmented reachability
issues when filters aren't updated and new prefixes are allocated.
This manifests itself as both a control AND data path issue.  I.e.,
if I'm not accepting reachability information for a given prefix then
as a matter of policy why would I accept packets sourced from or
destined to that address space?  And then something new is
allocated and there's a lag there between when it's used and
policies are updated to accommodate the allocations.

   An even finer EGP routing policy may use only the assigned address
   space from registries to providers as available in the registries
   databases.  This would result in the best filtering since the non-
   assigned prefixes will be filtered out.  However, this requires the
   synchronization of the filters with the registries databases.

This is all that we should be recommending, if anything, IMO,
and note that the previous paragraph requires precisely the same
amount of "synchronization".

Also, the entire 2.5 section is in conflict with the abstract, in
particular the "It does not discuss operational or policy issues
such as the maximum length of prefixes to filter." statement.

I agree with Pekka in that simply likening and scoping this
document such as RFC 3330 Special-Use IPv4 Addresses would
be a much better model for the IETF to follow, then perhaps a
routing and control plane discussion in a deployment considerations
section that touches on what operators might want to consider
wrt operational policies and associated caveats.  Perhaps even a
BCP 38 reference is in order?

Also, what is the intention of this document?  BCP, at best,
or perhaps even informational?  I would think the latter like
RFC 3330.  It's current status is currently labeled as "Standards
Track", which I suspect is a bit off base.

Some other nits:

2.6.  Default Route

   The default unicast route (::) may be advertised in an IGP.  It must
   not be advertised in an EGP unless it has been requested by the
   recipient.

How does one request a default route?

2.8.  Unknown addresses

   Any non listed address above must not be advertised and should be
   filtered out.  Future work might reserve additional address space  
for
   protocol use which might require specific routing guidelines.  The
   reader should refer to newer versions of the normative references in
   this document to verify the existence of newer protocol address
   space.

Where would operators find such a list if we're recommending they
filter these address spaces?

In section 3.0 in addition to the BCP 84 reference, a BCP 38
reference should be included.

In summary, I would much rather decouple routing guidelines
(which these are more of "don't route guidelines") from any ID
document explicitly and provide the relevant IANA and RIR
policies, and subsequent to that, IRR, etc..

I would much rather see a document here akin to RFC 3330.

I do believe there would be utility in a general routing
guidelines document, but see the scope as quite a bit
larger than this, and it's home would perhaps be GROW
rather than here.  A cross-WG review from GROW of this
document if it continues would likely be a good thing as
well.

-danny