Outbound Route Filtering (of which RT Constrain is a type) is really both push and pull depending on how you look at it.
The purpose of ORF is to deliver to a PE only the set of routes associated to community that locally connected CE are members of. When a new CE is configured on a PE that is a member of a community which existing CE were not members of, than the PE requests (pulls) the routes for that new community from it's RR/peers. In the case of NVE and hypervisors, when a VM belonging to a community moves to an NVE which does not have other members of that community then the NVE will request (pull) from it's RR the routes for that community. So, in regards to ORF, the question is not really whether ORF is pull or push but about what the trigger for a pull request should be (VM move, conversational level, etc) and what the pull should be for (community, destination, community+destination). I think the good folk at the IETF can certainly define new types such that ORF based pulls meet real-world requirements. But let's first get proof that the requirements are real-world. Best regards -- aldrin On Sep 27, 2012, at 7:38 PM, Kireeti Kompella wrote: > Hi Thomas, > > On Sep 27, 2012, at 13:54, Thomas Narten <[email protected]> wrote: > >> I doubt that it's worthwile trying to come up with a metric in >> advance. Most likely, we'll just start arguing about the assumptions >> being fed into the mode. I don't see the point in restricting the >> architecture to a "push" model at this early juncture. > > Fair enough. > > My guess is that, once you have both (push and pull technologies), it would > be nice to have a clear understanding of when which would be better. I.e., > build a model ... > > Kireeti > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
