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
