Hi Alia, Alia Atlas <[email protected]> writes:
> 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. As I said, the two notifications will be added in the next revision. However, it is important to note that, by design, the data model in routing-cfg is mainly a skeleton or framework providing placeholders for real stuff (routing protocol or route filter data) to be filled in. As a proof of concept, I can certainly try to write a YANG module that augments the specific items defined in i2rs-rib-info-model, should you find this exercise useful. > > 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. The text of the routing-cfg draft in fact presents an information model, and in a very similar structure as the present draft (routing/router instances, routing tables, routes, but in addition also routing protocol instances and route filters). I think we should be able to agree on a common information model, even if the I2RS WG decides to use something else than YANG for data modelling. > > It's also clear that there are large critical aspects that are missing and > needed (from the I2RS perspective). >From the NETMOD perspective, these critical aspects are eagerly waiting to be >augmented into the existing YANG data model. :-) Lada > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
