On Fri, May 2, 2014 at 1:47 PM, Jared Mauch <jared@puck.nether.net> wrote:
On May 2, 2014, at 3:44 PM, Deepak Jain <deepak@ai.net> wrote:
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session?
We use v4 transport for v4 routes and v6 transport for v6 routes only.
+1
This way if one plane is unstable the other is unaffected.
From the draft BCOP on this topic[1]: ----8<---- Establish new, IPv6-Only peering sessions parallel to existing IPv4
This is the key point I believe: No protocol fate sharing! peering. Individual IPv4 and IPv6 BGP peering sessions should be established between all BGP neighbors, particularly eBGP peers. While it is possible to use Multiprotocol BGP (MP-BGP)[2] to carry IPv6 Network Layer Reachability Information (NLRI) over existing (or new) IPv4 BGP peering sessions, this is not recommended. Both BGP sessions MAY use the same logical circuit, or, a new port MAY be used for IPv6 (separate physical or logical connections is NOT a requirement). [removed image] This maintains independent IPv6 and IPv4 topologies, rather than tying the two together unnecessarily. It prevents black holing of IPv6 traffic in the event of a protocol outage because the IPv6 session goes down when IPv6 reachability is lost. When an IPv4 BGP session carries IPv6 NLRI, IPv6 routes are only withdrawn if IPv4 connectivity is lost. Independent BGP sessions also facilitate protocol specific maintenance because the IPv4 and IPv6 sessions don’t affect each other (e.g. IPv6 can be “bounced” without effecting IPv4 and vice verse). Finally, establishing new, IPv6-only peering creates better operational clarity. It allows IPv4 and IPv6 configuration stanzas to be independent and easily recognizable. ----8<---- Cheers, ~Chris [1] - http://bcop.nanog.org/index.php/IPv6_Peering_Transit_BCOP_v0-6 [2] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4”, RFC 4760, January 2007
- Jared
-- @ChrisGrundemann http://chrisgrundemann.com