Re: [forces] I-D Action: draft-djjhs-forces-lfbstate-00.txt

["Joel M. Halpern" <[e-mail]>]

I am sorry, I still don't see the problem.

Suppose we have an FE with a non-modifiable topology.  Suppose that 
there is some LFB in the topology that we want to configure, but do not 
want to use.

Fine, do so.
By definition, if we are not using that LFB, we are not directing any 
packets to it.  If the upstream  never sends an packets to it, then 
whether the LFB is administratively enabled or administratively disabled 
is irrelevant.  Remember, the CE knows what it wants, and what it is 
doing.  The admin state of the LFB won't tell it anything it doesn't know.

In essence, this is a mathematical statement.  If we want a predictable 
behavior, then the graph has to avid sending any packets to any non-used 
LFBs.  enabled or disabled is irrelevant.

Yours,
Joel

On 10/16/2012 7:57 AM, Jamal Hadi Salim wrote:
> Joel,
>
> We may have digressed given i hardly disagree with what you said in
> your email below (and it may be orthogonal to our
> goals). Here's what we mainly want to achieve:
> Send config info to a specific LFB Instance. Decide when that info
> becomes active or inactive in the datapath. We want to do
> this in presence of many active graphs within an active FE
> (which receives traffic). Willing to have the LFB instance of
> interest to belong to only one service graph, but more importantly we
> want to achieve this in as fewer steps as possible (on the message
> exchange level).
>
> The disagreement i have is i think you are describing an
> implementation approach. Maybe this is left up to a face to face
> discussion at the meeting.
> Again, our goal is to take the FEState semantic and express
> it at the LFB instance level.
> With FEState there is an equivalent semantic at the coarse granularity
> of the FE i.e CE can update the config and when ready send a single
> message which says "activate" . How the isolation of the FE is
> achieved is up to the implementer. You describe isolation of the FE as
> being achieved by turning off physical ports on the datapath. I
> described an ASIC that could be sent a single message at the register
> level to achieve that same goal.
> As it stands right now, the interpretation of activate/deactivate
> is left up to the implementation. Thats where we draw our
> motivation.
>
> cheers,
> jamal
>
>
>
> On Mon, Oct 15, 2012 at 10:28 AM, Joel M. Halpern <[e-mail]> wrote:
>> I have to strongly disagree.
>>
>> With regard to turning off physical ports, there are two reasons that apply
>> to physical ports, and do not apply to the logical input ports of LFBs.
>> 1) This is a semantic that human beings express.
>> 2) More importantly, the upstream of these physical ports is in general not
>> under the control of the CE.  So the CE & FEs have to be prepared for it
>> doing unexpected things.
>>
>> With regard to CE operation, there is no need for admin-disabling  port.  In
>> fact, doing so will add needless steps to the operation of setting up a new
>> or changed configuration.  When making any configuration change to LFBs, the
>> CE has to
>> a) determine what changes it wants to make.  For modifiable topologies, this
>> may mean planning to create some LFB instances and / or planing to create
>> some links.  For any FE, this will meaning determining what LFB parameters
>> changes it wants to make.
>> b) The CE then evaluates the dependencies between this changes.  It arranges
>> them into a dependency graph.  And then applies the changes from the root of
>> the graph towards the leaves.  If the CE does not do this, then there will
>> be times when the FE will behave in unpredictable and probably undesirable
>> ways.  If the CE does do this, there is never a need to turn off an LFB
>> port.
>>
>> With regard to (b), if that sort can ot be done, the adding admin-disable to
>> individual LFB logical input ports will not help make it possible.
>>
>> As a minor note, there are cases where, n order to preserve te dependency
>> properly, one may have to make certain temporary config changes.  As a CE
>> coder, one can choose between the more complex math to find the stable
>> behavior or having the transient improper behavior. Again, the admin-disable
>> will not help.
>>
>> I will admit that in the above I am assuming that it is irrelevant to try to
>> determine the "meaning" of a topology and configuration in the middle of a
>> change.  With or without admin-disable on logical LFB input ports, such
>> interpretation of what was actually intended as a transient state is
>> probably very hard.
>>
>> Yours,
>> Joel
>>
>> PS: I am happy to discuss this in the meeting in Atlanta if we need to.
>>
>>
>> On 10/15/2012 6:47 AM, Jamal Hadi Salim wrote:
>>>
>>> On Sun, Oct 14, 2012 at 12:42 PM, Joel M. Halpern <[e-mail]>
>>> wrote:
>>>>
>>>> The issue of a non-modifiabe topology requires some though.  In > my
>>>> experiece, one usually can't turn individual LFBs on and off >in such setup.
>>>> Rather, with non-modifiable topologies the input
>>>> ports tot eh FE sre rutnred off, the whole set of LFBs is >configured,
>>>> and then the input ports are turned on.
>>>
>>>
>>> What you just described with "the input ports turned off"
>>> is essentially meant to be signalled by the FEO::FEState being put in
>>> AdminDisable. And i think in this case that would be an
>>> implementation approach (which is of course reasonable).
>>> There are ASICs where you dont have to turn off ports.
>>> You need to bang some registers to turn/off the datapath.
>>> And in that case I would rather set some bits in registers
>>> instead iterating the port list and turn off ports.
>>>
>>> If you assumed we can ignore non-modifiabe topology semantics,
>>> it still looks different and complex (youd have to scan the LFB
>>> topology and turn off every link to that LFB instance).
>>> It will solve one of our stated goals (the race condition aspect)
>>> but would be cumbersome for the HA aspect.
>>>
>>>> My big problem with turning off an LFB is that it is completely
>>>> unclear what it means for the packet flow.
>>>
>>>
>>> The semantics are the same as FEO::FEState
>>> If the FEState is Admin/OperDisable it provides the illusion that
>>> all LFB instances are inactive on the datapath.
>>>
>>>> What are we telling an upstream LFB to do
>>>> when the downstream LFB is disabled?  Drop the packet?
>>>> Or is the CE
>>>> supposed to assume that disabled LFBs are transparent?  Both choices can
>>>> produce extremely improper behavior.
>>>
>>>
>>> Agreed - the FE advertising this capability must be able to handle
>>> the configuration.
>>> Implementation  specific perhaps, but one way is to empty any
>>> control components related to the LFB instance from the datapath.
>>> In our case the FE would store the inactive Instance information in
>>> software
>>> (but not in the datapath) and activation implies storing it into the
>>> datapath.
>>>
>>>> Put differently, it is not at all clear to we that a instantiated,
>>>> connected, LFB can be meaningfully and safely disabled.
>>>
>>>
>>> It may end up being implementation specific as is the
>>> case of FEO::FEState.
>>>
>>> cheers,
>>> jamal
>>>
>>
>