Hi all, Thank you very much for the updated drafts and presentation at IETF 101 regarding bmp and Adj-RIB-Out and Local-RIB support. I have been reading the updated draft and fully support them.
Regarding route filtering the comment from Reudiger Volk. From a network operator point of view, I share Serpil's comments. I also share Paolo's concerns bringing in more complexity could potentially lead being less adapted by vendors. I share Job's suggestion that this should if being addressed in a separate draft. At current state BMP is able to answer the question at which point (Adj-RIB-In, Adj-RIB-Out, Local-RIB) how much and which routes are filtered, passed or when passed where the route attributes were modified. What BMP can't answer is why these routes where passed or when passed, why where the route attributes modified. And as Serpil already explained, for a network operator, if complex and historical evolved route-policy configuration is in place, can be quiet cumbersome to troubleshoot. Especially as route-policy configuration are not standardized and differ between vendors. An there, BMP could bring valuable insights in, which we should not ignore. How about for instance adding three fields to each route in Adj-Post-RIB-In , Local-RIB and Adj-Post-RIB-Out: Action: Passed, Filtered, Modified Place: route-policy name or function within router. An example for functions could be: route-target filter Debug: free text of what has been modified if modified. An example: modified next-hop to 1.1.1.1 I fully understood that adding these fields has its price and therefore it should be addressed and discussed in a new separate draft, especially since Adj-RIB-In is also affected. From my perspective, where I disagree, is that the a filtered flag alone would be enough to address the wish to get more visbility into the filter behavior since it would not explain why it has been filtered. Regarding Serpil's question wherever it would be sufficient only to flag routes if filtered by route-policy. From my point of view I can confirm that this is the most interesting part, but as I described above, I fear that it might be not enough when we start going down that road. Kind regards Thomas Graf ____________________________________________________________________________ Network Engineer Tribe IT Clouds Telefon +41-58-223 84 01 Mobile +41-79-728 80 12 thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> ____________________________________________________________________________ Swisscom (Schweiz) AG IT, Network & Infrastructure Tribe IT Clouds Binzring 17 8045 Zürich www.swisscom.com Postadresse: Binzring 17 8045 Zürich From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Serpil Bayraktar (serpil) Sent: Tuesday, March 20, 2018 7:54 PM To: Paolo Lucente <pa...@ntt.net>; Job Snijders <j...@ntt.net> Cc: grow@ietf.org Subject: Re: [GROW] Dropped Updates in BMP? +1 Not knowing which policy is filtering which route has been the #1 reason for operators not wanting to touch existing policy configuration on the routers AFAIK. Hence the enormous size of policy configs. Not to mention not having an easy way to validate whether a new policy is filtering what it is intended to filter or not. If there is any visibility into why a route was filtered that can be relayed via BMP, it’d be super useful. I do agree that it should probably be another draft as Job suggested. As for those routes that are dropped before even hitting the policy filters (such as due to errors in the path attributes like AS path loops), I think the operators need to step in here to indicate how valuable this information is to them and whether the vendors can provide them without harming the operation of the router or not. Serpil From: GROW <grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>> on behalf of Paolo Lucente <pa...@ntt.net<mailto:pa...@ntt.net>> Date: Tuesday, March 20, 2018 at 11:20 AM To: Job Snijders <j...@ntt.net<mailto:j...@ntt.net>> Cc: Grow Mailing List <grow@ietf.org<mailto:grow@ietf.org>> Subject: Re: [GROW] Dropped Updates in BMP? Minor comment: my understanding is that Reudiger was interested in getting more visibility in what happens between Adj-RIB-In pre- and post- policy. I concur with Tim Evens comment “In order to determine what was "dropped/filtered/rejected/whatever" we do a simple diff between pre-policy and post-policy", which is essentially the same i replied to Reudiger as in what can be done with what we have. Speaking to pmacct users using BMP, the ability to diff pre- and post- policy was found good enough as a starting point to further research what happened to missing routes (through means external to BMP). It would be nice to get to some sort of increased visibility and have a kind of ‘exit code’, as Jeff Haas described it, when a route is filtered (‘f’ flag to be ported to Adj-RIB-In and Adj-RIB-Out?) and I reckon things may get complicated if trying to stretch the concept too much beyond this point. I’d be willing to contribute effort if it is found that there is enough interest. Paolo On 20 Mar 2018, at 14:52, Job Snijders <j...@ntt.net<mailto:j...@ntt.net>> wrote: Hi all, Reudiger Volk mentioned something interesting at the microphone yesterday about getting more visiblity into BGP UPDATES that are rejected/dropped somewhere in the policy chain transitioning from Adj-RIB-In to Loc-RIB. To make a crude route-map example: ip prefix-list allow-ebgp-in permit 192.0.2.0/24 ! route-map ebgp-in permit 10 match ip address prefix-list allow-ebgp-in ! route-map ebgp-in deny 20 bmp-log-code 21438 It would be great to see what UPDATEs get dropped in "route-map ebgp-in deny 20". It would perhaps be quite useful if we can get to the point where you can even attach custom policy-exit codes to the "Dropped Updates" send in this new BMP feed. I can see how this makes operational life easier. RFC 4271 Section 9.1: "The Decision Process selects routes for subsequent advertisement by applying the policies in the local Policy Information Base (PIB) to the routes stored in its Adj-RIBs-In. The output of the Decision Process is the set of routes that will be advertised to peers; the selected routes will be stored in the local speaker's Adj-RIBs-Out, according to policy." Perhaps a series of BMP "PIB" drafts are in order? Is this worthy of a new BMP draft? Are there volunteers? Kind regards, Job _______________________________________________ GROW mailing list GROW@ietf.org<mailto:GROW@ietf.org> https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list GROW@ietf.org<mailto:GROW@ietf.org> https://www.ietf.org/mailman/listinfo/grow
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
