Hi Nitin, Nitin Bahadur <[email protected]> writes:
... >> >>1. What you call "routing instance" is very similar to "router >>(instance)" in routing-cfg. Interfaces are also assigned to each router >>instance, but we don't require (since rev. -03) that the sets of >>interfaces assigned to different router instances be disjoint. One use >>case is that two router instances may be used for different address >>families, e.g., instance A for IPv4 and B for IPv6. Then the same >>interface may be used in A for IPv4 traffic and in B for IPv6. Perhaps >>this also depends on the definition of "interface". > > Interface is not address family specific. It's not clear why one would > need 2 router instances, one per address type. The way I've been modeling One use case, though perhaps not very typical, is the BIRD routing software, which uses separate daemons for IPv4 and IPv6. > this is how I've seen customers use interfaces. They associate all > features with a given interface as part of one domain. So everything > related to a given GigE interface (like routes, VPNs, etc) are managed in > a wholesome way. Right, I guess it's just a matter of definition. And it's fine either way because the routing-cfg I-D also states: Implementations MAY specify additional rules for the assignment of interfaces to logical routers. For example, it may be required that the sets of interfaces assigned to different logical routers be disjoint. > > >>2. Until rev. -05, each routing table was also confined to one router >>instance. This was relaxed based on the following comment of a Routing >>Directorate reviewer (Thomas Morin): >> >>"Allowing multiple "routers" is a good starting point for using these >>specs in the context of RFC4364 >>(MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the >>way the filters are defined would >>not work in the context of RFC4364, where a BGP routing instance in the >>master "router" exports selected >>routes in each of the routing table of each VPN (VRF). The VRF also >>export routes to the master >>instance." > > IMO this is the export-import policy stuff (that I left out on purpose in > rev -00). IMO, import-export between tables in different router instances > should be supported/allowed. But that does not mean the tables need to be OK, then I misunderstood the following sentence in sec. 2.2: "Each routing table MUST belong to some routing instance." I thought this meant that such exports/imports between different router instances are imposible. > in multiple router instances. Based on your knowledge of Yang, do you > think it's not possible to define import-export of routes between tables > in different instances? > > Rest of your comments were data-model specific, which I will defer for now > (we'll take that up on a separate thread). OK. Thanks, Lada > > Thanks > Nitin > > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
