> Because it's the easiest place to do it. i once had someone tell me that > something should be carried in BGP because it was "easier" than duplicating > all the code for a new network protocol to do the data copying/replication. > As a non-professional implementer, I considered their opinion valuable.
I don't agree... It might be easy enough to use the same transport, but to carry in the same session --eventually you get to the point where you have everything being carried across one protocol. Is it working well to carry real time and streaming voice, real time and streaming video, ftp type data files, text, and a ton of other stuff in HTTP? How do you build QoS around this? Deep packet inspection? TRILL used IS-IS, but put it in a different process. There's a lot to be said for reusing code and ideas, and a lot to be said for splitting up failure domains, databases, and transport instances. > I think there's a few things here that are certainly valid concerns. I'd > like to refresh them into the following based on my observations: > > 1) The transport core of the network where all these control-plane messages > currently happen is growing and requires dense-high bandwidth routers > 2) when you upgrade the router/fabric/whatnot you typically need some new > routing-engine, rsp, cpu, etc. that is typically "faster". Maybe not fast > enough for some, but they tend to be "faster". > 3) As a percentage cost of an overall upgrade (take t640 -> t1600) the RE > component is not the most expensive part by far > 4) Cisco/Juniper have some products that are certainly long in the tooth and > honestly are too underpowered for even their own aggressive cpu > consumption/growth. It's so bad in cases they don't realize the performance > is poor on the older hardware as the labs typically have (on average) newer > hardware than in the core provider networks. "Underpowered" is a matter of opinion. A netbook is "underpowered" for some things, and perfectly powered for others. So is an iPad, and I don't see lot of people carrying around 6TB is drive space and 8GB of main memory with a quad core processor in their pockets --and yet people don't seem to complain about underpowered smart phones. If you're going to change a router into a fast compute platform with a lot of disk and processing requirements, it's going to take a while to make the proper adjustments. > I don't necessarily trust anyone in this arena. There's a lot of potential > for harm. I don't want my routers to require on some external device. You > may be willing to live with that, but I can not. I can not allow my network > to be constrained by some COTS PC where the vendors are unwilling to support > it, or decide that it's cheaper to just refund the entire cost than > fix/replace it (As is happening with HP/Dell on some devices now - google > 'sandy bridge' and/or 'cougar point'). While an ECO is something painful for > anyone, I would rather it be on something where the vendor is going to stand > behind it, vs people who can't trust you to plug in anything (optics, another > vendors bgp speaking device, etc) and have their devices operate properly. But you're making the assumption that whatever security device exists must be "plugged in" to the router physically. This is a bad assumption, IMHO. There is a market for firewall code in routers. There is a market for firewalls that are independent of routers. Again, this is part of the problem with the document --assumptions like this are buried under the covers. Bring them into the light of day, so we can discuss them. > I like the fact that Randy has talked about if you do the validation, how > much incremental cpu time it takes vs processing a prefix-list/as-paths, etc. > True comparision/data. I'm sure he can provide you links showing that the > "puny" cpus can keep up, and you don't need a 52-way cpu system to process > the bgp messages. But Randy has already said that those parts of the draft have nothing to do with performance, but security only... > (i am also frustrated that too few of my colleagues/peers have time to > participate in this stuff, and also that it takes so much time away from my > family.. then again, i'm sure i'm some sort of a tech addict as well). OTOH, this is going to have a major impact on your operations in the next few years. You need to think carefully about: 1. What is it you're trying to accomplish --what problem are you trying to solve? 2. Where do you want this complexity? 3. Do you want to assume BGP is where it should be for the next 20 years, or do you think we need to put security within a plan for pushing BGP along to something newer and better? One of my underlying assumptions is there won't ever be a "flag day," for BGP, so whatever we do for security now, we must either work around to push BGP forward, or we must live with permanently. :-) Russ
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
