RE: draft-bonica-tunneltrace-02

[neil.2.harrison@bt.com]

Randy,

Please see below.  Regards, Neil
 
> >>  - Define signalling protocols and measurement protocols 
> such that they
> >>    support multiple physical path and tunnel technologies
> > 2) Does OAM, that measure availability, also fall under 
> this definition? 
> 
> does OAM work on GRE?  IPsec?  if not, guess it's not Common, eh?
NH=> The thing that is *common* here is the function.  There are common
network problems that need solving for *any* cnls protocol and *any* co
protocol....and in the latter case there are some minor differences whether
the user-plane trail is cct or pkt based.  So OAM *is* a common
requirement....as is an ability to measure availability and QoS, since these
define the (server) SLAs for whatever the client payload of the layer
network in question is (which, dare I say it, is often another layer
network).  One thing that is *not* a common function however across all
layer networks is trail-trace as a per node 'request/response'
mechanism....at least as done in the user-plane (since to work
correctly/reliably one has to make certain assumptions about the behaviour
of the network, ie usually simply that it is defect-free....and in which
case one can simply ask the control-plane).  Another thing that is not
common in most layer networks is built-in layer violations, ie using the OAM
mechanisms of layer network X to proxy for missing OAM functions in layer
network Y....and there are very good reasons to avoid layer violations.

However, to have *common* availability and QoS SLAs, you needs to use a
*common* approach......which for any co technology goes like this:
-	1st identify all defect types
-	2nd define their entry/exit criteria and consequent actions....some
of which can be really quite important, like client layer alarms suppression
on lower layer failure, or supressing traffic (to protect customer
information integrity) if a misconfiguration failure occurs
-	3rd define available/unavailable trail state entry/exit criteria
based on defect state persitencies
-	4th you can now begin to define QoS and availability SLAs.  Note
carefully that although these are disjoint, the QoS metrics must only be
measured when the trail is in the available state since their SLA objectives
are only valid then......very obvious why I think.

So it's not a technology specific OAM embodiment that is common across all
layer networks (and in fact this would be a layer violation by direct
inference if it was) but the *function* that is common....and its embodiment
is layer/technology specific.