On 4/19/17, 10:03 AM, "Jared Mauch" <[email protected]> wrote:
Jared: > Are you saying that IOS-XR is non-compliant with 9.1.1 because it does not > have “bgp > unsafe-ebgp-policy” as the default? No. I wasn’t talking about any specific implementation. One of the reasons I like your document is the fact that rfc4271 is not specific about what should be done if there is no policy – it just says that policy may be applied. From that point of view, the XR implementation is neither compliant nor non-compliant. > At what point does the Cisco implementation make that decision? > > We seem to be triangulating on where in the exact decision process people are > considering a route feasible or ineligible, can you speak to your > implementation? That > may provide guidance in documenting the IOS-XR practice. The XR implementation makes the decision while processing the Update messages. Specifically, it drops all the routes from a peer without an incoming policy configured. IOW, it acts as if a deny-all filter existed. In the conceptual model in rfc4271, the routes are not even put in the Adj-RIB-In. Compared to the current text (in -05), there would be no routes to mark as ineligible in 9.1.1. The text I proposed also assumed that the routes would at least be received/stored. If you want the same behavior as XR then you would have to make the change in Section 9. (UPDATE Message Handling). Alvaro. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
