Subject: Address Allocation for PE-CE links

From: Vincent Parfait <[email-masked]>
Date: Wed, 27 Aug 2003 01:14:08 -0700 (PDT)

Ross, Rick and Ron,

The comments received last april on the PPVPN mailing list regarding the PE-CE addressing draft have been consolidated and integrated into a new version : http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-03.txt

Compared to version 2, the changes are :

- the title was changed to show that the scope of this draft is not restricted to 2547 networks but covers Provider Provisioned VPN neworks in general

- the size of the address block requested is changed from [TBD] to /12 with some explanations on this choice 

To move forward, I suggest that the draft now becomes a L3VPN WG document. 

Thanks to advise, 

Vincent

----------------------------------------------------------------------

22/04/2003 17:38

To: [email-masked], "Marco Carugi" <[email-masked]>, [email-masked]

Subject: PE-CE addressing draft

This is to inform you that the draft-guichard-pe-ce-addr has been updated : http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt

I invite you to read through this new version and give your feedback to the list.

The main motivation for this proposal is to simplify the Service Providers operations in the scenario where they monitor CE-PE links, and/or CE routers, while at the same time conserving IPV4 address space.

Large Service Providers such as Equant, ATT and Arcor are supporting this draft and are requesting that it becomes a working group document.

Vincent Parfait
Equant

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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 28 Aug 2003 11:14:49 -0400

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