Re: [CONTENT] RE: [arch-d] Re: Notes From Monday Nights Meeting

[Fred Baker <[e-mail]>]

On Nov 9, 2006, at 8:20 AM, Schliesser, Benson wrote:
> This feels like feature-creep to me, when the business really needs  
> us to just ship a product. That is, unless shipping the product  
> would lead to massive recalls etc, but I haven't heard any real  
> argument to that end yet.

I'll suggest that you look through
	http://tools.ietf.org/html/draft-baker-v6ops-l3-multihoming-analysis
	http://tools.ietf.org/html/draft-ietf-ipngwg-esd-analysis
	http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr
	http://www.vaf.net/~vaf/v6ops.pdf or (longer) http://www.vaf.net/ 
~vaf/iepg.pdf

Bottom line, I didn't look at GSE in the draft above, but I looked at  
what we're doing now, and I looked at two other things that the IETF  
has looked at, and compared them to the stated requirements for the  
problem in RFC 3582. What I came up with is that PI addressing as  
practiced today is very likely to put O(10^7) routes into the  
backbone by 2050, and by a different analysis Vince Fuller reports a  
similar number within 15 years. Compared to our present O(10^5)  
routes, that's a lot, and it drives

  - equipment cost: recalling that the route table is replicated in  
many memory systems on each high end router, how much did you want to  
pay for the equipment?
  - service delivery cost: power, cooling, ...    Recall that Google  
is siting plants by rivers to address power and cooling now...
  - route scalability: BCP 38, as I discussed a few days ago, imposes  
some interesting issues in IPv6 routing

I'm told that traffic engineering is a big deal as well, which leads  
me to believe that we don't have all the requirements on the table,  
and to be frank I'm a little peeved that after ten years of bickering  
and dismissive slamming of each other both IETF->ISPs and ISPs->IETF  
we haven't managed to get that basic step done.

It's not feature-creep. There is a very expert set of people who  
stated up front that this problem needed to be addressed (among  
others), and it hasn't gotten addressed. This is kind of their last  
chance to get it addressed, and they really want to do so. I think it  
is better for us that we take the step and have an honest and non- 
combative discussion on the topic.

The biggest problem, frankly, is that we have conflicting  
requirements and two communities that are willing to hurl insults  
rather than listen and help. An example of the conflicting  
requirements is that Vince and others, and many in the enterprise  
community, want IP addressing without the requirement to renumber  
when you leave a service provider, and consider that a fundamental  
need, while many in the ISP community see IPv6 PA addressing as a  
market lock and therefore something advantageous to them. Yes, I have  
heard those words from ISP mouths. We can't both create and not  
create a market lock, and whichever group we fail to please is  
guaranteed to be wandering around making pretty strong statements  
about the unresponsiveness and stupidity of the IETF community. shim6  
right now creates a market lock for any customer that abhors  
renumbering.

_______________________________________________
Architecture-discuss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/architecture-discuss