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

From: "Chen, Weijing" <[email-masked]>
Date: Fri, 22 Nov 2002 14:46:01 -0600

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.

1.	CE-PE access link:  That is what I must do regardless what kind of
services, VPN or not.  We can check this off.
2.	CE-PE routing:  What do I need to do to: establish, keep track of,
and troubleshoot?
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?
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? 
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?

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:

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

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

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

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 22 Nov 2002 16:29:34 -0500

At 02:46 PM 11/22/2002 -0600, Chen, Weijing wrote:

>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.
>
>
>
>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 
>    * CE-PE routing:  What do I need to do to: establish, keep track of, 
> and troubleshoot?

         Depends on what you run on the CE-PE link, and what sorts of 
things you are worried
about (i.e.: are you concerned with SLA or just connectivity?).

>    * 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?

         These things are covered as part of a service profile that you 
need to work out in your
provisioning system.  There are standard APIs for provisioning these things 
via SNMP, or
you can also use other various proprietary interfaces such as XML or CLI.

>    * 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?

         As Yakov suggested, I think that you need to become more familiar 
with how 2547 works.
You generally do not need to configure the inner or outer labels; the 
router does that
(although you can if you want to).  One good place to start to look for 
what needs to be
configured on a VRF is in the PPVPN-MPLS-VPN MIB.  Of course this is only a 
start, as
you may also want to configure MP-BGP, link or QoS parameters for each VRF.

         --Tom

> >>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 
>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
>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
>    * 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
>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.
>
>is not. The exception is if you are using RSVP-TE tunnels between 
>PEs.  However,
>over which you switch the VPN labels. I think that you are thinking of things
>    * 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.
>
>    * However, tracking of what connection to be shared or establishing 
>         Just look at the loopbacks at one VRF and that gives you pointers 
> to the other PEs.
>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
>technologies, especially if your OSS and network deployment strategy is sound
> >>Also, when you said "we operation group in service provider", do you 
> mean a specific service provider?
>

Success is relative; the more success, the more relatives. -Anonymous