Lada, Your enthusiasm is awesome - and I totally agree on trying for a common info-model! I just don't want to assume that everything has to be expressed in the hierarchy of YANG. I think that Joel had some opinions on the different expressiveness in different data-models. It's likely that the RIB info-model is a good place to start exploring that and helping to derive requirements.
I do think that the RIB info-model isn't expecting the "real-stuff" to come from elsewhere - but rather is expressing this particular layer fully. Before you start trying to write a YANG module to do the augmentation, you probably want to touch base with Nitin and see where he is on that (other than on Pacific Time). Regards, Alia On Wed, Jun 26, 2013 at 10:20 AM, Ladislav Lhotka <[email protected]> wrote: > 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
