Hi Lada, The draft you mention is certainly of interest - particularly if I2RS requirements for a data modeling language result in selecting YANG.
A couple quick points on your comments though. The next-hops are largely the POINT of this info-model. The organization into route-tables and then route-instances allow different ones to be applied to different interfaces and such. So, saying that the nexthops can be easily added via augmentation is saying that a very key feature is not yet there. Similarly, the event notifications are also a key point of the info-model ; that is how different i2rs clients can learn dynamic information. Having a comparison and thinking about how to extend the existing YANG model is certainly interesting - but I think it's important to get and agree on the info-model first. It's also clear that there are large critical aspects that are missing and needed (from the I2RS perspective). Alia On Wed, Jun 26, 2013 at 8:42 AM, Ladislav Lhotka <[email protected]> wrote: > 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 >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
