RE: draft-bonica-tunneltrace-02

["Gibson, Mark" <mgibson@orchestream.com>]

As an impartial observer, there seems to be an obvious way forward for this
discussion.

In the first instance, draft-bonica-tunneltrace-02 can go through the usual
process in the wg meeting in Minneapolis and, subject to rough consensus,
become adopted as a solution for the cases that it solves.  I believe even
the proponents of the mplsoam scheme concede that the tunnel trace solution
has merit in certain circumstances.  [a point made by Dave Allan as I type]
Lets document that solution space and, if technically sufficient, advance
this draft such that tunnel trace can meet all the points in that space it
can.

In the second instance, lets define the specifics of the remainder of the
OAM problem space and work on some solutions that solve these problems.
From memory, there were a number of individuals in the OAM BoF who, though a
minority were a large minority who believed something more substantive than
tunnel trace was needed, including a number of operators.  Presumably these
guys know what their requirements are.  As has been stated these are to a
large extent documented in the (sadly too new to get at for free) documents
Y.1711/Y.1710 but were in the now expired though surely google-able
draft-harrison... 

And finally, lets stop this "not invented here" mentality.  I'm not sure
that dismissing ITU documents because that's what they are does the IETF any
favours at all.  (c.f. the diatribe against the WAP representative at the
Adelaide open plenary).

Mark

 -----Original Message-----
From: 	Eric Rosen [mailto:erosen@cisco.com] 
Sent:	28 February 2002 14:59
To:	Shahram Davari
Cc:	'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org
Subject:	Re: draft-bonica-tunneltrace-02 


Shahram> It  has serious  security, complexity,  backward  compatibility and
Shahram> layer violation issues.

Tom> Can you elaborate on what you think these are? 

Shahram> Please refer to previous emails by me and David Allan. Most of them
Shahram> are listed there.  

I'm sorry, but  as far as I  can tell, those previous mails  simply say that
(a)  the  proposed  solution doesn't  do  some  things  that you  think  are
valuable,  and (b)  the proposed  solution doesn't  fit well  into  some ITU
architecture.

The  second  of  these  points  is  completely  irrelevant.   The  first  is
irrelevant too, unless there is a reasonable alternative proposed which does
more,  or if the  current proposal  doe so  little that  SPs don't  think it
worthwhile.   The MPLS OAM  stuff you've  been pushing  is not  a reasonable
alternative of  this sort  because (a)  it is MPLS-specific,  and (b)  it is
already crystal  clear that it will not  be accepted in the  IETF.  And it's
pretty clear  that a number of SPs  do think that what  the current proposal
does is worthwhile.

If  you can actually  cite specific  security issues  with the  proposal, it
would be valuable to know about them. 

Suggestions for reducing complexity would  also be valuable, if you have any
specific suggestions in that area. 

I don't understand what the backwards compatibility issue is, as there is no
previous version to be compatible with.

If you think there  are layer violation issues, then what you  need to do is
exhibit the particular set of  specific problems that will arise in practice
as a result of those violations.   If you cannot do this without referencing
some arcane ITU  architecture document, then the natural  conclusion is that
the  problem  is with  that  architecture's  layering  model, not  with  the
proposal.