Jared, See below.
On Feb 11, 2011, at 14:02 MST, Jared Mauch wrote: [--snip--] > 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. In fact, I would say my network is the complete opposite. :-) I already depend on external COTS servers for a variety of mission critical functions in the network: IRR, DNS, Netflow collection/processing, SNMP stats, syslog messages, syslog processing, etc. (I would be shocked if other networks don't have similar requirements for external COTS servers). > 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. (Sorry the following strays a bit off-topic for a technical mailing list, but I wanted to inject the operational reality as I see it from my vantage point). Ultimately, I understand "different strokes for different folks". My main point is: SIDR can't (or, at the very least) should not force a single operational or deployment model (i.e.: in-band transport in BGP of certs, etc.) on operators. To emphasize this point further: - Different networks have different EOL replacement strategies and, more importantly, timelines. - While some networks may be limited to only sourcing network equipment from a limited set of vendors, others are not. Requiring crypto-assist onboard routers is likely to either take a very long time for a broader set of vendors to implement or have them abandon the market altogether. Both would be very bad outcomes IMHO. Thanks, -shane _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
