RE: draft-bonica-tunneltrace-02

["Thomas D. Nadeau" <tnadeau@cisco.com>]

>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.