Subject: RE: Scalable and manageable network management and operation of MPLS/ VPN

From: "Fang, Luyuan, ALCNS" <[email-masked]>
Date: Fri, 22 Nov 2002 21:13:33 -0500

Weijing, 
Though your questions were for Tom, I'd like give some quick answers since we implement 2547 to provide the services to our customers. 
1. > CE-PE access link: That is what I must do regardless what kind of services, VPN or not. We can check this off. 
That is right. 
2. > CE-PE routing: What do I need to do to: establish, keep track of, and troubleshoot? 
You can run same protocols as for IP services, eBGP/OSPF/static/RIP, etc. For Enterprise VPN, you provision the VPN on PE only, VRF, RD, RT are all transparent to your customers. Yes, you need keep track of them in your systems. 
3. > VRF: Besides RD assignment for this VPN, what about RT? How do I know what RT to use? Is a management system to assign, track RTs necessary? What else need, MP-BGP? 
VRF, RD and RT can all be assigned automatically by provisioning systems and tracked by provision/management systems. You can develop such system in house or use tools from vendors or third parties. Establish MP-BGP connectivity through RRs is also part of auto-provisioning process. 
4. >Inner label (or VRF VPN label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? 
Labels are assigned by the routers automatically, not assigned by management system or provisioning system. Router A will tell router B to use label X to reach VPN ABC on router A, router B will tell router A to use label Y to reach VPN ABC on router B. 
5. Outer label (or PE Tunnel label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? 
Same as above, all MPLS labels (VPNv4(v6), LDP, IPv4(v6), RSVP-TE, etc.) are auto-generated by the routers, not management systems.
You might want to get a little more familiar with RFC2547 and other MPLS basics before criticizing. 

Luyuan Fang
AT&T,  IP backbone architecture

	-----Original Message-----
	From: Chen, Weijing [mailto:[email-masked]]
	Sent: Friday, November 22, 2002 3:46 PM
	To: 'Thomas Nadeau'
	Cc: 'PPVPN'
	Subject: RE: Scalable and manageable network management and operation of M PLS/ VPN
	
	Thomas,
	I guess I stirred up a hornet nest. To clam down the concern that I may advocate one VPN technology over another VPN technology, you can relax, I do not. As matter of fact, I have same concern over all the solutions.
	Now forgive my ignorance, please help me out on the following steps that I must do to establish, keep track of, and troubleshoot a VPN subscriber. If I am wrong, tell me what is right.
		CE-PE access link: That is what I must do regardless what kind of services, VPN or not. We can check this off. 
		CE-PE routing: What do I need to do to: establish, keep track of, and troubleshoot? 
		VRF: Besides RD assignment for this VPN, what about RT? How do I know what RT to use? Is a management system to assign, track RTs necessary? What else need, MP-BGP? 
		Inner label (or VRF VPN label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? 
		Outer label (or PE Tunnel label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? 
So help me out here.
	--
	Weijing Chen
	-----Original Message-----
	From: Thomas Nadeau [mailto:[email-masked]] 
	Sent: Friday, November 22, 2002 1:50 PM
	To: Chen, Weijing
	Cc: 'PPVPN'
	Subject: Re: Scalable and manageable network management and operation of MPLS/ VPN
	At 12:07 PM 11/22/2002 -0600, Chen, Weijing wrote:

	Yakov,

	Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list archive.

	>>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"?

	In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the attributes on the port serving the subscriber. We have to dedicate resources to the subscriber that go deeper into the network than just their port. Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult.

	If you look at network management this way, then of course, any VPN technology you
	look at will not be scalable. However, the success of 2547 is indeed that a well designed
	management system can managed new customers by managing basically the VRF attributes. 
	The typical addition of one (or hundreds) of customers should not affect the layout of your internal
	network or even the PE where those customers are attached if you did things correctly 
	from the start. For example, many providers I know will size how many customers a
	particular PE can handle in their lab. Once they know this, they just provision
	customers in a single, easy way. Once they get near the limit, they order another
	PE. This also plays into the larger design of the core network of course, but I think
	that if your network is designed to slimly that it needs to be re-provisioned whenever
	any customer is added, that you should think about your design again. 

	Specifically, the resources we have to dedicate and manage are:
		Virtual Routing Functions. Nearly one for each CE/PE interface. Each one of these, from a management standpoint, is a router. Right now, large IP carriers manage hundreds to possibly a few thousand routers. With IP VPNs, we'll be managing tens of thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump. 
Perhaps you can explain to me why you think that the addition of one customer is going to 
affect all of the nodes in your network? I do not know of any deployments where providers
re-provision their entire network based on the addition or re-provision of a 2547 customer.
		Connections between VRFs. Each VRF in a VPN has to have a connection to every other VRF in the VPN. The more VRFs you have (100,000), the more connections you have between them. 
You are thinking about this as if MPLS is a connection-oriented network, which it
is not. The exception is if you are using RSVP-TE tunnels between PEs. However,
a typical 2547 network uses LDP to establish sessions and distribute
labels between PEs, not each VRF. In essence, you get paths between PEs
over which you switch the VPN labels. I think that you are thinking of things
as if there are actual connection-oriented paths between all VRFs in a VPN.
Even if you use RSVP-TE tunnels between PEs, you can
support many hundreds or thousands of VPNs between those PEs without needing 
a TE tunnel per VRF inter-connection. Thus only a small number of tunnels exist 
between PEs (as opposed to specific tunnels for each VPN or VRF-pair).
		Connections between PEs. Each PE in a VPN has to have a connection to every other PE in the VPN. This connection maybe shared by multiple VRFs in the same PE pairs. 
Yes, but why is this a problem? 
		However, tracking of what connection to be shared or establishing new one if not shared is another daunting task. 
Just look at the loopbacks at one VRF and that gives you pointers to the other PEs.
If you are interested in figuring out which physical links are shared by which VRFs on 
a particular PE, then just look at the LFIB based on the label used by the loopback.

	Each single item above is translated into $$, which including recurring OPEX for operation and OSS system maintenance, and nonrecurring CAPEX for OSS system.

	I am not sure of that based on my experience with my customers who have 
	deployed 2547 networks. Certainly CAPEX is required for the equipment to begin
	with, but OPEX is actually quite low for 2547 as compared to many other VPN
	technologies, especially if your OSS and network deployment strategy is sound
	to begin with. I am not saying that management of any network and certain 2547-based
	is easy, but I totally disagree with the assertion that a 2547 network is not scalable
	based on how it must be managed.
	
	--Tom

	>>Also, when you said "we operation group in service provider", do you mean a specific service provider?
	
	Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of subscribers (number of sites), such as us

	Regards,

	--
	
	Weijing Chen
	
	SBC Technology Resources
	
	9505 Arboretum Blvd.
	
	Austin, TX 78759
	
	512 372 5710