RE: draft-bonica-tunneltrace-02

[neil.2.harrison@bt.com]

Hi John...see below.

regards, Neil

> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: 07 March 2002 04:39
> To: 'neil.2.harrison@bt.com'; erosen@cisco.com
> Cc: ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> Neil,
> 
> I asked a simple question and expected a simple answer.  
> Instead, you send
> this example of incoherence raised to an arm form.
NH=> It's not incoherent to me and many others.  Not sure I would class it
as an 'art form' its just compelling logic to me.
> 
> Since you raised the specter of GMPLS, 
NH=> Interesting choice of word to describe GMPLS.....have you seen the
future? ;-)
> did you consider that 
> we could just
> as easily take the fault detection/isolation procedures of GMPLS and
> re-apply them to MPLS? 
NH=> But that's exactly what I said!  That is, it is the *principles* of
having defect detection/handling in the data-plane that is the thing that is
invariant/common, not the 1 size fits all *specific* mechanism which is
attempted to be force-fed to all layers.  And 2 of the most
important/fundamantal principles here are:
-	decoupled from any client/server technologies (ie the layer
violation issue....absolutely critical for data-plane protocol evolation)
-	decoupled from any control or management plane protocols (or indeed
the data plane on which these protocols run....since in many cct-sw/co
technologies this is *not* congruent topologically (and certainly not
functionally) with the data-plane of the traffic).  Again absolutely
critical for protocol evolution (all planes).
The rest then follows as I explained.

So...to re-interate the key message.....the thing that is *common* are the
principles, the actual mechanism has variations dependent on transfer mode
(ie cnls vs co) and (for co) whether cct-sw or pkt sw.  If you are stuggling
still to grasp the point I am making think about the control-plane and the
GMPLS example you mention.  The basic (network) function is
'find/route/connect' and this applies to all network layers (OAM addresses
the 'maintain' part of these basic functions that also applies to all layer
networks).  So we need addressing/routing (applies to both cnls/co) and
signalling (for co) facets for all layer networks.  The actual choice of
addressing, routing protocol and signalling protocol is purely a matter of
'fit for purpose', there are lots of options and there will be ongoing
development in each.  So the only thing that is enduring is the
'find/route/connect' principle and the functions they cover, not some
specific protocol embodiment that is current today.  Now if you are asking
me whether the actual protocols chosen for deploying a control-plane for
SDH/OTN are 'fit for purpose' that is a different question that raises both
(i) commercial and (ii) technical issues that need careful
consideration.....and I don't want to get into that one here.  

