[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-bonica-tunneltrace-02
Yes Tom...you are correct. The draft Mina is referring to only covers fault
management aspects. I'd like to understand how element registers are done
wrt metrics collected/thresholding/exception(normal)_reporting/etc......I
have told our Ops guys to get on to this as I am not a MIB expert myself and
I don't know how good the stuff you/others have been doing is. However, a
further aspect of 'management' is billing and usually doing this against
delivering some SLA......so if you can't measure availability (ergo QoS)
then there are some strongly related issues here. I recall asking you about
this some time ago (ie how can you measure availability when defects are not
even defined?) and got a less than satisfactory answer...I let it pass at
the time, but at some stage I'll want to get to the bottom of this.
regards, Neil
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: 28 February 2002 16:53
> To: Mina Azad
> Cc: ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02
>
>
>
> >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.
>
> I would be careful with statements like that. I
> personally think
> that statement is
> inaccurate. I would characterize it as one characterization of for
> management of
> MPLS, but certainly not _the_ specification for how management should
> be done by any means.
>
> --Tom
>
>
>
> >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>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>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.
> > >
> > >
> > >
> > >
> > >
> > >
>
>
>
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time.
>
>