Hi, This raises a data modeling issue. Should every "backup parameter" be modeled explicitly in the YANG module, or can the ephemeral datastore be used for that, without any additional data model objects?
The I2RS architecture supports this "backup" concept (lower priority client), except it requires a notification from the agent and subsequent request from the client to make the backup active. With NETCONF or RESTCONF today, that round-trip will probably take around 500 to 1000 milli-seconds. Probably much worse during high loads. Our original proposal to the design team included a pane of glass for each client (and unique priorities for each client), because some people were talking about sub-milli-sec latency, and I know there is no way NETCONF or RESTCONF is going to support this sort of tight control loop. Whether the server rejects lower-priority edits right away, or whether the agent caches the request in the form of a client-specific pane, the client still needs to observe the data resources with pub/sub and decide whether its own particular state is still relevant. IMO the client complexity is the same either way, especially since the caching is only done if the client requests it. The only difference is likely to be almost a million times faster fail-over to the backup on the server. Andy On Mon, Nov 2, 2015 at 8:32 PM, Susan Hares <[email protected]> wrote: > Russ thank you for kicking off this discussion. It is an interesting > approach. I know that certain RIB implementations allows a back-up route. > > Sue > > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Russ White > Sent: Monday, November 02, 2015 7:39 PM > To: [email protected] > Subject: [i2rs] Conversation on Priority and Panes > > Y'all -- > > After sleeping on the discussion last night, I think the panes of glass (or > is it pains of glass?? :-) ) is still by and large another expression of > the priority concept within I2RS. The concept does bring up one specific > point of interest, however -- what about backup information? Some vendor > RIBs, for instance, allow a routing process to install not only the best > path as calculated by the process -- but if the process fails to install, > some RIB implementations allow the process to place the route in the > "backup > pool." This allows the local RIB process to drop to the "second best path," > in terms of priority, so the local RIB doesn't need to query the routing > processes to switch in the case of a withdraw or change in topology. > > To convert this to I2RS terms, it does seem worthwhile to me to have the > capability for a local agent to accept an install instruction for some > particular ephemeral state, and if the install fails, to hold that state > for > future use. This would apply to any sort of ephemeral data, including that > which is configured locally on the network device. Rather than trying to > think of this as "panes of glass," though, this would convert it to simply > a > backup list of lower priority items the local agent can use in the case of > the failure of the highest priority item currently in use. > > The nice thing about this view is that it doesn't require a lot of changes > at the protocol level. The only thing that needs to be available is the > option for an agent to send three different types of answers to an install > request -- > > 1. This ephemeral state was installed and is now being used. > 2. This ephemeral state was rejected/not installed -- with potential codes > for why (out of range parameter, etc.) 3. This ephemeral state was not > installed, but is being held as a backup. > > Using these semantics, the actual implementation of such a feature is up to > the local agent. It might be that some agents don't know how to hold backup > information, or that it doesn't make any sense to hold some sorts of > information in a backup list. This is fine -- the install can just be > rejected without further note. Locally configured information could simply > be treated as an item on the backup list, such that the priorities can be > considered as always in deciding what to install when any particular action > is taken. > > It seems, to me, that this is a simpler way to consider the same problem > set, and reduces to an actual protocol mechanism that appears (?) to be > fairly simple, and leaves as much flexibility as possible for any given > agent implementation. > > Thoughts? > > :-) > > Russ > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
