See Inline.. ----- Original Message ----- From: "Howard C. Berkowitz" To: Sent: Sunday, October 13, 2002 4:31 PM Subject: Re: Nanog Post: redistribute bgp considered harmful [7:54961]
> At 4:13 PM +0000 10/13/02, Peter van Oene wrote: > >At 11:30 PM 10/12/2002 +0000, Zim wrote: > >>I like this question. It seems to ponder the worth of a command based on > the > >>assumption that the command only exist to serve a purpose other than a real > >>world application. Will an ISP ever need to redistribute bgp routes into > the > >>routing table of any IGP? Well like so much in Internetworking, it depends. > >>But to take away something based solely on an assumption and perhaps a > >>limited view from your side of the world makes no sense. In short the > >>flexability should stay. Used or not, options are always good to have. Just > >>my 4cents (adjusted for inflation) > > > >I would agree that options are nice to have, but ones that have a tendency > >to catastrophically effect one's entire network with a simple > >misconfiguration might demand some additional protection. > > Actually, I'd argue that more and more options, more and more feature > creep, lead to less reliable systems. Personally, I'd rather have to > jump through a few more hoops in configuration than be exposed to > features that haven't gone through adequate regression testing -- > involving their interactions with other features. NT: I agree that more features and options do translate into being less reliable from a code-level standpoint. However, within the developmental process theses options and features do tend to provide greater insight or possibly foresight into future levels of protocol development. Also, as Micro$oft has proven so many times in the past ..the best "regression testing" resides with the public at large. :-) > In the Internet Research Task Force work on Future Domain Routing, > one of the needs expressed for next-generation exterior routing is > greater "people scalability," better options for automatic checking > and even proving of configurations, etc. There's no question that it > is easier to prove routing policy at the more abstract level of RPSL > than at the configuration language level. NT: Another good point here is the need for automatic checking. I do feel like this however will unlikely not become a reality. IMHO, much the same as with RPSL, in that the user must be somewhat proficient in order to fully appreciate/realize the benifits of the implementation. Another example is a recent thread on the nanog list that addressed complete source route verification. The need will stil have to be meet with engineers and administrators knowledgable on the implementation, whatever it may be. This is where those idiot knobs come in. Pro vs. Con. > > To answer the specific question, an ISP historically might have > wanted to inject selected BGP routes into the IGP for purposes of > best exit routing. I suggest, however, that best exit routing is > probably better done with MPLS TE. NT: There is no doubt that MPLS TE has/can provide best exit routing to rivial any redistribution. Nonetheless, based on the recent thread on the list in regards to aggrewssive implementation and acceptance of MPLS the question now remains how much MPLS TE can one depend on. I'll point everyone to this article ; http://www.nwfusion.com/newsletters/frame/2002/01550372.html In watching a recent a episode of Business Center where the CEO of Sprint noted that of the 27 or so organizations in the Telecom/Data Sector, only two(AT&T/Sprint) of the companies are said to be generating positive revenue. I know AT&T is doing a lot of MPLS, so the question is.. TO MPLS or NOT! > > Protocol features become obsolete over time, although they may have > seemed good ideas at the time: the OSPF Database Overflow feature, > (E)IGRP link-loading taken as part of a metric, etc. Other features, > which may be even more relevant here, are no longer called for in the > market -- witness the exodus of desktop protocols, LANE, etc., in the > CCIE exam. My one issue with the exodus of obsolete protocol features is how much of the obsolete code is actually removed form the code base. Furthermore, what effects will the user have endure in using software that is in effect a burial ground of unwanted features/options. Oh yes, regression testing.. I guess software development truely does have a life cycle :-) Nigel > > > > > > >>""Nigel Taylor"" wrote in message > >>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> > All, > >> > This was a recent post on the Nanog list which I thought could > get > >> > some interest on the list. Basically, the poster is questioning the > >> > relevance or real world requirements/need for certain commands, in this > >>case > >> > it's the "redistribute bgp" command. > >> > > >> > Here's the original post... > >> > > >> > Sean Donelan wrote: > >> > > >> > Should the Service Provider version of routing software include the > >> > redistribute bgp command? Other than CCIE labs, I haven't seen a > >> > real-world use for redistributing the BGP route table into any IGP. > >> > > >> > If the command was removed (or included a Are your sure? question) > what > >> > would the affect be on ISPs, other than improving reliability by > >> > stopping network engineers from fubaring a backbone? > >> > > >> > > >> > Thoughts! > >> > > > > > Nigel Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=55511&t=54961 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
