Re: [rrg] draft-narten-radir-problem-statement-05.txt

Thomas Narten <> Wed, 24 February 2010 22:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD5BF28C223 for <>; Wed, 24 Feb 2010 14:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.028
X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1K5KNagIVXTD for <>; Wed, 24 Feb 2010 14:04:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2395828C1D0 for <>; Wed, 24 Feb 2010 14:04:29 -0800 (PST)
Received: from ( []) by (8.14.3/8.13.1) with ESMTP id o1OLtYcO002333 for <>; Wed, 24 Feb 2010 16:55:34 -0500
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id o1OM6SJI129398 for <>; Wed, 24 Feb 2010 17:06:30 -0500
Received: from (loopback []) by (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o1OM6ShF002413 for <>; Wed, 24 Feb 2010 19:06:28 -0300
Received: from ( []) by (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o1OM6RUH002378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Feb 2010 19:06:27 -0300
Received: from (localhost []) by (8.14.3/8.12.5) with ESMTP id o1OM6O4J023229; Wed, 24 Feb 2010 17:06:24 -0500
Message-Id: <>
To: "Joel M. Halpern" <>
In-reply-to: <>
References: <> <>
Comments: In-reply-to "Joel M. Halpern" <> message dated "Wed, 17 Feb 2010 20:16:05 -0500."
Date: Wed, 24 Feb 2010 17:06:23 -0500
From: Thomas Narten <>
Subject: Re: [rrg] draft-narten-radir-problem-statement-05.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Feb 2010 22:04:31 -0000

Hi Joel.

Thanks for the comments.

> Thomas, one major and some minor comments on the document.

> The discussion of IPv6 routing table size in section 4.6 seems 
> misleading.  The discussion seems to have no component to represent the 
> present and increasing demand for PI addresses in order to support 
> multi-homing and ease of renumbering.  If we do not have a routing 
> architecture and system which addresses those pressures, and if we do 
> not manage to keep in place an artificial barrier to such PI 
> assignments, the size of the tables will grow dramatically.  Some 
> stimates place the expected number of multiohomed enterprises in the 
> ballpark of 10,000,000.  That would represent a significant growth in 
> the control plane, the RIB, and the FIB.

This section was intended to simply point out that dual stack adds
even more routes, in the sense that one will need both IPv4 and IPv6
route to the same destination. That only further increases the overall
number of entries a router deals with.

It goes without saying (and looking back, the document doesn't say
this) that all the  pressures that apply to IPv4 routing, apply pretty
much equally to IPv6.

Seems to me, that the best way to deal with that is to add a new
paragraph (perhaps in the introduction) that calls this out
explicitely. I.e., something like:

   Most of this document does not distinguish between IPv4 and
   IPv6. The overall routing archtecture for the two protocols is the
   same. Consequently, most of the issues in this document apply
   equally to IPv4 and IPv6. Any behavior that places pressure on IPv4
   routing is likely to also exert the same pressure on IPv6.
   Deployment of IPv6 will not lessen these pressures in most cases.

> Section 3.3 is titled "Alignment of Incentives".  It then begins with a 
> partial description of the pressures that Multihoming and Traffic 
> Engineering put on the system.
> It would seem that the document would be clearer if there were a section 
> describing the need to support multihoming and traffic engineering in 
> general (leaving the details for section 4 probably), and the fact that 
> these tend to produce growth in all the dimensions cited earlier.  That 
> could then be followed by section 3.3 with something similar to the 
> current second paragraph, which is actually about the Alignment of 
> Incentives.
> It would then seem sensible to include a paragraph about the need for 
> any mechanisms for improvement to have to property that the costs and 
> incentives for deploying the improvement are aligned.  (This appears in 
> the summary in section 6, but needs to be explicitly stated earlier in 
> the document.)

Let me think about this. I think I agree that the section would
benefit from some restructuring.

> Would it make sense to include in section 4.3 (End Site Renumbering) to 
> observation that this problem has also driven some NAT deployments? 
> (No, that is not a route scaling problem, but it reminds the reader of 
> an indirect cost of not solving these problems in an effective
> fashion.)

I guess I'm on the fence on this one. The goal of this document was to
describe the problems surrounding route scaling. So far, we have tried
hard not to add stuff that isn't directly related especially if people
might have strong views on the topic. In fairness, if we were going to
mention NAT, we'd have to point out that it has also helped relieve
pressure on the routing system -- i.e., there is a benefit.

> Should we at least acknowledge in section 5 that our habit of addressing 
> any and all problems with BGP extensions puts pressure on the control 
> plane?  (It may be that this component is manageable, but I wonder.) 
> Each of these features have been put in for very good reasons, but RFC 
> 2547 VPNs, Flow-Routes for black-holing DDOS, and add-path routes to 
> allow use of multiple parallel routes, are all examples of features wew 
> have or are putting in the system that increase the pressure on the 
> Control Plane.  [Note, I am not saying that these are wrong choices. 
> They may well be correct choices, and BGP may well be the right place to 
> address these needs.  But we should recognize that this puts pressure on 
> the system.]

Given yours and Danny's comment on this, how about something like:

      BGP is the routing control plane protocol in use today. Because
      of its ubiquity and centrality to routing, it is also a natural
      place to add features that enhance routing functionality, some
      of which may not be strictly necessary to support DFZ routing
      (e.g., RFC 2547 VPNs). The use of such extensions also place
      additional pressures on the routing control plane as they must
      be sent, received, processed, etc. along with other routing