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

From: "Chen, Weijing" <[email-masked]>
Date: Fri, 22 Nov 2002 15:12:12 -0600

Yetik,

Not "doing nothing", but "doing manageable thing".  What I am trying to
point out is that things we have to do now does not seem scalable to large
number.  Sure if the number of subscribers does not go up, we will be fine.
Hay, in that case, even CLI may work.

--
Weijing Chen

-----Original Message-----
From: Serbest, Yetik 
Sent: Friday, November 22, 2002 2:29 PM
To: Chen, Weijing; [email-masked]'
Cc: 'PPVPN'
Subject: RE: Scalable and manageable network management and operation of M
PLS/VPN

Weijing,

First of all, I need to understand your definition of "scalable
manageability". I think you mean "doing nothing". In other words, all the
intelligence will be at the customer's side, and the network will be dumb.
Let alone that it does not make sense from provider's point of view (i.e.,
revenue), it does not make sense from customer's point of view as some of
them don't want to deal with the complexity (e.g, fully meshed connections
and route peerings).

Otherwise, if you want to provide VPN service, all the things about RFC2547
you (mis)represented in your e-mail are necessary for this service, they
have not descended from heaven. The pros of RFC2547 are explained in
RFC2547bis draft quite well. In addition, the scalability of tunnels and
VPN-labels are really non-issue. For the troubleshooting, there are alredy
some tools, however, we still need to improve it.

In utopic world, things could have been different and this service could
have been provided differently. But this is an evolutionary step for a
really working network. On the other hand, I don't believe one can design a
new perfect network from scratch. 

thanks,
yetik

-----Original Message-----
From: Chen, Weijing 
Sent: Friday, November 22, 2002 12:50 PM
To: [email-masked]'
Cc: 'PPVPN'
Subject: RE: Scalable and manageable network management and operation of
M PLS/VPN

Robert,

Thanks for reply.  However, I don't think that I mixed the VR-based and
2547bis-based VPN.  Regardless it is a VR or a VRF, from management
standpoint, it is a router that we must management, e.g. route target id,
import id, export id, etc. in 2547bis case.  Also for VRF and PE connection,
LSP labels in both end and sometime LSP labels in the middle.  As long as
they are something that we must establish or assign, keep track of, and
troubleshoot, they require system resource and human resource.  And those
resources come with cost.

It reminds me of ATM (S)PVC.  Back then, all the (S)PVC people assure us
that it is not big deal since it is just a connection.  10 years from then,
we are still bearing the pain of provisioned connection-oriented (S)PVC.

IP is great since it is connectionless.  Telephone (POTS) is also great
since it is connection-oriented with fully functioned end-to-end subscriber
initiatied signaling.  Either one will work for us, but not something in
between.  Oh, well, I went too far.

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

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: Friday, November 22, 2002 12:24 PM
To: Chen, Weijing
Cc: 'Yakov Rekhter'; 'PPVPN'
Subject: Re: Scalable and manageable network management and operation of
MPLS/VPN

Weijing,

Your below email clearly indicates that you are mixing VR based L3VPNs
with the L3VPNs described in 2547bis architecture as non of your points
apply to the latter one. I must admit that they are very true for the
first type of L3VPNs though :-).

Thx,
R.

> 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.
> 
> 
> 
>      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.
>    #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.
>    #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 new one if 
>      not shared is another daunting task.
> 
> 
> 
>      Each single item above is translated into $$, which including
recurring OPEX for operation and OSS system 
> maintenance, and nonrecurring CAPEX for OSS system.
> 
> 
> 
>    >>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:40:36 -0500

>Yetik,
>
>Not "doing nothing", but "doing manageable thing".

         I think you need to define what "doing manageable thing"
means exactly before analyzing the technology. Once you have a
good set of parameters, then look at the technology and how it can
be managed to see if it meets your goals/requirements.  I think
that looking at the technology and then saying that it doesn't
work like what you have today (which you claim below is not
scalable to large numbers) and therefore is not scalable,
is not the way to go.

>What I am trying to
>number.

         What are you doing now?

>Sure if the number of subscribers does not go up, we will be fine.

         Well, if you are thinking of making money from this or any
other new service, I hope you would like for the number of
subscribers to increase . And in the least, to the point where you
have at least the same number of subscribers as you have with your
old service.

>Hay, in that case, even CLI may work.

         Why is that relevant?  I didn't think that we were
comparing management interfaces.

         --Tom

>-

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