inline At 10:43 PM 10/13/2002 +0000, Nigel Taylor wrote: >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. :-) True, but bugs in my win98 don't squash global communication networks in 1 minute or less. > > 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 The article in question deals with tunneling protocols for use in IP VPN's which although an interesting debate, might be somewhat orthogonal to the question of MPLS TE vs IGP for best exit routing. Furthermore, the article asks the question from the customers perspective which should be rather different from the providers. Customers should receive the service they pay for, and really shouldn't care that much about how a given provider delivers that service. However, providers should care entirely about how they deploy a given service and from that perspective, I would suggest that providers can depend a great deal on MPLS as an alternative to IGPs for best exit routing. >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! MPLS is simply a tool. Used correctly, it can provide a better use of your existing set of very costly infrastructure circuits. It can also help you reduce the amount of networks required to support various service offerings. It can also help you to scale the existing legacy networks you already own (high speed backbones for ATM network interconnection comes to mind) Unfortunately, it doesn't completely change your cost of doing business entirely in a single deft stroke thereby delivering instant profitability. These data companies, if they survive, are going to do so by cutting costs, and delivering more fee for service value to the customer. MPLS is a one of the many tools that can help them do these sorts of things and shouldn't be summarily dismissed because it isn't a panacea. > > > > 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 :-) It is unfortunately that the market has allowed such a low bar to be set in this area. >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=55584&t=54961 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
