I just want to clarify that "Requirements for OAM in MPLS Networks"
draft-harrison-mpls-oam-req-01.txt is live and kicking (exp. May 2002).
Draft-bonica focuses on tunnel tracing only, i.e. only one aspect of MPLS management.
Draft-harrison-mpls-oam-req-01.txt covers all aspects of MPLS management.
Therefore with regards to MPLS, draft-harrison-mpls-oam-req-01 is more "generic" than draft-bonica.
Regards,
Mina Azad
> -----Original Message-----
> From: Gibson, Mark [mailto:mgibson@orchestream.com]
> Sent: Thursday, February 28, 2002 10:32 AM
> To: ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02
>
>
> 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.
>
>
>
>
>
>