RE: draft-bonica-tunneltrace-02

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

         Why are we still discussing Y.1710? I thought that this
was the IETF. The following seem to comply with the operational
OAM requirements I am hearing from operators.

          LSP "ping",
          LSP Traceroute
          MIBs

         Others may be required.

         --Tom


>Could you provide us with a matrix (comply/does not comply) of the tools 
>you are
>talking about vs. the requirements given in Y.1710?
>
>Enrique
>_______________
>ecuevas@att.com
>Tel. (732)-420-3252
>
>
> >-----Original Message-----
> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> >Sent: Tuesday, March 05, 2002 9:07 AM
> >To: David Allan
> >Cc: Shahram Davari; ccamp@ops.ietf.org
> >Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> >
> >
> >>Your statement that requirements support the tools/mechanisms
> >that work
> >>today is the nib of my concern. Basically the requirments step is
> >>redundant at that point. We are now in a tight embrace where the
> >>requirements justify the solution and the solution dictates the
> >>requirements. Suggesting the requirements is a WG work item
> >would appear
> >>to be an oxymoron.
> >
> >         As I mentioned, some of the tools have already been worked
> >out, so yes, the cart is before the horse in some cases. However,
> >I don't think that this is necessarily a problem.
> >
> >         --Tom
> >
> >
> >
> >>Dave
> >>
> >> > -----Original Message-----
> >> > From: Thomas D. Nadeau
> >> [<mailto:tnadeau@cisco.com>mailto:tnadeau@cisco.com]
> >> > Sent: Monday, March 04, 2002 5:47 PM
> >> > To: Shahram Davari
> >> > Cc: ccamp@ops.ietf.org
> >> > Subject: RE: draft-bonica-tunneltrace-02
> >> >
> >> >
> >> >
> >> > >Thanks for your positive response. With regards to the
> >> > protocol requirements,
> >> > >which ones do you think MUST be there and why?
> >> >
> >> >          I think that the protocol requirements for those
> >> > solutions that
> >> > currently
> >> > exist should be in there.  I understand your point about
> >> > reverse engineering the tools, but unfortunately the
> >> > requirement writing effort
> >> > started after we had some solutions working. Therefore
> >> > protocol requirements
> >> > do matter because they support the tools/mechanisms that work
> >> > today. No
> >> > need to obviate those things at this point.
> >> >
> >> > >In my view protocol requirements should not unnecessarily
> >> > restrict the
> >> > >solution,
> >> > >unless they violate application requirements.
> >> >
> >> >          I think that protocol requirements should be in line
> >> > with the
> >> > application
> >> > requirements that have come from operational folks working at
> >> > SPs.  However,
> >> > application requirements should fit within existing protocols
> >> > as much as
> >> > possible (to promote reuse of existing software/tools).
> >We should not
> >> > be forced to reinvent the wheel just for the sake of doing so.
> >> >
> >> >          --Tom
> >> >
> >> >
> >> >
> >> > >-Shahram
> >> > >
> >> > > > -----Original Message-----
> >> > > > From: Thomas D. Nadeau
> >> [<mailto:tnadeau@cisco.com>mailto:tnadeau@cisco.com]
> >> > > > Sent: Monday, March 04, 2002 4:25 PM
> >> > > > To: Shahram Davari
> >> > > > Cc: ccamp@ops.ietf.org
> >> > > > Subject: RE: draft-bonica-tunneltrace-02
> >> > > >
> >> > > >
> >> > > >
> >> > > > >I think instead of debating whether Y.1711 is better than
> >> > > > LSP-ping/GTTP or
> >> > > > >vice versa, it would be more
> >> > > > >constructive to identify and document the applicability of
> >> > > > each proposal
> >> > > > >for various tunneling applications.
> >> > > >
> >> > > >          This sounds like a move in the right direction.
> >> > > >
> >> > > > >For this particular draft my suggestion at this stage is
> >> > > > that the Bonica's
> >> > > > >requirement draft be revised to:
> >> > > > >
> >> > > > >1) Add text (or at least a place holder) for additional
> >> > > > security issues
> >> > > > >raised on the list.
> >> > > > >2) Add backward compatibility, simplicity and scalability as
> >> > > > requirements.
> >> > > >
> >> > > >          I can go along with those.
> >> > > >
> >> > > > >3) Remove the protocol requirements section, since any
> >> > > > requirement here
> >> > > > >will be viewed as a reverse engineering of some solution.
> >> > > >
> >> > > >          Although this might sound reasonable to some, I
> >> > > > think that some
> >> > > > may object to this
> >> > > > since the protocol requirements are viewed by some as
> >> > > > fundamental to the
> >> > > > requirements
> >> > > > of any particular solution.  In the flurry of emails on the
> >> > > > topic, I have
> >> > > > not been able to
> >> > > > keep track of what the consensus on this might be (either
> >> > > > way). Perhaps Ron
> >> > > > has been keeping
> >> > > > track?
> >> > > >
> >> > > > >Then any offered solution should have text to show to what
> >> > > > extent they
> >> > > > >fulfill the
> >> > > > >requirements, and what is their applicability and
> >restrictions.
> >> > > >
> >> > > >          Sounds reasonable.
> >> > > >
> >> > > >          --Tom
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --------------------------------------------------------------
> >> > > > ----------
> >> > > > Mathematics is the supreme nostalgia of our time.
> >> > > >
> >> >
> >> >
> >> >
> >> > --------------------------------------------------------------
> >> > ----------
> >> > Mathematics is the supreme nostalgia of our time.
> >> >
> >> >
> >> >
> >
> >
> >
> >---------------------------------------------------------------
> >---------
> >Mathematics is the supreme nostalgia of our time.
> >
> >



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.