IETF 87 GROW meeting notes 07/30/2013 - 5:00PM draft-cardona-filtering-threats Presentation: Making BGP filtering a habit - Impact on policies - Camilo Cardona Discussion Ron Bonica - not seeing how the example is an undesired flow Camilo Cardona - ISP is providing transit through an unintended path Chris Morrow - Is this an example of a route leak? Camilo Cardona - Not considered a canonical route leak. It's a join of covering and more specific announcements with filtering in place Mikael Meulle - These cases are useful to document. Question: Is it possible to create loops? Camilo Cardona - Loops are not known to be an issue in these cases. John Mitchell- Useful updates to most recent draft. May struggle with encapsulating certain business policies. Some cases may be completely intended. Rudiger Volk - This is definitely about business policies. Have seen examples where customers appear to be taking economic advantage. Also some accidental cases as well. However, it is good to have it documented draft-chen-idr-based-traffic-steering-usecase Presentation of draft - Mach Chen Discussion Wes George - If you are not careful where you announce the paths you can create a routing loop. Have to be able to deal with backup paths. Almost as complicated as using RSVP-TE. Need to be carefule with IGP metrics. Can end up sending traffic the wrong way. Many risks. Peter Schoenmaker - What is the intention of bring draft to IETF? Can split into two parts - use cases and potential solutions. Can standardize the use cases. Jeff Haas - Why wouldn't you use RSVP-TE and other mechanisms such as Add Paths or BGP optimal Route Reflection? Perhaps useful for networks that don't have MPLS deployed for some reason? This is probably not a motivating consideration for most networks. Robert Raszuk - most networks have at least 2 RR's, How do you guarantee no loops? John Mitchell - People may be thinking in terms of traditional route reflectors. They are not considering software based RR computations. Rob Shakir - If we are going get RR's synchronized, why not use TE and call it TE? Mach Chen - May be useful for small networks that don’t want to upgrade/use MPLS. Wes George - On small networks, the argument that is diffcult to roll MPSL or upgrade doesn’t really hold water -- they are much easier to upgrade than a large network. draft-bgp-route-server-operations Presentation by Robert Raszuk draft was split in two - IDR for BGP changes, remaining best practices document remaining in GROW Discussion Jeff Haas - haven't read draft, all old issue for route servers . Is it due to history being lost. Robert Raszuk - attempt to document route servers and not rely on old documents Jeff Haas - People now have VRF and VRF-lite to do similar things Layer 2 reachability through next-hops, we use BFD. But BFD doesn't help in this case - can reach route serves, but not peers. Could use a sedate timer for tracking. Various cludges didn't always work in past. Randy Bush - when layer n is not congruent with layer n-1 there will be issues. Robert Raszuk - can be same issue with RR's. Randy Bush - only when RR's are out of the data plane. Peter Schoenmaker - route servers are deployed today, we still need to document. Chris Morrow - is the goal to document the operational reality? Randy Bush - not saying don't document it, just saying don't use it. Robert Raszuk - how do you peer when there are 500 peers? Randy Bush - NTT uses automatically generated BGP peering configs. Chris Morrow - yes, everyone should use automated configs.. Randy Bush - competitors are welcome to do it their own way. Chris Morrow - whether or not good or bad, it should be documented. John Mitchell - only addresses IXP best practices - other use cases? Rob Shakir - recent work has massively improved stability of route servers. Some people still won't use them (Randy), still good to document the use cases. Chris Morrow - Agree, that having documentation still useful. Rob Shakir - This is ultimately a religious issue. Jeff Haas - last NANOG had dicussion - bigger operators don't use route servers to make their life easier, they just use it to help smaller operators. draft-ietf-opsec-bgp-security-01 Presentation - Courtesy update for GROW from OPSEC Discussion Randy - Unfortunately, like much of BGP, RPKI stuff is still a little delicate - should just point to the RPKI origin authentication documentation which has already gone to last call Other items Wes George - route leaks draft? what's going on? Danny - going to update and re-submit draft Rob Shakir - Ops req for BGP error handling needs another rev - please submit comments