Subject: RE: [PWE3] draft-roth-pwe3-fc-encap-00.txt

From: [email-masked]
Date: Mon, 25 Jul 2005 19:19:35 +0100

Ben,

> Stewart et al,
> 
> > SB> I think that you should consider writing an applicability
> > section I
> > SB> would imagine that FC has quite stringent requirements on delay
> > SB> misordering latency etc. Would you consider it suitable 
> > for ruuning
> > SB> over the pblic Internet?
> 
> I don't think it should be 'considered', according the old and the new
> charter it is mandatory:
> 
> Old charter: "Applicability statements for each service will describe
> expected shortfalls of the emulation's faithfulness."
> 
> New charter: "All emulated service definitions must include an
> applicability statement describing the faithfulness of the emulation."
> 
> Ben
NH=> I agree.  But you/I know there is a server->client performance
inheritance issue here that has not been addressed to date, largely
because this was not something we needed to worry about.  That is, when
the link connections in your layer network are provided by trails in a
co-cs or co-ps_CBR server layer network then this issue is not
significant.  However, if this is not the case then one cannot assume it
is no longer not significant.

Further, not only are there no rules on what client/server relationships
can exist between the (3) modes but there are no rules on how many such
client/server transitions could be encountered.  {Aside=> I've some
ideas on how to model this (which I've fed in R&D work here in BT) but
it looks complex to me (understatement)....and of course performance
(inheritance) is now load sensitive (in all lower layer networks which
are not co-cs or co-ps_CBR)}.

So, in order to fulfil what appears to be (correctly) stated in the
charter then some good network models will be required with both end-end
objectives (for some set of NP metrics) and these need to be broken back
to smaller partition impairment allowances, ie operators need to know
what NP they are required to meet (because ultimately this comes down to
some measurements), and customers will also want to know what they are
getting in SLAs.

After all, if we cannot quantify this stuff then how can we
measure/control/apportion it in any meaningful and fair way? 

Should be an interesting exercise...especially noting that to even get
on NP page there are several things that must precede it, ie what I call
'an order of processing', viz:
-	the mode defines the defects that are relevant and required OAM
-	the defects need to be quantified wrt entry/exit criteria and
consequent actions
-	defect persistency sets availability entry/exit criteria and
consequent actions....one of which is..
-	NP aggregation (for SLA purposes) in only valid in the up-state
(ie available time)

regards, Neil

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