RE: draft-bonica-tunneltrace-02

[neil.2.harrison@bt.com]

Kireeti,

My vote is (b).

Rationale:

-	a trail-tracing function is one diagnostic tool which is 'desirable'
to help operations people verify routing......it is not the only 'desirable'
diagnostic tool required.  Moreover, it is not a defect detection/handling
tool, which is an 'essential' function IMO.  I hardly think it appropriate
that in all the cases we want to use IP/MPLS technologies to expect the
customer to act as the defect detection mechanism.  I see this as
particularly ironic and inconsistent given that in the GMPLS work it is
taken for granted that the defect detection/handling mechanisms relevant to
the traffic/data-plane of a L1 layer network (eg SDH) must indeed be
present....such as correct framing, BIP-X violations, trail-trace
violations, FDI to suppress higher client layer alarms, etc.  See also next
item.

-	I noted this comment from yourself:
>    My input on this (as WG chair) is that CCAMP is all about tunnels,
>    and a protocol to debug and test tunnels is well within scope, even
>    if not called out explicitly.
I have no problems with this statement per se.  However, a tunnel to me is a
server layer network relationship to a client layer network.  This can have
very many possible combinations, but some are more logical than others, eg
IPoverMPLS seems more logical than MPLSoverIP....others may disagree, but it
illustrates my point that 'tunnels' are not bounded by the example
client/server relationships given in the current draft.  In another part of
CCAMPs we see GMPLS being discussed.  Here we can have (for example) IP
served by SDH, eg IP may be using a VC-4 'tunnel'.....or LSP.....or whatever
you want to call it, architecturally its a VC-4 trail provided by a VC-4
layer network as defined in G.805, and it can act as a server layer trail
(tunnel) to many different client layer types besides IP.  I therefore find
it somewhat inconsistent:
	* to selectively choose only certain technologies and client/server
relationships when there is the above plea for generality wrt GTTP;
	* that CCAMPs is prepared to accept the need L1 traffic/data-plane
defect detection/handling tools in GMPLS work and yet refuse to accept that
the *defect detection/handling principles* applied at those layered networks
should also apply at other layer networks.

IMO we should have some consistent principles here across all layer
networks.  In terms of OAM functions this has been attempted in Y.1710
(principles/requirements)...and although aimed at MPLS in this case, if you
read them you will note that they are largely generic and apply to any layer
network to try and bring consistency of approach rather than ad hoc
expediency.

Hope that makes sense.

regards, Neil