We discussed storing backup ephemeral state. There are a number of
issues that arise if we permit that.
For example, if state gets over-ridden, but preserved, then even though
it is not doing any good, the client which installed the state must
still monitor for any related dependenecies so as to not leave incorrect
pending state.
Which also means that a client has to be able to remove state it has
created, even though that state has been over-ridden. And probably has
to be able to create state which won't take effect. Which in turns
means that you need to be able to read your own effects and the current
state separately.
In general, earlier working group discussion found this to add a lot of
complexity. So our agreement for now is that there is no storing of
non-effecting state by I2RS. Caching or other performance improvements
are for future study.
Yours,
Joel
On 11/2/15 7:39 PM, Russ White wrote:
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
