Hi, this work, or at least its general parts, is closely related to the following work item of the NETMOD WG:
http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09 I tried to compare these two documents, and IMO the match is pretty good. Paradoxically, the match would be even better if we take one of the previous revisions of the routing-cfg documents because some constraints that were originally present have been relaxed in the meantime (details follow). I think it would make a good sense to coordinate these two efforts, and it should't be difficult. Specific comments: 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". 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." 3. Route attributes, nexthops etc., as specified in draft-nitinb-i2rs-rib-info-model-00, can be easily added into the YANG data model via augmentation. We expect this will be done by future YANG modules defining data models for routing protocols, such as BGP. For example, an entry like your ISO_SYSTEM_ID can be augmented by an IS-IS module. 4. The data model in routing-cfg doesn't define any event notifications yet, though I think there have already been some proposal. I think we can add the two that you mention in sec. 5. 5. Routing tables can be inspected in the same way as other operational state data, i.e., via the standard NETCONF operation <get>. However, we also have two special RPC operations: o active-route: query the routing system for the active route(s) that are currently used for sending datagrams to a destination host whose address is passed as an input parameter. o route-count: retrieve the total number of entries in a routing table. Cheers, Lada Nitin Bahadur <[email protected]> writes: > Folks, > > We have just posted an initial version of the RIB information model. > Looking for feedback and collaborators who can help improve/add-to the > draft. > > Thanks > Nitin > > > On 6/25/13 11:47 AM, "[email protected]" <[email protected]> > wrote: > >> >>A new version of I-D, draft-nitinb-i2rs-rib-info-model-00.txt >>has been successfully submitted by Nitin Bahadur and posted to the >>IETF repository. >> >>Filename: draft-nitinb-i2rs-rib-info-model >>Revision: 00 >>Title: Routing Information Base Info Model >>Creation date: 2013-06-25 >>Group: Individual Submission >>Number of pages: 21 >>URL: >>http://www.ietf.org/internet-drafts/draft-nitinb-i2rs-rib-info-model-00.tx >>t >>Status: >>http://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model >>Htmlized: >>http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-00 >> >> >>Abstract: >> Routing and routing functions in enterprise and carrier networks are >> typically performed by network devices (routers and switches) using a >> routing information base (RIB). Protocols and configuration push >> data into the RIB and the RIB manager install state into the >> hardware; for packet forwarding. This draft specifies an information >> model for the RIB, to build a standardized RIB model, using which an >> external entity (external to the network device) can read and write >> information from/to the RIB. >> >> >> >> >> >>The IETF Secretariat >> >> >> > > > > _______________________________________________ > 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
