RE: draft-bonica-tunneltrace-02

[neil.2.harrison@bt.com]

> 
> I  understand that  you don't  think that  MPLS, viewed  as 
> an  IP tunneling
> protocol,  is worthwhile.
NH=> This sentence does not make sense Eric.  MPLS is a layer network (proof
by existence if you like), whether you would like it to be viewed as such or
not.  It may carry an IP client or it may not......that is irrelevant.  The
network object that we operators need to manage is the LSP.....inc those
instantiated without any control-plane assistance.  We are seeking
as-generic-as-possible a solution, whereas you appear to only a advocate a
restrictive solution.

   But that's  not the  question.  
> The  question is
> whether  a traceroute  tool that  works through  IP tunnels  
> (including MPLS
> tunnels)  is  worth  standardizing.
NH=> You argument does not compute Eric.  You are arguing for a generic tool
(any server technology) but that view clearly breaks once you consider
GMPLS....or more accurately SDH VCs or OTN trails.  GTTP does not compute
here as I hope you agree....however the *principles* of fault-managing the
data-plane trail do (any layer).....and it is these principles that are
truly generic, not the attempt to force some single mechanism across all
(technology) layers.
BTW - I know you find the concept of layered networks hard to swallow/accept
but I can't help you on that one.....you will just have to either accept it
or (we will all have to) live with the problem that you can't.

   This  question doesn't  
> seem  to  have
> anything to do  with CO networks.  Thus I don't  understand 
> why a discussion
> of  CO networking  is even  relevant to  the discussion  of  
> the tunneltrace
> requirements. 
NH=> This is an example of what I mean with us having to live your problem.
> 
> Dave> I  would  also  similarly  invert  the "saddled  with  
> CO  mechanisms"
> Dave> statement as it would appear that bringing some CO 
> properties to IP is
> Dave> what MPLS is all about. 
> 
> Certainly MPLS facilitates the bringing of some CO properties 
> to IP.
NH=> Is this a 1st step to realisation there is life outside the cnls world?

  One of
> the ideas of MPLS was to be  able to bring the (few) good 
> properties without
> also bringing the (much larger  number of) bad properties.
NH=> This smacks of .....'I know its true deep down, but boy does it hurt me
to admit it'.  As I pointed out to you in an earlier mail, our whole
industry is totally dependent on having a cct-sw/CO technology *somewhere*
below IP.......you can't connect IP transfer-mode boxes together without it
(and if I may add your company has done very well on this very principle!).
Why not just face it Eric?  MPLS can/does create new data-plane trail
entities....you may pretend this is not what they are, but we operators
still have to manage them on this basis (ie they have functions/behaviours
that are not based on IP...or any other layer network.....and as such
require their own mtce processes).
  
> Another idea was
> to do this  while using an IP  control plane.  So I hope  you 
> can understand
> why  "let's do  OAM  the way  it  is done  in CO  networks",  
> and "let's  do
> something that  doesn't require IP", is  an argument that  
> does not resonate
> very well with many of us.
NH=> I can understand this view from someone like yourself with an IETF hat
on....but to be honest it does not compute with GMPLS as I hope you can
honestly agree.  So where does one draw the cnls/co line?  I actually don't
think you need to draw any line *providing* we agree on the
principles.....it is these that are enduring (ie the set of 'network
problems' that are common to all cnls/co technologies), rather than trying
to bludgeon a '1-size-fits-all mechanism' through (when it clearly does
not).  I can also understand other views here.  When I discount the
regligion, these simple facts remaim for MPLS:
-	MPLS does create new layer networks.....has to by definition of new
OH/functionality.  I mean would LDP, CR-LDP or RSVT-TE for example exist in
an IP-only network?  Does IP issue labels?, etc  
-	MPLS can carry payloads other than IP......PWE3 is working on just
such behaviour.
-	MPLS LSPs can have failure modes that are not relevant to any client
layer or any server layer (nor should their 'behaviour' be dependent on any
control-plane or management-plane protocols in use at peer/client/server
layers).
We therefore need tools to manage the defect detection/handling of MPLS
failures that are generic and not a function of what appears above/below
MPLS, nor how the LSPs are instantiated.  This seems intuitively obvious to
me and other like-minded operators/manufacturers.