The MPLS WG Archive

[Magatho Anthony Mello <Mello_M@mtn.co.za>]

I am interested in the response.  

Please copy me if you get or send any responses off-list.

-----Original Message-----
From: Florian-Daniel Otel [mailto:otel@ce.chalmers.se]
Sent: Wednesday, 06 September 2000 10:43 AM
To: Jeremy Lawrence
Cc: mpls@UU.NET; te-wg@UU.NET
Subject: Re: Incremental MPLS (BCP document lookup)





Jeremy,

First of all, thanks for the insight. Second, as I didn't get any
replies other than yours I will expand (below) the reason for my
questioning. 

> Florian,
>> I am looking for a case study document/white paper focused
>> on/describing the possible means (maybe even claimed advantages ?) of
>> introducing MPLS in a _incremental_ manner in a core network.

> What does the core network look like before MPLS is turned on?

Very plain and very simple: It is a transit network, small core size
(< 10 routers) , star-of-stars topology, IP over PPP/HDLC
connections. Two external links to higher tier ISPs and several
"customer" links. The network carries basically two diffent types of
traffic that have to be distributed. The two types of traffic source
from several locations, with some locations sourcing both types. The
way they are handling it right now is w/ BGP peering as the traffic
is mostly inter-AS bound.

The claimed advantage of using MPLS on this simplistic topology is
that the two types of traffic can be aggregated at different levels 
and the trunks handled independently. 


> If the core network is an IP router network then there is at least
> one router implementation where MPLS signalling (LDP or RSVP) can be
> enabled on a link-by-link basis in a live network (possibly after a
> software upgrade, which can be done node-by-node). The advantage
> of is largely that the network can still be forwarding IP traffic
> while the MPLS upgrade is going on. 

Giving the "if-it-works-don't-fix-it" attitude towards things of most
operators in order to make a successful "MPLS sales" job to the operator
one has to convince them that they can do it incrementally with
minimum fuss (this operator attidude is "we don't want increased or even 
_different_ complexity than the one we have now.."). That is why 
running RSVP or LDP won't do it. What I had in mind was that, at
least in initial stages, they should hook label distribution on
existing BGP peering and do independent LSP control. And after they
get confortable w/ it they can start doing fancier stuff like running
RSVP-TE/CR-LDP e.g to reserve resources (bandwidth) based on traffic
type, etc.

Anything wrong with this picture ? Ideas ?


All in all that is why I was looking for a document describing a way
to incrementally implement MPLS in a net and the claimed advantages...;)

> Regards,
> Jeremy


All the best,

Florian.


P.S: This might be more of an operational (TE) question than mpls so
if you consider it off-topic please reply off-list.