RE: draft-bonica-tunneltrace-02

[John Drake <jdrake@calient.net>]

Neil,

I asked a simple question and expected a simple answer.  Instead, you send
this example of incoherence raised to an arm form.  

Since you raised the specter of GMPLS, did you consider that we could just
as easily take the fault detection/isolation procedures of GMPLS and
re-apply them to MPLS? 

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
> 
> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Tuesday, March 05, 2002 11:32 AM
> To: erosen@cisco.com
> Cc: ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> Eric...can you please explain how GMPLS fits against this 
> statement please?
> 
> regards, Neil
> 
> > -----Original Message-----
> > From: Eric Rosen [mailto:erosen@cisco.com]
> > Sent: 05 March 2002 14:52
> > To: Shahram Davari
> > Cc: 'Thomas D. Nadeau'; ccamp@ops.ietf.org
> > Subject: Re: draft-bonica-tunneltrace-02 
> > 
> > 
> > 
> > Shahram> What is  the difference between ATM,  FR, or any  CO 
> > technology and
> > Shahram> MPLS 
> > 
> > Well, for  one thing, MPLS  isn't a CO  technology.  It's got 
> > lots  of stuff
> > that doesn't really  make sense from a CO perspective.   Of 
> > course, when the
> > CO  guys  run  across  these  features  (multipoint-to-point, 
> >  php,  liberal
> > retention, independent  mode, equal  cost load balancing,  
> > dynamic rerouting
> > with no signaling,  ttl, lack of packet sequencing,  IP 
> > control plane, etc.,
> > etc.) they assume that those features are there by mistake!
> > 
> > This misconception  that MPLS  is a CO  technology, shared  
> > as it is  by the
> > "pure  IP" crowd and  by the  ITU/ATM crowd,  is the  source 
> > of  much wasted
> > time.  
> > 
> > MPLS is  actually an IP-derived technology that  facilitates 
> > the application
> > of  certain   circuit-like  characteristics  to  IP  
> > networks.    As  an  IP
> > technology,  the usual  IP diagnostic  tools, such  as ping  
> > and traceroute,
> > should be applicable.   That's what this whole useless  
> > discussion is about.
> > One  the one  side are  people  who think  that IP  networks 
> > are  inherently
> > unmanageable (after all, they don't  follow ITU standards), 
> > and on the other
> > side are people who think that the IP-based paradigms are the best. 
> > 
> > It is true that  MPLS can be used to provide something  which 
> > is very like a
> > CO network,  but it  doesn't have to  be used  this way, and  
> > usually isn't.
> > Those of use  who are not particularly interested in  CO 
> > networks just don't
> > want to be saddled with the  legacy CO mechanisms.  
> > Presumably, if all these
> > legacy CO mechanisms were  so great there would not be such  
> > a great rush to
> > IP. 
> > 
> > 
> > 
> > 
> > 
>