On Thu, Apr 12, 2012 at 01:07:38PM -0400, George, Wes wrote: > [WEG] I'm not totally sure which message you're referring to, but I think > that may be a red herring. I'm not seeing how incrementing the BGP version > automatically means that all routers in an ASN must upgrade to it.
Fish aside, given prior statements that once you leave a BGPSEC domain that you stop doing BGPSEC, then it seems reasonable that you can't have bgp-4 inside of bgpsec. I suspect that's not what some people are meaning by BGPSEC domains or versions or what have you. But this is all fall-out of what does it mean to do BGPSEC in an AS that won't have some number of routers that can do it. The original model discussed was BGPSEC signature operations at eBGP borders. In that model, iBGP considerations are largely irrelevant to the signatures. Where they become important is the edge cases where iBGP may alter AS_PATH data. If iBGP speakers are expected to participate in signature operations, we need to figure out what that means. Chris M. suggests signing at origination - signing to what exactly? When there's confederations, is there signing? What do those certs look like in the RPKI especially when AS numbers are re-used (private ASes)? How do you handle confederation AS stripping signature-wise? If you don't believe each router in an AS needs an upgrade, you obviously have protocol behavior in mind. Write it down, please. Keep in mind the answer will change based on whether BGPSEC operations are done in iBGP or not. > This isn't exactly the same flag day sort of driver as the move between v3 > and v4. BGP speakers that support BGPv5 also SHOULD support BGPv4, and would > determine which they should use on initial capability negotiation. If you can do the work via capability negotiation, I'd argue you don't really need a new version number. -- Jeff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
