Nice research :) I didn't bother to stretch back pre 93'ish :) Quick comments inline
At 12:33 AM 4/11/2002 -0400, Chuck wrote: >dead horse time, and maybe not worth further comment / question, but see >below if you have masochistic tendencies, or just want to delve into the >thought process of the designers: > >some snipping done because the thread was getting to be less clear. > >""Peter van Oene"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > inline > > > > > > Was it ever discussed in any BGP spec? It's certainly not in 1771, nor > > 1267 as far as I know. > > > > > > Was just making the point that beyond OSPF-BGP interaction, I've never >seen > > BGP-IGP synchronization described in any ietf documentation related to >best > > practise BGP implementations. > >I was curious about that. Besides, I wanted to see if my guess was >reasonable. So I went back to RFC 1163. I also took a quick look at RFC >1773. Finally I delved into RFC 1164. > >You are correct that historically there does not appear to be discussion of >"no synch" as we know and love it. > >OTOH, 1163 does state the following: > >"To characterize the set of policy decisions that can be enforced > using BGP, one must focus on the rule that an AS advertise to its > neighbor ASs only those routes that it itself uses. This rule > reflects the "hop-by-hop" routing paradigm generally used throughout > the current Internet." > >There is an implication here that there needs be some means of enforcing >rules of reachability. Synchronization would appear to be the best / the >only means of doing so. RFC 1164 actually discusses this in detail. Advertising only what you use is a typical strategy in routing theory. However, this does not directly imply anything related to synchronization between protocols in my opinion. I take this to mean that a router should only communicate reachability information for prefixes that it itself is satisfied it can reach. Satisfaction rules are usually limited to a single protocol. Advertising via protocol B for prefixes learned via protocol A is generally a less than optimal solution as much pertinent information can be lost in the translation. >o then why the "no synch" that all us wannabees have come to depend upon? >Is it solely to make it easier for us to set up BGP in our labs? Is it for >the practical reason that I as an ISP might have a bunch of /24's I want to >advertise, but I worry about some of them flapping due to an unreliable >carrier? You as an ISP will never use this feature. You will always run iBGP fully meshed. If you are a single homed ISP, you will nail up your advertisements for consistency (ie static routes to null and redist static + routemap or network statement) If you are multihomed and using transit services, you will likely nail up major aggregates and leak dynamically generated specifics for inbound routing optimality. These dynamic advertisements would originate as static routes and again enter BGP via redist static + route map or network statements. >As I said, dead horse time. > >Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=41167&t=40741 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
