[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
As an impartial observer, there seems to be an obvious way forward for this
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
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
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).
From: Eric Rosen [mailto:email@example.com]
Sent: 28 February 2002 14:59
To: Shahram Davari
Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; firstname.lastname@example.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
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