This post is redoing the title - so that it links to the original discussion.
Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Susan Hares Sent: Saturday, February 20, 2016 11:44 AM To: 'Joel M. Halpern'; 'Russ White'; [email protected] Cc: ''Alia Atlas'' Subject: Re: [i2rs] Comments on draft-ietf-i2rs-architecture - off list until we get some agreement Joel and Russ: Here's the new section 6.3 text. I've included the differences. I will upload this on Monday am if I've not heard about any other changes from Russ, Joel, or the list. Sue New section 6.3 Changes may originate from either Local Configuration or from I2RS. The modifications and data stored by I2RS are separate from the local device configuration, but conflicts between the two must be resolved in a deterministic manner that respects operator-applied policy. The deterministic model is the result of general I2RS rules, system rules, knobs adjust by operator-applied policy, and the rules associated with the yang data model (often in MUST and WHEN clauses for dependencies). This operator-applied policy can determine whether Local Configuration overrides a particular I2RS client's request or vice versa. To achieve this end, the I2RS data modules have a general rule that by default the Local Configuration always wins. Optionally, a routing element may permit a priority to be to be configured on the device for the Local Configuration mechanism interaction with the I2RS model. The policy mechanism would compare the I2RS client's priority with that priority assigned to the Local Configuration in order to determine whether Local Configuration or I2RS wins. For the case when the I2RS ephemeral state always wins for a data model, if there is an I2RS ephemeral state value it is installed instead of the local configuration state. The local configuration information is stored so that if/when I2RS client removes I2RS ephemeral state the local configuration state can be restored. When the Local Configuration always wins, some communication between that subsystem and the I2RS Agent is still necessary. As an I2RS Agent connects to the routing sub-system, the I2RS Agent must also communicate with the Local Configuration to exchange model information so the I2RS agent knows the details of each specific device configuration change that the I2RS Agent is permitted to modify. In addition, when the system determines, that a client's I2RS state is preempted, the I2RS agent must notify the affected I2RS clients; how the system determines this is implementation-dependent. It is critical that policy based upon the source is used because the resolution cannot be time-based. Simply allowing the most recent state to prevail could cause race conditions where the final state is not repeatably deterministic. Sue -----Original Message----- From: Joel M. Halpern [mailto:[email protected]] Sent: Thursday, February 18, 2016 2:32 PM To: Susan Hares; 'Russ White' Cc: ''Alia Atlas'' Subject: Re: [i2rs] Comments on draft-ietf-i2rs-architecture - off list until we get some agreement Actually, I (and I believe the working group) do not expect indirect interactions to be deterministic. The priority rule is there to make direct interactions deterministic. Indirect interactions were deemed too complex to try to anticipate, and thee is no requirement or exepectation that such be perfectly deterministic. I would even go so far as I to say that if you try to cover all such cases you probably have an intractable problem to solve. Yours, Joel On 2/18/16 2:29 PM, Susan Hares wrote: > Joel: > > See comments below. > > -----Original Message----- > From: Joel M. Halpern [mailto:[email protected]] > Sent: Thursday, February 18, 2016 10:08 AM > To: Susan Hares; 'Joel M. Halpern'; 'Russ White' > Cc: ''Alia Atlas'' > Subject: Re: [i2rs] Comments on draft-ietf-i2rs-architecture - off > list until we get some agreement > > I am missing a step in your reasoning about the dependency case. > > If I have understood you correctly, your concern is that if > 1) I2RS Ephemeral is allowed to over-ride, and > 2) There is a dependency upon something that is owned by local-config, > then: if I2RS over-rides invalid configuration can occur. > > This appears to be a question of what error behaviors we expect > regarding I2RS. I think your concern is that we may have an > over-riding I2RS ephemeral config that an operator can disable by > removing the interface (or more generally the dependent item). > > > Sue: The ephemeral requirements says the I2RS ephemeral state can rely > on a Local configuration for constraints. The interface is a > constraint of the > route. If the constraint changes, the I2RS agent will have to handle it. > > ========= > Joel: I don't see this as a violation of the precedence rules. We > have been very clear that I2RS can have all sorts of interesting > interactions acros elements, and we are not claiming to get them all > right. For example, within I2RS ephemeral we only try to address > direct conflicts. Indirect conflicts, such as the one described here, > are explicitly out of scope for I2RS conflict resolution. > > Sue: I do not see it a violation of the architecture precedence rule > of local configuration over the operator-applied policy. I still see > that the i2rs architecture local-configuration rule section was > incomplete if we want the solution to be deterministic. > > Joel: Given that the problem is out of scope for I2RS-I2RS, I don't > see why it would suddenly be in scope for the I2RS-LocalConfig case. > > Sue: It is not out of scope for I2RS models. The data models must > have enough details to be deterministic on what happens with the "local-config" > default, the operator-policy, and the interaction of the data models. > > Joel: Have I understood the problem you are raising correctly? If so, > does my response make sense? > > Sue: Not quite, but the discussion is very important to helping me > correct and push through the data models: so please continue to aid > me. I still see the rules are: > 1) architecture: default to local configuration wins > 2) operator-applied policy: Let I2RS win > 3) data model logic application of "Let I2RS WIN" > 3-a) I2RS route-vs- local-config route - operator applied priority ok > 3-b) I2RS route vs. interface local - operator-applied priority not valid. > > > I thought this should be in the architecture in 6.3 as a heads-up that > operator logic must fit within the data model. > > Sue > > ============= > > On 2/18/16 9:53 AM, Susan Hares wrote: >> Joel: >> >> The last thing I want to do is to make a major design change as the >> chair. It is inappropriate. >> >> I had seen this problem as part of the multi-head problem that was >> being discussed in November and December. I thought we had wisely >> come up >> with a solution for the 2 pane glass case. See rest of comments below. >> >> Thanks for being patient with me. >> >> Sue >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:[email protected]] >> Sent: Thursday, February 18, 2016 9:35 AM >> To: Susan Hares; 'Russ White' >> Cc: ''Alia Atlas'' >> Subject: Re: [i2rs] Comments on draft-ietf-i2rs-architecture - off >> list until we get some agreement >> >> As I have tried to say repeatedly, if you think we made a wrong >> design choice, you have a perfect right to argue for a change. Making >> a change of this magnitude without calling attention to it seems to >> me VERY inappropriate. >> >> Sue: If this is a major change, you are correct. I had not seen it as >> a change but a clarification of text in 6.3. >> >> This email is the first time I have seen an explanation of why you >> think there is a problem. >> >> The two cases you describe are VERY different. >> >> Sue: I am glad I am finally being clear. I agree they are very >> different >> >> Joel: In the case of a change to a dependent item, unless the I2RS >> client applied a change to the dependent item, local-config still >> owns that. So it can change that, no matter what the over-ride >> policy is. >> >> Sue: The problem is not the "interface" but the fact the route >> depends on the interface. I agree, the dependency must fail. This >> issue means when the model depends on local configuration and does >> not own it, I2RS could not allow the operator to set an "I2RS wins" policy. >> It simply does not make sense for Local configuration. >> >> Joel: Conversely, in the case of routes for the same prefix, I do not >> see how the model can decide what should over-ride. Fundamentally, >> if the operator sets the knob so that local config is stronger than >> I2RS modifications, the operator is choosing to restrict the use of >> I2RS in his system. We have agreed he should have that choice. >> >> Sue: The case I am trying to write about is when the operator-applied >> policy sets the I2RS wins policy. In this case, the operator wins >> for this portion of the mode. >> >> Niether case you describe seems to need a per-model switch. >> >> Sue: I think what we are struggling on is the define of a "per-model" >> switch. What I am trying to write-up this this specific case. In some >> portions of the I2RS Data Model, the "Operator-applied" policy cannot win. >> >> In some portions of the I2RS Data Model, it is a choice of the >> operator. The I2RS RIB route has both so it must be carefully >> described in the I2RS RIB IM/DM model what the operator-applied >> policy will or will not do. If we do not, we will have problems in >> the vendor assumptions and interoperability. I was trying to factor >> this back > into >> the architecture in this section. Does what I'm trying to do make >> sense now? If not, I need to make this clear. >> >> Joel: It is true that certain use cases will not work for operators >> who set the priorities certain ways. That is their choice. Note that >> we have a limited form of flexibility in that an operator can set >> different clients to different priorities. Thus, the choice becomes >> theirs, not the models. Which is consistent with the agreement that >> if the operator wants to shoot their foot, it is their foot to shoot. >> >> Sue: I really do not understand what you are trying to say here. I need >> an example of what you mean by limited form of flexibility. I agree if >> an operator wants to shoot themselves in the foot, it is there foot. >> >> Yours, >> >> Joel >> >> On 2/18/16 9:22 AM, Susan Hares wrote: >> >> > Russ and Joel: >> >> > >> >> > We agree upon this statement: >> >> > The deterministic model is the result of general I2RS rules, >> system >> >> > rules, knobs adjust by operator-applied policy, and the rules >> >> > associated with the yang data model (often in MUST and WHEN >> clauses for dependencies). >> >> > >> >> > What I am really trying to refine is the question Russ White added: >> >> > "Should the agent always be able to override the local >> configuration, >> >> > or the local configuration should always be able to override what >> the >> >> > agent installs?" >> >> > >> >> > I used two cases for an approved model: I2RS RIB For dependency >> (Route >> >> > depending on egress interface), if I2RS ignores the >> >> > configuration change to the dependent clause cause a problem. For the >> >> > conflicting case of two routes with the same prefix (I2RS route >> and >> >> > configuration route) - that the I2RS agent could ignore the local >> >> > configurations routes. I do not understand how I2RS can work for >> DOS, if >> >> > we do not allow the operator-applied policy to allow the router >> to >> >> > keep the DoS route even if the NM configuration software tries to >> update it. >> >> > >> >> > The topology model and the I2RS FB-RIB have similar problems. >> >> > >> >> > We have approved data models and the architecture conflicting. I >> was >> >> > hoping my rule set could >> >> > >> >> > 1) architecture design - by default local config wins >> >> > 2) system design - can be either default local config wins or >> priority >> >> > (recommend local config wins) >> >> > 3) policy-applied by operator - local config/priority >> >> > 4) Model based policy - allow operator to specify specific >> over-write >> >> > for routes in features. >> >> > >> >> > Sue >> >> > -----Original Message----- >> >> > From: i2rs [mailto:[email protected]] On Behalf Of Russ White >> >> > Sent: Wednesday, February 17, 2016 9:31 PM >> >> > To: 'Joel M. Halpern'; 'Susan Hares'; [email protected] >> <mailto:[email protected]> >> >> > Cc: ''Alia Atlas'' >> >> > Subject: Re: [i2rs] Comments on draft-ietf-i2rs-architecture >> >> > >> >> > >> >> >> The working group has agreed that such priority can always be applied. >> >> >> An operator can choose to not to. But an individual model can >> not >> >> >> say "priority does not apply to this model." >> >> > >> >> > I read what Sue has proposed in the opposite way -- that there is >> a >> >> > per model flag that says the operator may not override the >> priority on >> >> > this particular model through local configuration. I suppose the >> >> > result might be the same, but the wording implies this is >> something to >> >> > be used sparingly, or rather in the truly exceptional case where >> >> > overriding the policy with local configuration could cause major >> problems. >> >> > >> >> > The only real question comes down to this -- should the agent >> always >> >> > be able to override the local configuration, or the local >> >> > configuration should always be able to override what the agent >> >> > installs. Adding a bit here or there isn't going to make this any >> more >> >> > or less complex, it's just going to mean either interpreting >> equal >> >> > priorities as not truly equal, or having an explicit bit that >> >> > indicates intent. The functionality needs to be there either so, >> so the complexity seems to be there either way (?). >> >> > >> >> > :-) >> >> > >> >> > Russ >> >> > >> >> > >> >> > _______________________________________________ >> >> > i2rs mailing list >> >> > [email protected] <mailto:[email protected]> >> >> > https://www.ietf.org/mailman/listinfo/i2rs >> >> > >> > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
