At 11:27 PM -0400 5/22/02, dre wrote: >""Howard C. Berkowitz"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> >> -- in the real world, it's VERY rare to redistribute between a dynamic >> >> IGP and BGP. Sure, there are exceptions, but they are VERY carefully >> >> chosen. >> >> A provider backbone CANNOT survive having 100,000-plus routes in its >> >> IGP, nor should it. >> > >> >I wouldn't say it's VERY rare. >> >> There's something as key as OSI (actually more so) in this technology >> area that often doesn't get mentioned: the abstraction of routing >> policy (which is distinct from Cisco policy routing). I only started >> understanding what backbones actually were doing when I began to grok >> RIPE-181, which has been superceded by RPSL. > >RPSL is a great way of explaining routing policy. Even stranger I found it >holds a lot of programming concepts like object-oriented-ness. But the >language only goes as far as the real world implementations. Learning RPSL >was one thing, but downloading all of the radb.db files over the years and >reading through them was the real experience of a lifetime. > >> The first key question to ask here: what is the broad routing >> paradigm? Cold potato/closest exit or hot potato/best exit? > >For a "peering routes" example, yes best-exit/closest-exist problems >are super high on the agenda. However, that seems to be more of >an IGP problem, and that's where regular knowledge of say, OSPF, >is taken to a whole new level.
Not necessarily an IGP problem, but possibly an edge router that classifies traffic, possibly with communities signaled to an aggregating router, or using policy routing to MPLS tunnels. >And one that is never taught in any >course or material in any classroom or even online. You learn that >on the job at an ISP (does anybody else have any resources for this?). Most of my knowledge of this approach came from IETF mailing lists, some of the MPLS drafts, and informal discussions with protocol implementers (well, I was doing some of the cancelled Nortel router architecture for this). > >> >Many ISP's may want to inject their IGP into their BGP for >> >customer static routes (using a route-map to filter out all the junk). >> >> With considerable aggregation, yes. Alternatively, though, >> redistributing blackhole statics for their allocations is common >> enough. > >Reversal routing concepts are common in the workplace and unheard >of in any labs/certification courses. Are you mentioning reverse path verification as well? > >> We've been learning a lot about that IGP metric direct translation to >> MED can be dangerous, and produce persistent oscillation. Those route >> maps may be the better way to set MED. > >Where is there information available in-print/online about the MED's >topic? Another one completely skipped over. http://www.ietf.org/internet-drafts/draft-ietf-idr-route-oscillation-01.txt >Most people are using >IGP metrics alone these days, no need to try to translate. At least in >the environments I've seen. This is a part of that whole closest-/best- >exit argument above. I've never really seen any configs or designs for >translating IGP metrics to MED, something like that would interesting >to see - even if it produces oscillatory routing. Do you know why this >happens? Can you try to explain the problems more effectively? There also some unusual uses of MED, where IOS has knobs to implement certain behavior. Always-compare-MED can compare the MEDs of different AS, as long as they are adjacent. Avi Freedman had a presentation on an informal standard for exchange-point MED values, based on delay, at the Denver NANOG. > >> >Service providers typically implement tons of statics and defaults, >correct. >> >Most don't like it, though, and try to design around it for any >> >alternatives. >> >> Well, it depends. If you look at my NANOG and ARIN presentations on >> address management, this lends itself to being automated. A provider > > certainly has to keep a database of the address space it hands out. >> Once you have this database, writing a Perl script or even the DBMS >> reporting system can be used to generate ip route, DNS A/PTR, etc., >> records, which then get merged into .cfg files for routers and/or >> sent directly to the devices, using telnet/TCL/expect. > >Don't forget to automate the billing, RWhois/SWIP changes, and the rest. ;> > >> >This stuff is pretty easy, actually. At least once you start doing it >and >> >getting your head around the problems. >> >> Ummm...isn't that about what you say to a virgin about sex? :-) > >Luckily there are lots of good books and even real-life experiences that >you can purchase. And there's lots of people willing to share their >experiences. There's a whole different industry and market there, Howard ;> >I don't think you need to go to school or have certifications, at least my >wife >didn't ask for any credentials. I shudder to think what thread drift here into certification versus experience versus academic arguments might bring. I will recount one of my favorite Shel Silverstein cartoons as an example of how this discipline is relevant to topology and loop-free routing. The scene: two octopi, their tentacles incredibly tangled. One looks rather sheepish, the other, with eye makeup and earrings, is speaking. Caption: "and did the Kama Sutra tell you how to get OUT of this position?" Getting out of bad routing is an important skill, especially when you got there from bad data from another AS. This gets into the whole theoretical area of the Byzantine Generals (also called Byzantine Corruption) covered in Radia Perlman's dissertation. > >> Yep. A lot of tutorials as well at www.radb.net. I use extensive >> RPSL and pseudo-RPSL in explaining provider problem analysis in the >> new book. > >That sounds really cool. Got any examples for those of us who can't wait? They are kind of graphics heavy. Let me see if the publisher will let me post a sample chapter. > >> Exactly. But the point here is that the certification programs aren't >> enough to get started. This is one of the reasons people on this >> list keep emphasizing that proficient network engineers MUST learn to >> research on their own. > >I would never argue against that concept! =] I thought the point of the >thread >was to identify places where there isn't *any* information out there, and >stuff >that's totally black-art. Cisco certs clearly don't have the whole >ball-of-wax, >but a lot of this can be easily incorporated into their curriculum. Well, it depends how complex you want to make the curriculum. I don't really see, for example, why an ISP routing engineer needs a particular knowledge of VoIP. If the ISP offers voice, they are likely to have full-time voice specialist. If the ISP is just providing connectivity, the VoIP and AVVID in general becomes the enterprise's problem. I'd rather see more certification types, in more depth than breadth, in more areas. That's the way the TAC is internally organized, anyway. > >> Olivier Bonaventure, whom I believe reads this list, has developed a >> superb document that I hope will move to Informational RFC. > >Yes, that one is especially good. He'll be at NANOG discussing exactly >this: >http://www.nanog.org/mtg-0206/bruno.html > >Interesting ones to me are the NO-PEER, Link Bandwidth, and the new >Alvaro Retana "Cost Community". There are a couple of alternatives to NO-PEER, including a concept I called the super-community in an I-D. It might have advantages with respect to exchange points and distribution within a region, but NO-PEER is much more general. > You're starting to see the BGP >community concept explode into the feature creepism that every IETF >protocol does. It will be a laugh to see how the Internet holds up to >such concepts. They'll be combining BGP communities and LDAP >and XML and NFS in no time. ;> This trend is a good part of the reason we have to limit the number of BGP sessions per router. All the policy processing adds significantly to CPU load; it's not a forwarding capacity or RIB size problem. > > >> A stray comment pertinent to the arguments we see here about >> experience vs. lab rat, "Old Timers" who feel threatened by new and >> won't share knowledge, etc. Here's a book coming out almost >> simultaneously with my book on the same general area. I'm delighted! >> This is a sufficiently complex area that having multiple authors >> describing it in their own style will help the industry. I know Phil >> in person, but Barry only electronically, and I'm sure they will do a >> great job. I really have to think hard to consider them >> "competitors," rather than true professionals trying to "pay it > > forward". > >> >I think MPLS is still niche, like ATM, but it's better to know it when >you >> >are going >> >to need it. Cisco all but invented MPLS as Tag-Switching, Actually, the first implementations were at Ipsilon, which had a working but significantly limited, ATM-dependent product perhaps 18 months before anyone else. I think Nokia bought Ipsilon. > > >Hahahaha, that's like saying ATM is a replacement for IP. Or CLNS. >Actually IPv6 is a replacement for IPv4. Tell Nortel to work on that. I did. To use their euphemisms, telling things like that is one reason I was "optimized" out of a job. > > >> But the point I want to make is these are statistical >> characterizations. The table never truly becomes stable when you are >> handling full routes, and the research proposals in the IRTF and >> elsewhere recognize that trying to get global synchronization is like >> my cat running away from his tail. > >But, in my opinion you need to "do the math" (literally) to understand the >problem. Something that I doubt anyone would ever teach in a "shortcut >certification course". Exactly. I'm struggling myself with some new concepts based on control systems theory. Negative feedback to a digital routing system is mathematically...interesting. > >> >Back to the IRR/RPSL concepts, ISP's do filter. PA space is becoming >less >> >and less useful for multhoming purposes -- in Europe, ISP's only allow >RIPE >> >PI space generally and won't do the PA space multihoming like US ISP's >do. > > > >> We are in violent agreement. Hopefully, I will be able to have >> physical clue sticks made up soon. > >Which part are we in violent agreement about? RIPE, Conditional >Advertisment, >or Multihoming NAT configurations? You've always said yourself, "what is >the >problem you are trying to solve?". Don't you think any of these >applications of >specific technology will help anyone? Shortage of smart -- make that uninformed -- people. How many times do you see posts to this list wanting to know how to globally load-balance their BGP traffic? What fundamental misunderstanding causes this? Conditional advertisement is something I wish would get into Cisco IGPs, where I think it's more useful than in BGP. In general, I can usually hack some policy, especially with interprovider cooperation, that can do a semblance of conditional advertisement. Don't get me wrong, keep it in BGP. But where I'd love to see it is in OSPF summarization. Cisco and Bay took different approaches, each of which can be legitimate depending on your routing policy. I'd like the choice between either: Cisco's which emphasizes stability at the possible risk of blackholing, and Bay's emphasis on optimal routing at the cost of deaggregating. > >IOW: What is your opinion on how to handle the multihoming announcements >problem? In the US, more specifically? Should Europe/Asia be handled any >differently? Or do you not consider it a problem at all? Bring the >cluesticks ON! Not sure which aspects you have in mind, and there's a lot of enterprise education needed about what various multihoming strategies will and won't buy them -- I spent at least a chapter on these choices. NO-PEER could help, because it's becoming pretty clear CIDR aggregation is becoming less useful due to the desire of customers for multiprovider multihoming. I also find that single-provider multihoming to multiple POPs, with conscious local loop diversity, is much underutilized. > >Please don't say IPv6 because, well, ... we know ... we know ... IPv6 multihoming is actually a much scarier problem. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44789&t=44778 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
