We got it. On Wed, 19 Apr 2017 at 20:45, Alvaro Retana (aretana) <[email protected]> wrote:
> 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 >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