> Thanks,
> 
> John
> 
> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Tuesday, March 05, 2002 4:08 PM
> To: John Drake; erosen@cisco.com
> Cc: ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> No problem John......really glad you asked this question as 
> the answer is
> dead easy:
> 
> The simple/one-liner answer is to ask you to read 
> Y.1710.....I wrote this
> after a conversation Maartin Vissers and I had a few years 
> ago (on a bus in
> Turin or somewhere) where we effectively said:
> -	the network problems are effectively the same 
> irrespective of the
> technology, ie find/route/connect/maintain
> -	there are some differences dependent on transfer mode, 
> ie cnls is
> different to co, and in co there are some differnces wrt to cct-sw vs
> pkt-sw....but in essence, the 'network' problems are invariant
> -	and focusssing in the OAM aspects one can lay down some 
> principles
> that are largely technology independent and quite 
> generic....ergo Y.1710.
> 
> However, assuming one has never read Y.1710 the arguments follow this
> general reasoning:
> 
> -	1st define the defects specific to the layer 
> network/technology of
> interest....now clearly these are different in specifics 
> whether one is
> considering an OTN trail, a SDH VC-4 trail, an ATM VP trails 
> or an MPLS LSP
> trail (etc)........but they all clearly embrace:
> 	* simple breaks within/below the layer of interest
> 	* swapped/misconfigured trails
> 	* mismerged trails (these can only happen with co pkt 
> modes *and*
> relative addressing, ie labels....cnls pkts use *absolute* 
> addressing, ie
> each pkt carries a trail-trace by definition (ie source 
> address), which is a
> generic requirement as noted below and so complies).
> 
> -	2nd, since we know the data-plane trails carrying the 
> *traffic* can
> be totally decoupled from the data-plane trails carrying control
> (signalling/routing) or management plane protocols then each 
> data-plane must
> have its own defect detection/handling mechanisms which are (i) not
> dependent on any other specific client/server layer networks 
> (essential for
> technology compatibility/evolution....aka layer violations) 
> and (ii) not
> dependent on any specific control/mananagent-plane protocols (or their
> data-plane), inc none, for similar reasons....very obvious in 
> cct-sw/GMPLS
> applications IMO;
> 
> -	3rd, given above, its obvious that the data-plane (be 
> it carrying
> traffic/control/management protocols, which can be in 
> orthogonal data-plane
> network embodiments  please note) must carry its own OAM
> mechanisms.....again, very obvious in the case of cct-sw (esp 
> OTN), but same
> applies to pkt-sw.  Not so true in case of cnls.....where one can ask
> certain (higher level) control (say) plane protocols to proxy 
> for data-plane
> OAM.  The generic solution is here it to send some 
> 'trail-trace' identifier
> periodically source/sink......this is exactly what is done in 
> SDH VCs for
> example, and same should be done in pkt networks, ie same 
> generic principle.
> And as I noted above, cnls protocols like IP carry a trail-trace (ie
> absolute source address) in each/every pkt since the 
> addressing is absolute
> not relative (assuming globally unique addressing of 
> course).....so IP also
> fits the model for this aspect.
> 
> 
> -	4th, then define the entry/exit criteria for each defect inc the
> consequent actions one needs for each....some obvious ones being:
> 	* let's not have multiple client layer alarm storms 
> above the level
> of the defect (esp since these can be geograhically/organisationally
> disperse)...so we need some form of FDI (Forward Defect 
> Indication) for
> this.  So again this is a generic function, aka AIS in SDH/OTN.
> 	* some local alarm is needed....again pretty generic.
> 	* its useful to tell the source of far end failures in 
> some cases
> (ie single-ended both-direction monitoring of 
> QoS/availability SLAs say, or
> N:M prot-sw).....so this requires a generic BDI (Backward 
> Derect Indication)
> of some kind that mirrors the FDI.
> 	* with swapped/mismerged connections traffic 
> suppression is in order
> to protect the customer information integrity....again quite generic.
> 
> -	5th, in CO networks (be they pkt or cct-sw) 
> availabililty is the key
> perf metric.  So we can define this based on defect 
> persistence.  QoS metric
> measurements only makes sense when in the 'available' 
> state.....so if you
> want to offer/measure availability/QoS SLAs you need to pay 
> attention to
> this point.
> BTW - In Y.1711 I have drawn out the near-end/far-end 
> processing for LSPs
> wrt availability state to help people since this is the hard 
> bit.....though
> the actual protocol is trivial, ie its only 1 
> keepalive/trail-trace (CV) pkt
> in the up-state, and 2 pkts (FDI/BDI) in the down-state.  I 
> simply don't
> know where those who scream 'too complex' against this get it 
> from....I
> suspect they have never read and/or understood it.
> 
> So John, to return to your question.  SDH and OTNs frame 
> structures have the
> above concepts defined in them you will find and embody the 
> principles I
> outlined....all I have done is do the same for MPLS.  It's 
> got zero to do
> with any control-plane (or management-plane) protocols for 
> very obvious (esp
> here) reasons.
> 
> In summary, I would say what we have proposed for MPLS OAM is 
> actually very
> generic and not technology specific.....and so IMO is actually more
> in-keeping with the spirit of CCAMPs as a title (ie 
> 'common').  However, I
> can't take GTTP and say I can apply it to GMPLS......since its the
> *principles* that are enduring, not trying to force one 
> specific technology
> embodiment to fit all layers.
> 
> And that's about it....Neil
> 
> 
> > -----Original Message-----
> > From: John Drake [mailto:jdrake@calient.net]
> > Sent: 05 March 2002 19:40
> > To: 'neil.2.harrison@bt.com'; erosen@cisco.com
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: draft-bonica-tunneltrace-02 
> > 
> > 
> > Neil,
> > 
> > As a related question, would you please explain how your OAM 
> > proposal fits
> > against GMPLS?
> > 
> > Thanks,
> > 
> > John
<snipped>