Subject: Re: Address Allocation for PE-CE links

From: Robert Raszuk <[email-masked]>
Date: Tue, 02 Sep 2003 15:02:03 +0200

Vincent,

The draft does addresses a real need - I must admit so. But since the
very early days of this draft I am not sure if the approach sugested has
a possibility to work. The draft is based on assumption that there is a
solid line on the definition of "Service Provider" as such entity. 

From my experience with all practical reason there is no such solid
line. I know a lot of global enterprises with dedicated network
departments who provide services to their own branches or to other
smaller enterprises and may in turn use Tear-1 providers for their POPs
connectivty. So if they would start using defined here address ranges I
think the draft's main benefit is out. The same applies to smaller SPs
offerering 2547bis and yet using global SPs for connectivity. 

So at minimum I would like to see a clearly added definition who the
"Service Provider" is to the draft. Example: "Service Provider is an
entity who does not use any other provider for L3 connectvity" (if such
a definition will be accepted by L3VPN community ;). 

Rgs,
R.

---

From: Vincent Parfait <[email-masked]>
Date: Mon, 1 Sep 2003 06:54:01 -0700 (PDT)

Thanks for your reply and comments.

Regarding your point 2 - size of the address block - the /12 should be sufficient for most SPs (allowing for more than 250K CEs). If ever one SP needs more addresses, then a new address allocation request could be issued. However, when reaching such number of CEs, an SP will likely face other scaling issues requiring the partitioning of the management system. 

As you pointed out in 3, the most important is then to prove that this /12 would provide a real benefit wrt the conservation of the global address space. Unfortunately nobody will be able to produce tangible evidence like listing all SP's addressing requirements ... However simple calculation show there is a case. There are currently tens of SPs deploying 2547-like VPNs. If let say only 30 of them will manage 80K connections, then 150 class B will be needed to addess these connections, ie almost 10 times more than the requested range !

Regarding point 4, let say this proposal does not pretend to do any better than private addressing based on RFC1918 addressing 

Discussions on this draft always converged to the fact that it would be too difficult, and not justified, to request a /8. Today the draft defines a pragmatic approach in order to move forward. Shouldn't IANA be contacted at this stage to discuss with them the type of consensus needed ? Any idea on the people to contact ? 

Vincent

Thomas Narten <[email-masked]> wrote:This document has come up within some informal IESG discussions. There
may well be some serious difficulty in convincing the IESG, IANA,
etc. that this is a good idea. Note also the comment from the Yokohama
meeting:

> Scott - The likelihood of setting aside a /8 for VPN providers is
> close to zero.

Bottom line: this document will not be an easy sell, and needs careful
and rigorous justification, as well as strong community consensus.

I think I understand the problem this document is trying to
solve. Namely, rather than use global/public address space to number
certain links, they can all be numbered out of a single SP-reserved
prefix.

Main Benefits: conserve global address space, don't need to get it
from RIRs.

Having said that, I'll note:

1) There are very few address blocks that are reserved for a
particular purpose (e.g., net 10, etc.). Thus, _any_ proposal to
reserve a chunk of space for some special purpose (other than
normal global numbering) will be viewed skeptically. The bar for
such allocations is high. So even if this WG thinks this makes
sense, the larger IETF community may not.

2) The document makes no serious attempt to quantify why /12 is the
right amount. Can't it be made smaller? (and note, the smaller the
size, the easier it will be to justify I suspect). On the other
hand, how do we know whether the size is large enough? If it isn't,
then what happens? Does the allocation in fact then not really
solve the problem and/or are we back where we started?

3) I don't see right off why these can't just be numbered out of
global space. Sure, conserving addresses is goodness, but the real
question is whether the cost of the proposal justifies the
benefits. If no allocation were given for this purpose, just how
much global space would be "wasted"? Is this amount worth trying to
conserve when looking at the big picture? (In my mind, this is the
critical question.)

4) Finally, what happens with SPs merge through acquisitions and such?
Using this scheme, one immediately has collisions among the
addresses used by the merged orgnizations, which is presumably not
a feature. Indeed, this may make the end result rather painful when
compared with just using global space. So, this scheme _does_ have
potentially serious drawbacks compared with just using public
addresses.

Thomas 

---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software