Subject: RE: [PWE3] Draft Charter nits

From: [email-masked]
Date: Thu, 21 Jul 2005 12:41:48 +0100

Some observations.....

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yaakov Stein
> Sent: 21 July 2005 08:39
> To: pwe3
> Cc: [email-masked]; [email-masked]
> Subject: RE: [PWE3] Draft Charter nits
> 
> 
> 
>     It is not intended that an emulated service will be 
> indistinguishable 
>     from the service that is being emulated.  
> 
> I think a subjunctive form is required here:
> 
>     It is not intended for the emulated service to be 
> indistinguishable 
>     from the service being emulated. 

NH=> I am not at all happy with this.  Its a completely useless
statement as it cannot be quantified.

The word 'service' has significant implications to me as a network
operator....far more than intended here I suspect.  The most basic
requirement however is for the transparent carriage of all 3 planes of a
client across a (traffic data-plane entity) in the server.  If this is
not met then it fails at the 1st hurdle.  However, this is not
sufficient (this is the min client/server relationship requirement).

We should all know by now (?) that the topology of a given layer network
(ie its link connections) is created using trails of a server layer
network....and this relationship is recursive to the duct.  Now the
impairments of some layer network N are a sum (linear to a 1st approx)
of:
-	impairments introduced by the nodes in layer N
-	impairments *inherited* by the link connections in layer N from
the trails in layer N-1.
And of course, this is recursive to the duct.

Now, if we want to define a 'service' that uses the resources of layer N
we had better be pretty sure that we can quantify the behaviour of layer
N....be this in some apportioned HRX model or the subsequent need to
measure metrics against their apportioned objectives.  At the end of the
day operators will need to do this.

If we cannot do this then actually very little of real value can be said
about the goodness of a given layer network.....and this is of course
exactly what is said above, ie its effectively a useless
remark.....other then perhaps a vague warning to a user of this
'service' that its behaviour 'might not be very good'.....whatever that
means.

Aside - To date this has not been a significant practical problem
because it has been assumed (I suspect unconsciously by many) that the
server layer does not introduce significant impairments.....so we only
need concern ourselves with the layer N native impairments.  This is
indeed the case if the server layer is either co-cs or co-ps_CBR in
nature...and likewise to the duct.

So, we should always respect the client layer transparency requirement
and, if folks still want to carry on with the current direction, I'd
like to a see a health warning attached to any standards where the
server layer is not assumed to be either co-cs or co-ps_CBR to the
effect that:

'The service provided cannot have any strong performance guarantees
because we have no good way at present of quantifying the (inherited)
Network Performance metrics/objectives of the server layer, nor relating
these to the subjective QoS degradation that the client will
experience'.

The reason for the word 'subjective' here is to make it clear that a
GIVEN set of absolute Network Performance (NP) impairments can be
perceived very differently by different clients/applications.  However,
if one has no basis for defining/measuring the absolute NP metrics then
you can forget doing anything else.

And I perhaps ought to also add here there is a key 'ordering of
processing' issue folks should not overlook, ie
mode=>required_OAM=>defect_specification=>availability_specification=>NP
_specification.  In other words, you cannot get on the NP specification
page until all the preceding steps are defined.  And I find very little
evidence of this understanding/rigour being applied so far.

With the current cop-out statement these 'problems' are being passed to
operators to have to deal with....they will impact both
products/services folks and (perhaps more importantly when we think
about opex costs) the operations and NMS/OSS folks.  I see the problems
caused here in managing our existing network technologies which have
arch violations and/or flawed functional specifications and it really is
not good enough to be creating even more problems in these areas.

We could fix it.....but not unless/until we:
(i) decouple MPLS from IP (which is also a point both I and Yaakov have
made many times in the past....though I'd go further and say it needs to
look more like GMPLS)
(ii) have a form of MPLS that looks like co-ps_CBR (which again is the
GMPLS analogy wrt the co-cs mode)
(iii) can do a proper client/server case and
(iv) have sound/simple OAM *at the LSP level* like that specified in
Y.1711.

In such a scenario we don't need to create this completely unnecessary
'PW layer network' (and all the unnecessary problems it will
cause).....it stays as an adaptation, which is all it should be anyway
(and it could be simpler).  Further, LDP/PHP have no future (sorry
merging is a violation and it ultimately has to go), and DS as-is is of
little real value either......indeed chasing multiple QoS classes 'as a
means to an end' in a single network mode is a complete illusion of
something worthwhile as anyone who has looked at this topic with any
degree of seriousness/honesty ought to realise.  The 'importance'
semantic is now associated with the trail (LSP) entity as indeed it
should be.

regards, Neil

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3