Clarification on VERIFY_AND_SAVE & COMMIT

[kishanps]

1. Clarification on VERIFY_AND_SAVE & COMMIT action for SetForwardingPipelineConfig()
   Right now, it looks like these 2 have to go together, meaning COMMIT always refers to the previous VERIFY_AND_SAVE P4info. We are trying to come up with a solution to have the server apply the last previously applied and saved p4info (via VERIFY_AND_SAVE or VERIFY_AND_COMMIT or RECONCILE_AND_COMMIT) when a COMMIT action is specified and want to understand the motive behind the tight coupling to VERIFY_AND_SAVE.

2. Want to understand the reasoning behind the text in VERIFY_AND_SAVE - “any subsequent Read / Write requests must refer to fields in the new config.” Why does the subsequent write requests have to refer to a field which has not been applied yet ?

[kishanps]

@smolkaj for vis.

[jonathan-dilorenzo]

So, for the second question, it think it's because o.w. this line from COMMIT definitely won't work: "The forwarding state in the target is updated by replaying the write requests to the target device since the last config was saved."

However, I think it's not completely clear what it would mean for the forwarding state to be updated here. It seems like it must be cleared first, then updated by replaying, because o.w. how do we know that the forwarding state is compatible with our p4info?