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:[email protected]] 
> Sent: Monday, July 10, 2006 7:22 PM
> To: Romascanu, Dan (Dan)
> Cc: Ops-Nm (E-mail); [email protected]
> 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
>