The MPLS WG Archive

[neil.2.harrison@bt.com]

> 
> > > > 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 form?  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 across 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 that it is generally not a sensible idea to try and aim for BW squeezing optimisations 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 illusion 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 requirements 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 with 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 constraints (ie adding functional components like signalling, etc) to the most basic of all network modes which is 'broadcast at source, filter at sink' (which is what ethernet uses).  We add these constraints to make simplifications 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 as '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/applies for MPLS works/applies for GMPLS......and this is more general than the 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 recursive 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 another 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 approaches the duct.

3	Finally.....I am not sure what was behind your origin probing Adrian but I read it like this:  If folks go implemenet something ahead of final/stable stds they do so 'at risk'.  IMO we should not be retrospectively writing stds to match what some folks have done.  I can see the atraction/merits of experimentation 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 possibility/danger.

regards, Neil