The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <0536FC9B908BEC4597EE721BE6A3538904EF3487@i2km07-ukbr.domain1.system
host.net>, neil.2.harrison@bt.com writes:
> > 
> > > > > What about existing implementations and deployments of the soft
> > > > > preemption draft?
> > > >
> > > > What about them Ina?
> > >
> > > Do you plan to document them in your draft as well?
> > 
> > Well, no, not really. I haven't documented any other 
> > experimental implementations or
> > deployments either.
> > 
> > What is your issue/question?
> > 
> > Adrian
> 
> Adrian, 
> 
> A few observations:
> 
> 1	What makes folks think all operators want pre-emption at all in any for
> m?  We tried this stuff many years ago and we would never use it again (note 
> that I am making a distinction here between 'dumping' extra traffic to effect
>  restoration of higher priority traffic, and trying to effect pre-emption acr
> oss some multiple set of priority classes....the latter is what does not work
> ).  I don't want to get into the detail, but the essence of the problem is th
> at it is generally not a sensible idea to try and aim for BW squeezing optimi
> sations in highly loaded networks.....and if they are not highly loaded (like
>  over 99% of operational life between planning cycles) its a non-issue anyway
> .  The real challenge is how to deliver consistent/meaningful services over a
>  large range of loading points.....this leads into a discussion of the illusi
> on of QoS, but that is another (related) story.
> Note - this does not just apply here, but to any technologies that purport to
>  do BW squeezing optimisations....esp if they also break func arch requiremen
> ts in doing so.  BW squeezing is not a priority for operators (well us anyway
> ), getting rid of complexity and the capex/opex costs that are associated wit
> h this is (and this seems to be on the increase)
> 
> 2	The co-cs mode layer networks (eg SDH, OTNs) are a completely different
>  beast to the co-ps mode layer networks (eg MPLS, FR, ATM), which in turn are
>  a completely different beast to the cl-ps mode networks (eg IP, ethernet....
> and these 2 are also quite different).  The differences arise from applying c
> onstraints (ie adding functional components like signalling, etc) to the most
>  basic of all network modes which is 'broadcast at source, filter at sink' (w
> hich is what ethernet uses).  We add these constraints to make simplification
> s that allow benefits wrt scaling/design/operation/etc.  The last thing folks
>  should do is try and somehow 'crunch' these modes together and regard them a
> s 'the same'.....they are not the same (just a fact), they require different 
> treatments and a 'full-service' operator like BT for sure needs them all.
> 
> So...as a suggestion/plea.....do not assume what works/applies for IP works/a
> pplies for MPLS works/applies for GMPLS......and this is more general than th
> e pre-emption issue of course.  And remember this:  In func arch terms a link
> -connection in a client network is created by a trail in server layer network
> .....this is the essence of client layer topology creation, and it is a recur
> sive behaviour to the duct.  Two immediate points:
> -	the client and server layer networks may belong to different commercial
>  entities......and this should be the guiding arch rule *not* the exception. 
>  This requires independence of the client and server layer networks (or put a
> nother way, the client must be transparently carried over the server)....PWE3
>  stuff for example breaks this requirement.
> -	the holding times of trails generally need to increase as one approache
> s the duct.
> 
> 3	Finally.....I am not sure what was behind your origin probing Adrian bu
> t I read it like this:  If folks go implemenet something ahead of final/stabl
> e stds they do so 'at risk'.  IMO we should not be retrospectively writing st
> ds to match what some folks have done.  I can see the atraction/merits of exp
> erimentation but I can also see how it could be abused by dominant players...
> .not saying anyone would dream of doing this of course, I just see the possib
> ility/danger.
> 
> regards, Neil


Neil,

You bring up a good point regarding why do we need preemption at all.

For many networks everything is almost all IP over MPLS with a little
of something else over MPLS (L2VPN, whatever).  That something else
may be both important and intolerant of all but the smallest loss, and
in some cases intolerant of rerouting its traffic (discontinuity in
delay, possibly out of order delivery for a few msec).  You'd like
that traffic to stay put (ie: not reroute unless absolutely
necessary).  That and IP prec / MPLS-EXP is enough QoS for most
anyone.

Another class of traffic is SLA traffic which is moderately tolerant
of loss.  It is more tolerant of loss than VOIP for example, however
loss beyond some threshhold may exceed service guarentees and require
customer reimbursement.  For that a solution being considered by some
and used by some is standby tunnels or standby LSP.  That is
presignaled fully disjoint LSPs that can be switched to quickly.
Recovery using standby works best if the standby are also traffic
enginnered.  One way to traffic engineer this is to put the primaries
on one hold-pri and put the standby on a numericly higher hold-pri.
Primaries can the be routed independently of the standbys.  The
standby are traffic engineered within the remaining bandwidth.

In the event of a falure, primary LSPs will be rerouted and you'd like
them to be able to preempt standby LSPs, but in a way that does not
take down any standby that is currently in use.  The soft preemption
accomplishes that.

Other people may have other reasons for wanting soft-preempt.  This is
only one of them.  It obviously doesn't apply to FSC, LSC, or TDM LSPs
but it can be applies to anything that is PSC.

Curtis