[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-bonica-tunneltrace-02
So do mine.
Ours are documented in Y.1710 where are your documented?
regards, Neil
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: 05 March 2002 19:42
> To: neil.2.harrison
> Cc: ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02
>
>
>
> >Tom...I suspect Enrique is saying this because that is the
> only place he is
> >aware that they are written down and, since this is from the ITU, by
> >definition must have operator agreement. Can you please
> provide us with a
> >reference to the requirements documents that you are working to?
>
> My requirements come from my customers' operational
> departments.
>
> --Tom
>
>
>
> >thanks & regards, Neil
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > > Sent: 05 March 2002 17:01
> > > To: Cuevas, Enrique G, ALASO
> > > Cc: David Allan; Shahram Davari; ccamp
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > >
> > > 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.
> > >
> > >
>
>
>
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time.
>