I'm responding to dre. >""Howard C. Berkowitz"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> At 11:27 PM -0400 5/22/02, dre wrote: >> >> 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. > >You really think that's likely? I always saw it as: >same weight/local_pref -> external route -> same as-path -> same >origin type -> *then* MED (some people doing annoying internal >IGP metrics (based on fiber distances) to MED's, others doing more >intelligent, yet also annoying values that force you to do best-exit, but >end up costing you money until you local_pref and force shortest-exit, >and lastly smart people who tell you they are doing MED's based on >delay or congested peers or *ahem* antiquated equipment (can you >say AGS+?) and you listen to them because you are friends with the >guy or some equally similar situation).
Oh--I probably wasn't clear enough. MED is really more appropriate as an interprovider route selection factor, where there is some real engineering consensus on what it means. Not necessarily just that you are providers, but it may be called for when you have a contractual relationship with the other provider for interprovider QoS. For signaling from the customer to the provider, communities are more useful than MED. If you are MPLS traffic engineering enabled, you can use community to assign to an LSP appropriate to the forwarding equivalence class of shared destinations and QoS. Even without MPLS, you can negotiate with the provider to pick a specific exit (e.g., I've done this to deliver to the POP closest to a different AS of the same enterprise, using private AS numbers) >Now, what's the next step if MED is the same? Your IGP metric. >Boom. > >Doing something like DS-TE (which it sounds like you are mentioning >as common practice for best-exit routing) is unheard of to me. > >> >Reversal routing concepts are common in the workplace and unheard >> >of in any labs/certification courses. >> >> Are you mentioning reverse path verification as well? > >Good catch. ;> Actually, I had the idea of reverse triggers using BGP >and source-specified routing a long time ago (to actually stop spoofed >addresses). I sort of borrowed the concept from MAPS RBL's BGP >reverse trigger for stopping unsolicited commercial email and other >blackholing concepts. Then Cisco (and now Juniper) started doing >this with a FIB and calling it uRPF. Funny name for a simple concept. >Well I guess it's not very simple. I'm still trying to get my head around >loose vs. strict uRPF and some of the strange ideas I've had recently >involving IRRToolSet peval and router configruations for strict mode >(or was that loose mode? heh). As I think about the loose aspect, it's establishing a class of interfaces over which the update could have arrived rather than a single interface. The class could consist of several interfaces of which destination-based load sharing has the update coming in a different interface than perfectly legitimate traffic. You might also create a class with, let's say, a low-bandwidth, low-delay link for control traffic and a high-bandwidth, high-delay path for bulk data transfer. > > >> 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. >> >http://www.ietf.org/internet-drafts/draft-ietf-idr-route-oscillation-01.txt > >Ok well that's easy. Implement your RR's correctly (duh). And I >personally say Keep It Simple Stupid and use every possibility before >considering MED's (never do always-compare, but always use >deterministic when you do use MED's), and just stick to good old >IGP costing based on whatever you want (fiber distances, delay, etc), >but make it overly simple and easy. > >One way to avoid using MED's is to call your peer and say "hey can >you local_pref or change your IGP metric around this for me?". That >generally works pretty well ;> > >> 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. > >Wish there was more out there, but thanks for the pointers =] Cisco >docs are lacking, and I hadn't seen those (woo!) 3 slides before. I >guess something is better than nothing, so I'll stop complaining now. > >> >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. > >I sort of like how the Cisco SE's are organized: >Core Transmission (e.g. SONET, ATM, Frame-Relay, Ethernet/Etherchannel) >IP Multi-Layer / IP VPN (e.g. MPLS VPN, IPSec, BGP, OSPF, VLAN) >IP Aggregation / Access (e.g. xDSL, Cable, Dial, Fixed Wireless, WLAN) >Packet Telephony (e.g. VoIP, VoX, SS7, IPBX, H.323, MGCP, SIP) >Network Management (SNMP, TFTP, CLI, HTML, XML, CORBA) > >Is this what you are talking about? Cisco is starting to organize a lot >of concepts around good models; I think they have this stuff down (but >that doesn't mean it can't be improved - they need a lot of industry >feedback). Other companies are also starting to get some momentum >(well I'm talking about Juniper, although Foundry and possibly others >have their own ceritification programs). I'm assuming this is a provider SE organization, since it doesn't consider some primarily enterprise terminology? > >> 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. > >Which I-D describes the super-community? I'm already trying to think >up crazy ideas with NO-PEER, but what's annoying is that it's breaking >a lot of my Keep It Simple concepts. Actually, everything is really coming >together in the worst way possible. Too many options now and no one >leading the bunch. We now have a big bucket of Cisco, Juniper, IETF, >oldtimers, newbies, NetVMG, RouteScience, Packet Design, and the >list goes on and on.... all trying to solve the same problems -- and working >in opposite (yet equally complicated) directions. Isn't this called Chaos >Theory or something? Really, it's not a lot of vendors in different directions. There's a LOT of interaction in the IDR working group and elsewhere (e.g., PTOMAINE), with good leadership. For example, there are three proposals for ORF, one on AS path, one on community, and one on prefix. Sue Hares, the vice chair, is letting people work out their thinking, but then plans on merging the concepts into one document before trying to go to RFC. > >> >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. > >Yeeouch. Bitter, much? Actually more amused at their bureaucratic language than anything else. What's wrong with telling someone, who knows the company is in financial trouble, is "laid off" rather than "optimized"? It was true that my role was something of an IP routing evangelist, trying, with a small team of co-conspirators, to bring back the corporate (well, mostly Bay) capabilities. > >> 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? > >Not RTFM'ing? Cisco's avoidance to test on these topics? Dunno. >What caused the 112,000 routes we have today? I really super doubt >it's all that mysterious swamp space. I think it's more like the opposite. Geoff Huston has pretty good data suggesting it's customer multihoming. The PTOMAINE WG is looking at that quite a bit. > >To be honest, I'm discovering that the industry is filled with people >trying to keep their jobs even though they are totally underqualified >and only been doing this stuff for like 2-3 (at most!) years. They are >filling the bucket of knowledge with FUD, FUD, and more FUD. And >they're growing in insanely large numbers everyday. This is *not* an >easily solvable problem and it's not going to turnaround for the better >anytime soon. I have noticed a lot of propagation, I think inadvertently, of FUD onto this list...like buying into the concept that a "layer 3 switch" is significantly different from a router. > >> 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. > >Your other book says "... get advice from your ISP or a consultant >experienced with multihoming address practices". When I read that >3 years ago I wanted to virtually beat you with a cluestick (or something)! >Is this what you are going to say in your new book, as well? Hey, the new book is for the ISP. It goes into LOTS more detail on that area. I just don't think most enterprise designers are going to keep up with multihoming technology, just as ISP designers aren't as likely to keep up with large campus switch technology. > >So, if there's a lot of enterprise education needed -- then start >educating!! There's a philosophical question here. As you know, I'm pretty involved with medicine. It's been a long time since anyone thought that specialists were not absolutely necessary -- nobody can keep up with every field. My favorite example of asking a patient if they understand enough medicine is "if you suddenly lost vision in half of each eye, what kind of specialist would you go to?" If the patient answers "opthalmologist", they aren't ready to pick specialists and should be consulting a primary physician. What I've described is a classic neurologic/neurosurgical emergency, because the problem isn't in the eye, but in the brain. > >The only things I've read so far is >A) Doyle Vol. II Figure 4-6 (NAT is used to resolve the CIDR problem) >B) Conditional Advertisement >http://www.cisco.com/warp/public/459/cond_adv.html >C) Knowledge of how ARIN and RIPE give allocations and how ISP's filter > on boundaries http://www.nanog.org/filter.html > >So what's the answer? My answer is (keeping it simple) and thus doing PI >space whenever possible and annoucing it everywhere (hrmn... disconnected >backbones... hrmn... annoying concepts... hrmn...) possible and for >inter-domain >traffic engineering for inbound use a more-specific with like no-export >(and/or >send-community setting of upstream local_pref) and/or as-path prepends >(which >are easily overridden by local_pref). More annoying concepts, but I can't >think >of anything more simple than that. I guess PA is/was saving a lot (or was >it?) for >most people (since most people are single homed?), but blah, who wants to be >single homed anyways? And who stays single-homed forever? You're going to >end up punching holes in your blocks if you hand out PA space. > >RIPE does it smart: >if you want to run BGP at all (which means you probably understand the >concept >of multihoming), you have to get a PI allocation (but most people there can >get a >PI allocation because RIPE doesn't require a minimum of 1024 hosts immediate >need and 2056 hosts by end of one year like ARIN does to get a /20). Here >in >ARIN territory, you have to be a lot more clever in order to be a good BGP >neighbor and that means choosing options A) or B) above (or going the C >route >I mentioned before and somehow getting some PI / swamp space). > >I'd like to see the delta between your thoughts and mine on PA multihoming. > >-dre There are days I want to see the delta between my own thoughts. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44821&t=44778 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
