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

[Jamal Hadi Salim <[e-mail]>]

Joel,

Lets defer this discussion to th meeting time; you may be able
to  convince us or us convince you.
Ignoring the non-modifiable topology issue...
It becomes a usability issue if an LFB instanc  belongs to more than one
topology (more messages).
The maybe purist arguement is : if a node in a graph is tagged "down"
that implies in every topology where this node participates there is no
connectivity to it.

cheers,
jamal

On Tue, Oct 16, 2012 at 9:49 AM, Joel M. Halpern <[e-mail]> wrote:
> 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
>>>>
>>>
>>
>