[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Routing requirements draft
Eliot,
The common goal is shared - keep the Internet running smoothly.
One needs first to define bits on wire, write code, experiment, go to
market in pre-standard mode. We agree on this as well.
But then is defining how a protocol is being deployed, operated and
maintained 'very important' for sunning the Internet smoothly?
This is the question that we are discussing. I personally do not know
the answer to it.
But I know that the alternative today - mandating the writing of MIB
modules - does not work well in many cases.
Dan
> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]
> Sent: Monday, July 10, 2006 7:22 PM
> To: Romascanu, Dan (Dan)
> Cc: Ops-Nm (E-mail); mreview@ops.ietf.org
> Subject: Re: Routing requirements draft
>
> Dan,
>
> For personal reasons I can't attend. However...
>
>
> > - Control of Function and Policy
> > - Information and Data Models, e.g. MIB module
> > - Liveness Detection and Monitoring
> > - Verifying Correct Operation
> > - Requirements on Other Protocols and Functional Components
> > - Impact on Network Operation
> >
>
> Could you imagine what the statements for BGP4 would have
> been at the time? There was no AS-PATH prepending and a
> zillion other things that are now common with most vendor
> implementations. So if they had a section it would have
> quickly been outdated. But more importantly the protocol
> would never have gotten out. One of the biggest problems
> with the routing area is that vendors try to get to market
> quickly with "pre-standard" functionality. And this has been
> the case since BGP4's release. So why on earth would we want
> to make it harder for people to document existing practices?!
>
> I'm not saying these things are unimportant. They're very important.
> But it's in everyone's best interest to keep the Internet
> running smoothly. Text in a document won't do it. Only
> testing and experience will.
>
> So this is a big, fat vote for the authors THINKING about
> this stuff, but let's not cram this down their throats.
>
> Eliot
>