----- Original Message ----- From: "Ladislav Lhotka" <[email protected]> To: "t.petch" <[email protected]>; "Susan Hares" <[email protected]>; "'Edward Crabbe'" <[email protected]>; <[email protected]> Sent: Thursday, April 24, 2014 3:27 PM > "t.petch" <[email protected]> writes: > > > ----- Original Message ----- > > From: "Susan Hares" <[email protected]> > > To: "'t.petch'" <[email protected]>; "'Edward Crabbe'" > > <[email protected]>; <[email protected]> > > Sent: Wednesday, April 23, 2014 5:21 PM > >> Tom: > >> > >> 100% agree with your comments. I2RS cares whether it is read-only or > >> read-write. My work toward the revision found: > >> > >> - RBNF RBNF did not even allow you a place to r/w or r-only or > > permissions > >> (needed for security, but that's my next draft). > >> - The yang tree I wrote was r-w for config, but did not express the > > ro-only > >> tree. I wanted some feedback to figure out why I had 2 write 2 trees. > >> (your telling me it is a yang short-coming). > > > > Sue > > > > That is a feature of YANG. Spend half a day on the netmod WG archives > > for 1H2013, particularly May and June and for interfaces-cfg, and all > > will be clear. > > > > As Ladislav said on 2May13, > > > > "In the current model, the operational state data are not present unless > > the corresponding entry in the "interface" list is *configured*. So, > > what I have in mind is a data tree like this: ..." > > > > That is, 'config false' nodes under a 'config true' node do not get > > instantiated in the data model unless and until the 'config true' node > > is configured. So if you have the one routing table, you will be unable > > This issue only affects 'config false' data appearing in the subtree of a 'config true' node. > In my opinion, such a data organisation should be generally avoided, and that's why we now have configuration and state data in separate trees. > > > to see the routes learnt via BGP - 'config false' - unless and until you > > configure the table by creating a static route - 'config true'. > > Note this has never been the case in the ietf-routing module. Routing tables (later renamed to ribs) were always "pure" state data and the default rib for every address family is supposed to be present independently of any configuration. > > > It is a tenet of YANG so fundamental, so basic, that I know of nowhere > > where it is written down:-( > > Please see the definitions of system-controlled versus user-controlled list entries in sec. 4.1 of draft-ietf-netmod-routing-cfg-13. > > I also think think is no idiosyncrasy of YANG, just the way how most systems and their CLIs work.
Is it, though, the right approach for I2RS? I see the rationale of I2RS as being able to take a holistic view of the routing system, not one based on where the information is coming from (a view that may make sense when building boxes or installing them). Rather, I am minded of problems I have been called upon to resolve which are the result of misconfiguration, misconfiguration which is not apparent because the integrated view of what is controlling the box is not available. For example, a static route is inserted to circumvent a quirk of topology, the quirk is fixed but the static route is not removed, the topology changes again and that static route becomes a liability. Being able to see everything at once makes the problem apparent, looking for a configuration error or a BGP error separately is fruitless. My sense is that I2RS needs an integrated view whereas NETCONF/YANG focus on the configuration (as their RFC explicitly state). YANG is a good start, but as Andy said at IETF89, not enough. Tom Petch > Lada > > > > > Tom Petch > > > > > >> - UML seems to be able to handle read/write variants, and I'm looking > > to see > >> if graphical tools will help the developer. > >> > >> Not shown in the reduction: > >> ... And I started working on BGP, ISIS, RIP.. only to find some of > > these > >> issues you mention. DCHP and NTP. Any suggestions or help would be > >> gratefully accepted. > >> > >> I will continue to try to get more details on Yang++ and ForCES to see > > how > >> many wheels fall off. > >> > >> Sue > >> > >> -----Original Message----- > >> From: i2rs [mailto:[email protected]] On Behalf Of t.petch > >> Sent: Wednesday, April 23, 2014 12:08 PM > >> To: Edward Crabbe; [email protected]> > >> YANG (with NETCONF) is designed for writing configuration and reading > >> everything else, and does an excellent job at it. Trouble is, for me, > > that > >> configuration doesn't mean what I think of it as; it means, in the > > YANG > >> context, what you might put in through the CLI and it excludes > > everything > >> else, such as data learnt via a protocol. > >> > >> Take routing. A static route is configuration; anything learnt, via > > BGP, > >> IS-IS, RIP etc, is not configuration (and is read only). > >> > >> An interface configured automatically on a hot-plugged card is not > >> configuration; adding 'ospf passive' is. > >> > >> And so on, for DHCP, NTP, ..... > >> > >> In practice, this means that the YANG model comes in twin sets, one of > >> read-write configuration and one of read-only not-configuration (as > > can be > >> seen in the current I-Ds that the netmod WG is producing) with no > > formal way > >> in YANG of relating the one to the other. So if you want e.g. the > > routing > >> table, the host software has to know where to look and how to combine > > the > >> pieces to produce a coherent picture (and then you cannot edit most of > > it). > >> > >> So if I2RS never wants to write anything to a router, YANG is fine; if > > I2RS > >> is only producing a Information Model (and ignoring whether or not > > data is > >> read-only or read-write), and not moving on to an implementation, then > > YANG > >> is fine. > >> > >> Rather, as Andy Bierman said at IETF89, likely I2RS would need an > > extension > >> to YANG, a new sub-statement for all data objects, semantics not too > > clear > >> but designed to separate out the not-configuration, learnt via a > > protocol, > >> 'editable-state' (and in doing so, making it read-write - but still > > 'config > >> false'). > >> > >> Yes, YANG allows for such extensions but it seems to me that I2RS > > would then > >> be getting YANG++ (and NETCONF++), once the necessary work has been > > done. > >> > >> Tom Petch > >> > >> > >> ----- Original Message ----- > >> From: "Edward Crabbe" <[email protected]> > >> To: <[email protected]> > >> Sent: Friday, April 11, 2014 6:50 PM > >> Subject: [i2rs] consensus on I2RS protocol and model > >> > > > > _______________________________________________ > > 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
