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

rrg mailing list

Reply via email to