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

From: "Serbest, Yetik" <[email-masked]>
Date: Fri, 22 Nov 2002 14:29:10 -0600

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: "Naidu, Venkata" <[email-masked]>
Date: Sat, 23 Nov 2002 14:21:33 -0500

->  > One of the advantages to MPLS L3VPN is that it
->  > can be managed as part of your overall MPLS management strategy
->  > given that it is an extension of MPLS. 
-> 
-> in case the provider has no other use for mpls than vpns, then the
-> provider needs to start managing mpls in addtion to managing 
-> ip, which clearly is an additional burden.
 
  It is just a trade-off and amortized optimization providers has
  to make. If "managing MPLS/VPNs" overweighs "advantages provider
  gets by using MPLS/VPNs over IP/VPNs" then provider may prefer to 
  go for IP/VPNs instead of MPLS/VPNs. If provider calculations show
  that "advantages" overweighs "managing" MPLS/VPNs then, MPLS/VPNs
  are far better.

  More over, providers consider "extensibility" along with "scalability".
  At this point in timeline, a provider might use MPLS only for VPNs. But
  what if in future provider gets more benefits from MPLS (other than
  just VPNs)?!? - there are already other benefits, ofcourse.

--
Venkata.

---

From: "Serbest, Yetik" <[email-masked]>
Date: Sun, 24 Nov 2002 21:27:01 -0600

Brijesh,

Complaining about scalable management application is one thing, complaining
about scalability of RFC2547 is another. Weijing is confusing these two.
RFC2547 is more complex service than point-point connectivity services which
most people are used to. It does not mean that it is not scalable. It means
you have to do more work to provide that service. 

thanks,
yetik

-----Original Message-----
From: Brijesh Kumar [mailto:[email-masked]]
Sent: Saturday, November 23, 2002 3:42 PM
To: Chris Chase; Chen, Weijing
Cc: 'PPVPN'
Subject: Re: Scalable and manageable network management and operation of
M PLS/VPN

Chris,

I guess, it was your conclusion that Yakov quoted  as 2547 BGP/MPLS VPNs
being "Certainly scalable and solvable.".  I am not doubting that assertion,
but I would like to know a bit more. I am wondering what is the scale, we
are talking about here? 100s of VPNs, 1000s of VPNs per PE?.  How many sites
per VPNs? in tens or hundreds?

There is yet another issue on which I would like to seek an answer from
people like you who seem to have operational experience with configuring and
managing Layer 3 VPNs in live networks.

There are two aspects to VPN service scalability - the router engineering
aspect, and the operational aspect. The first aspect does not look like an
issue  as the current generation of equipment is designed (or claimed) to
facilitate carriers to provision several thousand Layer 3 VPNs (regardless
of the VPN model used), if not tens of thousand VPNs like existing Layer 2
technology. I don't know if any one can guarantee that with their equipment,
a carrier can support a few thousand VPNs with  a few hundred sites per VPN,
but most can do a few thousand VPNs with moderate number of sites (<20). I
would like to know if any one is running Layer 3 VPNs that have sites in
three digits.

If I understood  Wienjing's mail correctly, he seems to be pointing to the
lack of operational scalability i.e., the lack of suitable VPN management
and configuration tools that allow operators to manage a large number of
layer 3 VPNs, taking a network wide view (as opposed to a point-by-point, PE
oriented view). Do you believe that current generation of operation support
software provided by your vendor X is good enough for operators to run
large networks with thousands of VPNs with some VPNs having hundreds and
possibly a few thousand of sites?

Cheers,

--brijesh

----- Original Message -----
From: "Chris Chase" <[email-masked]>
To: "Chen, Weijing" <[email-masked]>
Cc: <[email-masked]>; "'PPVPN'" <[email-masked]>
Sent: Saturday, November 23, 2002 7:18 AM
Subject: Re: Scalable and manageable network management and operation of M
PLS/VPN

> I don't normally follow this mailing list, but an associate pointed me
> to this thread.  Sorry to jump in the middle.
>
> Inline.
>
> Chen, Weijing wrote:
>
> >Robert,
> >
> You are equating resources with cost and I assume you are saying that
> "pain" for VC service is in terms of costs.  So what are you concluding
> here about PVC service?  Has it been a pain for SBC?  SBC has the
> largest U.S. FR market share of the ILECs (although much smaller than
> the IXCs), but approaching 1/3 billion (market analyst reports for
> 2001).  Are you saying it is so much of a pain (in terms of costs) that
> SBC can not make money with it?  I know that for AT&T and most other
> carriers PVC service is very profitable.  I suspect the same is true for
> SBC - you may want to talk to your SBC associates that deliver those
> services.
>
> Certainly there are complexities and resource consumption with creating
> these network based VPN services, whether Layer 2 or Layer 3.  But is
> that not the value add we as carriers bring to the equation?  We provide
> the value add of these services for enterprise WAN service while making
> money because we do this at scale.  Otherwise, you would not being
> seeing enterprise WANs migrating off private lines nor carriers
> reporting profitable business data services.
>
> Carriers have found how to scale the network based layer 2 services to
> tremendous sizes and be very efficient with running these services. We
> believe we can do (and are doing) the same with the nascent Layer 3 (IP)
> network based VPNs.
>
> Layer 3 network based VPNs are connectionless IP from the enterprise WAN
> user view.  Layer 2 network based VPN are connection oriented and proven
> from the enterprise WAN user view.   When you say these services (by
> implication the "something in between") will not work for "us", who is
> "us" - the SBC point of view or the corporate enterprise WAN view?
>
> Chris Chase
> AT&T Labs Research
>
> >
> >--
> >Weijing Chen
> >SBC Technology Resources
> >9505 Arboretum Blvd.
> >Austin, TX 78759
> >512 372 5710
> >[email-masked]
> >
> >