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

Fred Baker <fred@cisco.com> wrote:
> 
> I'll suggest that you look through
> 	http://tools.ietf.org/html/draft-baker-v6ops-l3-multihoming-analysis

   (33 pages)... written as advice to IP address registries: it is
unlikely that registries can do much about the problem. :^(

> 	http://tools.ietf.org/html/draft-ietf-ipngwg-esd-analysis

   (52 pages)... analysis of GSE proposal; I haven't read it either.

> 	http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr

   (20 pages)... the GSE proposal: calls for rewriting addresses at
site boundaries. At first blush, it looks like automated renumbering
for re-homing to a different upstream...

> 	http://www.vaf.net/~vaf/v6ops.pdf or (longer) http://www.vaf.net/ 
> ~vaf/iepg.pdf

   (19 slides)... explains why provider-independent routing-as-we-
know-it can't work.

> 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...

   Clearly unworkable!

   (I'll let others discuss the perpetual-motion-machines they envision
to get around this routing problem...)

> 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.

   Our problem is architectural: asking the routing infrastructure to
solve the reliability problem which multi-homing intends to address
can only decrease the reliability of the routing infrastructure.

   (I shall briefly resist the temptation to give an "obvioous" answer.)

> 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.

   By all means. But let's separate it from what particular protocol
we use for inter-netting.

> 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,

   Examine that statement carefully: it's not quite correct. They
want end-user source- and destination-addressing that need not change
when a particular upstream ceases to provide what they need for
reasonable prices and conditions. We'd be _very_ poorly advised to
(try to) deny them this.

> while many in the ISP community see IPv6 PA addressing as a  
> market lock and therefore something advantageous to them.

   The upstream providers want sufficient lock-in that they can
pass through any cost increases without worrying about losing their
customers. Without this, their businesses are more likely to fail.

> 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.

   IMHO, we can't create this market lock, period. The ISPs must
create it themselves (and I don't believe they'll succeed). We
should, however, beware "reasonable-sounding" calls to "protect
the infrastructure" by helping them create such locks.

--
John Leslie <john@jlc.net>

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/listinfo/architecture-discuss