Hi Russ & Andy,

I certainly understand the desire for different behavior when a priority
override happens.
However, this is one area where the working group was extremely clear.  Sue
and I had
ideas of store-if-not-best and handling overwrites and so on.  There was a
very clear
push back against any such complexity.  Feel free to take a read through
the archive.

While it is tempting to expand the scope and functionality of I2RS to
handle this as not
an error, I would ask that we respect the WG consensus and get agreement
and implementations
going on the basics.

We have a serious case of too many saying "This is an interesting soup.
Let's watch it." and
far too few people putting wood on the fire and experimenting.

Regards,
Alia

On Thu, Nov 5, 2015 at 12:57 PM, Andy Bierman <[email protected]> wrote:

>
>
> On Thu, Nov 5, 2015 at 12:10 AM, Russ White <[email protected]> wrote:
>
>>
>> > First, is the case of two I2RS clients modifying the same "thing"
>> > something we consider normal and desirable, or is it an error.  The
>> earlier
>> > discussions was that it is an error.  In discussing the many different
>> kinds of
>> > direct and indirect collateral issues that arise, we concluded that we
>> could
>> > not expect the I2RS agent to be able to determine the "right" thing to
>> do
>> in
>> > the general case.
>>
>> So, assume the following --
>>
>> 1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1
>> 2. In order to move traffic off a "hot link" in a fabric, a
>> client/controller installs a route, 10.1.1.0/24 via 192.168.200.1
>> 3. An attack vector is detected in a flow destined to some host on
>> 10.1.1.0/24 that causes a separate client/controller to install a route,
>> 10.1.1.0/24 via 192.168.150.1 for five seconds
>>
>> If I were the operator who owned this network, I wouldn't call this an
>> "error." I would call this "normal operation," -- in fact, the ability to
>> do
>> the above would be the very reason I would deploy I2RS on the network in
>> the
>> first place. Further, I would expect the entire process to unwind properly
>> and _quickly_. I don't care how it happens, I just want the removal of the
>> second client's route to leave the first client's in the table as the
>> current route, and the removal of the first client's path leave the BGP
>> route as the best path. To go farther, why are there client priorities at
>> all if this is an "error?" If all overwrites of "ephemeral state" are an
>> error, the agent should simply reject any attempt to overwrite any such
>> state.
>>
>>
>
> I agree that a priority override is not an error. In a multi-client
> environment,
> client A is not going to know about the other clients added to the system.
> This is true whether the clients are primary or secondary behind a broker.
>
> The notification to a client that some or all of its data was just
> overridden
> is a separate matter from whether the client wants all or part of its
> data to be removed or altered.
>
> One proposal to the design team is the notion that the server
> supports an advertised (static) number of clients (max client panes).
> Each client must be assigned a priority, such that every client
> has its own pane, so adding a valid edit does not fail. Activating
> the edit is a separate matter. Each client can flush all or part of its
> own pane.
>
>
> :-)
>>
>> Russ
>>
>>
>
> Andy
>
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to