Dear GROW, (Removed sidrops@ from CC)
*Wearing a Working Group participant hat* I reviewed draft-ietf-grow-route-leak-detection-mitigation-04 and it appears to me there is a shortcut possible in the mitigation algorithm. This shortcut in turn negates the need to specify any ASN in the "DO Community". Only requiring a single community opens up the path to use existing well-known RFC 1997 community as signal between BGP nodes. The section 4.1 leak mitigation algorithm could be revised such that if a route path present in the Loc-RIB is considered the best path and eligible for export to EBGP neighbors, an additional verification step is performed. The sender could check whether a 'DO community' is present on the route in the Loc-RIB, and if the to-be-exported-to EBGP neigbhor is configured as a 'lateral Peer' or as 'Provider', the route is rejected in the PIB (Policy Information Base) and thus will not be present in Adj-RIB-Out - thus blocking a leak from happening. This places the route leak mitigation solution one step earlier in the BGP 'supply chain' process. There is an existing well-known BGP Community known as 'NOPEER Community for BGP Route Scope Control', described in RFC 3765. Similar to how the mitigation does not truly differentiate between 'Providers' and 'Lateral Peers' (if one considers routing policy puzzles often can be solved through multiple different combinations of policy in either of EBGP-IN, IBGP-OUT, IBGP-IN, EBGP-OUT. The recommendation then simplifies to the following three steps: 1/ Recommend network operators to never strip the RFC 3765 Community upon receiving a BGP route from either an IBGP or EBGP neighbor. 2/ Recommend network operators to manually configure (or have BGP OPENv2 speakers automatically) *add* the NOPEER Community (if it wasn't already present) to route paths received from a Lateral Peer or Provider. Then proceed with whatever Import Policy applies. 3/ Recommend network operators (or have BGP OPENv2 speakers automatically) block routes which contain the NOPEER Community from propagating towards EBGP neighbor marked as 'Lateral Peer' or 'Provider'. The procedure stops. 4/ If the EBGP neighbor is *not* a 'Lateral Peer' or 'Provider', the route MAY be added to the Adj-RIB-Out specific to that EBGP neighbor. The NOPEER community is not removed (see step 1). As Nick Hilliard pointed out earlier in this thread, there might be business requirements which require the operator to override the autnomous system's default policy, but as the NOPEER Community happens to be 'just a BGP community', operators can do as they wish with the received routing information. A case can be made that operators - by default - would benefit from accepting the NOPEER community and based on its presence prevent routes from propagating further towards EBGP neighbors in the Peer/Provider class. The above proposal is slightly different than the implementation requirements stemming from honoring GRACEFUL_SHUTDOWN (where the intention is for the inter-domain signal to be honored on EBGP-IN), the NOPEER community essentially is best honored in EBGP-OUT policies. Promoting inter-domain use of the NOPEER community by outlining how correctly adding & scoping based on this community one can help mitigate BGP route leaks. The NOPEER community being readily available in most deployed BGP speakers for any operator wishing to use the mitigation mechanism, this might make for a compelling argument. In short 'Down Only' is equivalent to 'Not towards Peers & Providers: - in EBGP-IN set NOPEER on routes received from Peers/Providers - in EBGP-OUT block NOPEER routes from being announced to Peers/Providers The above appears incrementally deployable, and compliant with the specification of NOPEER, and can be promoted through Network Operator Groups by converting draft-ietf-idr-route-leak-detection-mitigation to target Best Current Practise (BCP). Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
