Then we really have to write up use cases, settle on requirements and decide on the protocol.
Dean On Dec 8, 2014, at 11:48 AM, Russ White <[email protected]> wrote: > >> What state do we want to change via I2RS? > > The original intent was specifically state in the routing table, not -- > >> As far I know, we wanted to allow i2rs agent to change any supported state >> on the device. If that is still the case, then we need to go through the > > Or rather, the only supported state was routing table state. The original > intent was, essentially, to allow an off box process to interact with the > local routing table just as an on box routing process might -- same speed, > same atomicity, etc. In other words, the router could run BGP locally or > remotely without the router, locally, knowing the difference. The major > conflict in this realm is whether this should include such things as > modifying a community string on a specific BGP route within the BGP process > itself. I don't know that we ever resolved this specific question. > > If we've decided to change routing protocol configuration, packet filters, > and all the rest, then I would suggest we should break the work up into two > pieces -- one that covers the original (minimal) intent, and another that > covers the routing protocol configuration pieces. The configuration pieces > are more "full YANG" in nature, while the original intent work could use > YANG models, but would clearly not need (nor want) locks, multipart commits, > etc. > > :-) > > Russ > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
