The MPLS WG Archive

[Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>]

Hi Curtis,
First of all, I observed a kind of dispute and thought, a set of numbers which everyone agrees upon  would be helpful to either reach consensus 
or preciser disagreement. The numbers which I gave are just examples, backed by no investigations.

 Scalability is important. But let me add a few other issues.

1) support of building alliances of VPNs, such that a particular VPN can easily join and also easily quit a particular alliance of VPNs.
    Here, IMHO: The VPN ID becomes important (so far RFC2547 does not exploit the VPN ID)

2) Establishing a VPN by a network administrator completely from his desk. 
   Juha's "soft-LSP" scenario   should even be extended to a "3rd-party LSP setup" scenario. 
   If the administrator is hooked to router C, but shall initiate the establishment of an LSP from router A to router B, he might be interested to know and to
   dictate the route from A to B. If I see it correctly, then a Distance Vector Protocol (like BGP) does not yield the view of all the network mashes, but only
   a collection of routes, e.g. which  start at router C.  The administrator at router C can only send to router A the command "establish an LSP to router B,
   but find out yourself what is the proper route". If router C knew the entire topology (by OSPF,IS-IS) than router C could send to router A also all information wrt
   route from A to B.

3) Routing between different (and not allied) VPNs while utilizing the installed source- and destination-VPNs:
    IMHO: Source- and destination VPNs are utilized best, if a route across public service providers in-between is shortest, which impacts
   where to exit the source VPN and where to enter the destination VPN.
   

4) Imagine a "Pay-TV multicast" scenario. It may be of monetary interst from a particular VPN prospective that the delivery tree enters the
    VPN only once, no matter when and how many users inside this VPN want  to JOIN.


IMHO, these are all valid points and shouldn't be played down just because the currently existing protocols have problems to support them.
This is true for the routing protocols, for the multicast protocols and also for the IPv6 design. I don't think that VPN is properly covered by IPv6 addressing 
(nor is multicast).

Though it needs a lot of study first and may take some time for working out the adequate solutions, it should be worth the effort.

We should not aim for further interim solutions. There are already interim solutions: RFC 2547 as well as the Virtual Routers. But others
may disagree and believe these solutions cannot be improved.

What do you think?
   
Heinrich
>  
> 
> 
> If you wish to make a point wrt the scaling capabilities of rfc2547 or
> the rfc2547bis i-d, please go ahead and do so.  There is no need for
> everyone to agree on your growth projections first.
> 
> I doubt that Cisco will drop their push for it and rfc2547 probably
> won't be declared historic or abandoned any time soon but I for one
> would be interested in your analysis.
> 
> Curtis
> 
> 
	 
	In message <DB74A4E69C7CD311B740006008136E078D3495@MCHH213E>, Hummel Heinrich w
	rites:
	> Hi all,
	> 
	> Is it possible or do you all think it will be helpful to first of all agree o
	> n a set of  fictitious but reasonable numbers, e.g. like
	> 
	> envisioned number of small-sized vpns of up to 10 sites       = 100 000
	>                 number of  medium-sized vpns of up to 300 sites = 2000
	>                 number of large-sized vpns of up to 2000 sites     = 500
	> 
	> number of nationally operating SPs = 500
	> number of nations =200
	> 
	> number of internationally operating SPs = 100
	> 
	>  Are there other important figures and differentiations ? And what would be t
	> he values everybody will agree on ?
	> 
	> I think the dispute on RFC 2547 and on BGP concerning chokes and limitations 
	> would have a better fundament and would
	> yield better results, if all agree first on a set of such figures.
	> 
	> 
	> Heinrich Hummel
	> Siemens
	> 
	> heinrich.hummel@icn.siemens.de