> 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
