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

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

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.

My big problem with turning off an LFB is that it is completely unclear 
whatit means for the packet flow.  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.

Put differently, it is not at all clear to we that a instantiated, 
connected, LFB can be meaningfully and safely disabled.

Yours,
Joel

On 10/14/2012 7:02 AM, Jamal Hadi Salim wrote:
> On Sat, Oct 13, 2012 at 7:31 PM, Joel M. Halpern <[e-mail]> wrote:
>> Can the same ffect not already be achievd by the CE refrainign from
>> connecting anything to the input ports of the LFB isntance ntil after it has
>> filled in any of the parameters of interest?
>
> That's one of the approaches we discussed. Two issues we faced:
> a) The LFBTopology is only sensible the FE's modifiabletopology is
> advertised as true. This may not always be the case.
> b) It provided the semantics of a graph link being inactive as opposed
> to the intended graph node (LFB instance) being inactive.
>
> For completion, one other approach we considered was to update
> the LFBTopology row with state - but that is also victim to
> LFBTopology and provides state semantics for a whole graph
> instead of a single node.
>
> cheers,
> jamal
>