RE: [IP-Optical] RE: Three GMPLS related IDs

[neil.2.harrison@bt.com]

Hi Zhi, you noted 15 March 2001 20:14
<snipped>
> If we extend Kireeti's voting weight, I would think an 
> operator's input
> would have more weight than other's inputs.
NH=> I think this depends on the issue.  For *networking aspects* (eg
addressing, OAM, performance metrics/objectives/apportionments, etc), and
certainly wrt to determining requirements, then operators should take a
strong interest.  However, I suspect the effects of cost-cutting might be
preventing as much carrier involvement as one would like/expect.  If the
issue is largely *implementational* then I think the vendor's views should
carry more weight.
> 
> > Thinking about the further concerns a carrier would have to 
> address in a
> > connection oriented switched-network, there needs to be a 
> consideration of
> > blocking probability and users having connection requests 
> refused, ie a GoS
> > metric. The result is that transport networks currently 
> designed around high
> > utilisation with long-holding connections need to be 
> redesigned around
> > ensuring a large enough pool of free capacity.  So, in 
> addition to having to
> > address the above issues up-front with SVC-like services, 
> carriers would
> > also be forced to define a 'erlang/pricing model' for 
> something akin to a
> > Gbit PSTN!  Depending upon the number of circuits and the 
> distribution of
> > traffic holding times it may not be possible to apply 
> simply erlang theory
> > as is, but rather some modifications will be 
> required.....and the demand
> > model will obviously be an interdependent function of the 
> pricing model.
> >
> 
> Yes. Simple availability metric does not fit the switched model very
> well.
NH=> True if holding time is not long compared to failure frequency.
However, one would expect the holding times to increase as one approaches
the duct layer.....but if this is not the case, then the operators had
better make sure they have paid enough attention to the demand/pricing
models and that these make ecomonic sense.

> Since availability measurements are obtained through time
> integration of errors, with short connection duration, this metric may
> not be appropriate in its current form. For example, if a connection
> lasts for one day, and during that time 1 or 2 bit error occur.
> Depending on the level of availability offered, this may result in
> non-compliance.
NH=> I see a distinction between availability and QoS.  I would not consider
a few bit errors (for example) to impact an availability metric/objective.
Further, I would strongly recommend *not* to incorporate normal up-state QoS
metrics (eg errors/delay) into some OR'd availability criteria.....it can
get very complex (and costly) to measure....and it is probably not worth it.
It is better IMO (for a well-engineered/designed network) to rely primarily
on defect indications to determine availability entry/exit criteria.  Have
read of our recent draft on MPLS OAM.....some rationale is given in there.
> 
> Parameters that have been used in traditional PSTN networks need to be
> re-examined and modified to fit the new switched network. 
> These include
> those you've mentioned, such as connect attempts, hold times, blocking
> probability,  erlang traffic model (which already takes hold 
> times into
> consideration)
NH=> I wonder how many other operators have actually given much thought to
this yet?  It certainly concerns many of us in BT at least.
> 
> > 6       Noted the point in para 4.2 regarding ENE 'having 
> to maintain
> > source/sink LSP inventory', but the SNE also needs to maintain its
> > server->client layer adaptation mappings....so that on 
> failure the correct
> > FDI information can be sent forward into all affected 
> clients (and this
> > process should recurse for clients of those clients, etc).
> >
> 
> Yes. Each NE would still provide the capabilities inherent in an NE,
> i.e., adaptation mappings, detection/generation/suppression of various
> defects/alarms. Because these are user plane functions, we did not
> include discussion of this. 
> 
> Do you think it would be worthwhile to have a sentence to describe the
> user plane functions?
NH=> You could do...but how much would one write?  Maybe some references to
where such material is specified might suffice.
>  
<snip>
> I agree with the observation that highest bandwidth does not 
> necessarily
> mean highest priority.  Highest bandwidth might be the least critical
> application, e.g., file transfer (low priority) vs. voice (high
> priority), the bandwidth needs might be reversed.
NH=> 2 things:
-	1st, an application's forwarding QoS requirements have no
relationship to its survivability needs.  So whilst voice might be mission
critical and data transfer not mission critical in one case, in another case
their requirements could be reversed......but in *both* cases they need the
same up-state forwarding treatment.  So, like-DS-class merging in an LSP
raises some availability issues at a per 'application level'.
-	2nd, how can we can rank restoration priority amongst LSPs?  For the
L-LSP case we potentially have the situation referred to above, ie merged
same DS class applications may not have the same survivability requirements.
In the E-LSP case the situation is even less clear for similar
considerations.
I also think there is a distinction in how one views the survivability needs
of a VPN and general public services, ie voice in a VPN might require
different survivability treatment to a general 'public voice' service.  I
therefore have a concern that some issues relating to availability/QoS have
currently not be thought through.......possibly because the emphasis to date
has been largely on QoS.  
> 
> We will add this discussion in the next revision. BTW, when you state
> "an ability to select the priority of restoration post failure between
> different trails", do you mean that for all protected connections, the
> highest priority protected connection get protected first, second
> highest priority get protected second, etc. and that you want the
> flexibility to decide what criteria is used to rank the restoration?
NH=> In essence yes.  What we don't want is compounded bumping....or at
least the ability to turn it off.
> 
<snip>
> Yes, I agree. theses issues should be viewed independently.  As you
> mention, even within routing protocol, there would be differences in
> term of the relevant aspects/constraints for route determination.
> Whether these differences could be handled via different protocol or
> simply as different extensions need to be further discussed. For
> example, would the same algorithm be applicable to both SDH and OTN
> networks (most likely?)
> 
> Do you suggest we expand this section to include discussions of these
> points? We would be very happy to work with you on extending the
> concepts that you've described.
NH=> I think there needs to be further discussion.  And, perhaps more
importantly, I think operators need help to get a better grasp of what the
various extensions and redundancies will actually mean for
routing/signalling protocols.  For example, is building 1 parent protocol
with extensions/redundancies better (or worse) than tailoring the protocol
for a particular technology?  Noting that in the former case, then the whole
parent protocol seems as though it would need some re-work each time a new
technology/layer was introduced.
> 
<snip>
> > 11      In section 5.4.3.1 you describe the 4 main stages of
> > prot-sw/restoration.  I agree.  But please don't overlook 
> these facts that
> > are relevant to the first item of failure detection:
> > -       1st, we must identify all failure modes
> > -       2nd, we must describe their entry/exit criteria
> > -       3rd, we must take correct consequent actions, eg 
> FDI upwards to stop
> > alarm storms, BDI backward (if single ended visibility of 
> both directions
> > needed), squelch traffic if trail ID mismatch (important to 
> protect customer
> > traffic...so this is a sort of security consideration, but 
> it also impacts
> > billing etc)
> > -       4th, we need to know/define what constitutes up and 
> down states of
> > the trail.....this defines the 2 aspects of availability 
> SLA and the QoS
> > SLA, where the latter only has meaning once the former is 
> defined (ie only
> > valid in up-state) and will generally be based on the 
> defect handling
> > covered by points 1st-3rd above.
> > See our draft on MPLS OAM (packet level) where we cover the 
> above for an
> > example of what is required in the user-plane:
> > 
http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt We need a
> similar approach for the lower transport layers....and note that there
> should be some attempt at metric/objective harmonisation across the layers
> in order for any measurements/SLAs taken/applied at each layer to have
some
> cross-layer relative significance.
> 

Yes, these are very valid points. I believe for points 1-3 above, we can
provide a brief description and then refer to existing standards. For
point 4, we will need to extend the document. 

Would you happen to have some text available for us to include in the
next revision?
NH=> Not currently.