Hi Lada,
On Tue, Jun 24, 2014 at 5:53 AM, Ladislav Lhotka <[email protected]> wrote: [removing fine conversation] > > [Alia] We described the arbitration rules in Section 6.3 of > > draft-ietf-i2rs-architecture-03. > > I guess we have to think about a proper representation of operational > state and ways for tagging its contents or otherwise signalling what caused > a particular change. > [Alia] I think that this is actually implementation-dependent and find the idea of trying to tag operational state to be excessively complex and downright scary. IMHO, the interaction needs to be between the config system and I2RS. > For instance, if a configured static route is not present in a RIB > (operational state), it may be because > > - the next hop wasn't reachable when the static route was configured, or > [Alia] I think this is a bad example. The route can still go in - it's just not active. Anyway, that's expected to happen in I2RS. > - the I2RS agent deleted it. > In that case, the I2RS agent should have notified the config, IMHO. The NETCONF server should be able to discriminate between these two cases > because its action (reinstall the route or not) may depend on it. > With a better example, yes. Alia > Lada > > > > > > >> > > >> > So one module, three trees, an additional YANG substatement for a leaf > >> > that is writable by I2RS. > >> > >> Rather than inventing new annotations, I'd rather like to see making > YANG > >> less NETCONF-specific so that it could directly define schema and > >> constraints for other datastores such as the one for I2RS. > >> > > > > [Alia] Please - I think there are different assumptions... > > > > Regards, > > Alia > > > > > >> > >> Lada > >> > >> > > >> > Tom Petch > >> > > >> > > >> >> > 6.4.2" o writing policy information such as interface attributes > >> > that > >> >> > are > >> >> > specific to the routing protocol or BGP policy that may > >> > indirectly > >> >> > manipulate attributes of routes carried in BGP. > >> >> > > >> >> > o writing routes or prefixes to be advertised via the protocol" > >> >> > I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB > but > >> > the > >> >> > I-D goes on to say > >> >> > " direct modification of the link-state database MUST NOT be > >> > allowed" > >> >> > (which I have seen on the list w.r.t. the BGP RIB). > >> >> > > >> >> > or > >> >> > > >> >> > 8" The interaction of state installed via the I2RS and via a > >> > router's > >> >> > configuration needs to be clearly defined." > >> >> > which again implies that I2RS and C/N/S are writing to the same > >> > data. > >> >> > >> >> *Maybe.* > >> >> > >> >> In some cases, the overlap with config state will be quite obvious > and > >> > your > >> >> observation will strongly hold. > >> >> > >> >> In other cases, I think a better perspective is that I2RS injected > >> > state is > >> >> effectively like that of another routing protocol. > >> >> > >> >> If you'd like to argue that BGP is effectively the same as C/N/S... > >> > well, if > >> >> we're talking Flowspec I might agree. :-) > >> >> > >> >> > The examples of data that can be changed are few, such as > >> >> > "For example, the interaction with OSPF might include modifying the > >> >> > local routing element's link metrics, announcing a > >> > locally-attached > >> >> > prefix, .." > >> >> > which leaves me wondering, do you expect an OSPF YANG model to be > >> > unable > >> >> > to change a link metric:-) > >> >> > >> >> Sure. In a highly dynamic fashion? With a fallback to a default > >> > config when > >> >> the application is done? > >> >> > >> >> By comparison to some vendor specific features, it's somewhat the > >> > difference > >> >> between a policy database (config) and the dynamic policy API that > >> > doesn't > >> >> require a system reconfiguration event. If you want to point out > that > >> > the > >> >> relationship is strong and that the defining differences are shallow > - > >> > you > >> >> could very well be right in those contexts. > >> >> > >> >> Again, we don't expect I2RS work to supplant netconf/yang. We expect > >> > to > >> >> leverage the work. > >> >> > >> >> > If I2RS were aiming at a higher level, say specifying policy and > >> > have > >> >> > the system translate that into actual config changes I would > >> > understand > >> >> > that, but I do not see I2RS going that far, rather when I2RS says > >> >> > policy, I think it means changing a community (config again) or > some > >> >> > such ie more of an implementation detail than a high level > strategy. > >> >> > >> >> I hesitate to frame it this way, but one example application is a > form > >> > of > >> >> SDN. The front end says "provision this VPN" to a data model for > that > >> >> purpose. The fact that it may go behind the covers via client->agent > >> > and > >> >> eventually install ephemeral netconf state is an implementation > >> > detail. > >> >> > >> >> If you want to argue that such a higher level model is simply > netconf, > >> > then > >> >> perhaps we should de-charter and do all of the work in that group. I > >> > was, > >> >> however, under the impression that work for various models was being > >> > pushed > >> >> to be done in appropriate working groups. :-) > >> >> > >> >> -- Jeff > >> > > >> > _______________________________________________ > >> > 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 > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
