RE: draft-bonica-tunneltrace-02

[neil.2.harrison@bt.com]

> > NH=> Asking ICMP to proxy for missing defect handling in MPLS is a
> > possibility....and as George hints in an earlier mail is 
> actually an example
> > of a layer violation, but so be it.  However, this should 
> not be used in
> > XoverMPLS....you need a solution here that is 
> self-contained within the MPLS
> > network.
> 
> Have we found the crux of the matter?  MPLS as defined by the IETF
> (and I personally don't believe any other body has jurisdiction over
> the core MPLS technology) requires that all boxes be IP capable.
> 
> ...George

NH=> Yes I think you have hit on the key point here George.....but you need
to be clear which *plane* you are referring to.  To do what is being
suggested (implicitly by your comment) requires an IP capable transfer-mode
network that is decoupled from the other layer network that it is proxying
defect handling for.   In other words, the IP network is acting as though
its some form of (i) higher layer client application/test-probe in the
traffic-plane and (ii) management-plane gatherer of information.  Several
points flow from this:

-	its a well known fact to us in telco world that the data-planes of
the traffic, control and management planes are not necessarily
congruent.....indeed for CO networks there are many advantages in not having
them congruent and in some cases this is clearly forced, eg OTNs.  A key
point of this observation is that the topology/design of the control (or
management) data-planes must only take its survivability cues from the duct
layer.  So even if one is using an IP-based encapsulation/transfer mode in
the user-plane of the control or management networks here, one may not be
doing so in the traffic-plane (this also has implications for 'addressing'
of the data-plane access points of the networks that constitute these
different planes).

-	if I build on the above and consider SDH/OTNs in general (we can
collectively call these GMPLS if it helps), the traffic-plane here is a
cct-sw 'quantised BW' entity.....clearly this has nothing to do with IP at
all (it may ultimately carry an IP-based pkt stream, or indeed anything
else, but that is irrelevant).  You might use an IP delivered set of
protocols in the management or control planes for such networks.....but
these lie in a different data-plane network as I noted above.

-	if one agrees with the above (and I can't see how anyone could not
since its obvious), then it follows that this logic can be applied to any CO
layer network.....MPLS is therefore but one example that I can add to FR,
ATM, SDH, OTNs, etc.  Ergo GMPLS....in principle, if not in embodiment.

-	and to reinforce the point.....the fact that MPLS creates new CO
trail entities (that can carry clients other than IP) means these will have
failure modes that are not relevant to any other layer network (inc IP), and
need decoupling from any specific client or server layer technologies.  This
is just a fact......you can disagree with it if you like (and I am sure many
will) but I can't alter the truth of this observation (hopefully such a
truth is a bit more obvious for an OTN in the context of 'GMPLS' for anyone
still struggling to grasp this).

Trying to pretend MPLS is not a layer network which creates CO trails (when
ER/signalled at least) does not help anyone long-term....esp if one is also
prepared to accept what is happening in GMPLS, as such a stance would be a
logical contradiction.  IMO its time we faced this fact and stopped skirting
the issue.

BTW - I would be careful saying that no other body should have jurisdiction
over MPLS as:
(i) I can't equate this remark with what I see happening to SDH and OTN wrt
GMPLS in IETF;
(ii) there are other bodies out there like ITU, ATMF, MPLSF, IEEE who will
need to have some say wrt MPLS development (ditto GMPLS....or put another
way SDH/OTNs/etc and the interfacing/control/management of such);
(iii) it assumes that IETF are eventually going to provide some
carrier-strength defect detection/handling functions for MPLS, but given
what I have seen over the last year this seems very unlikely to materialise.


regards, Neil