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

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 13 Oct 2012 11:39:34 -0400

New draft.
Something buggy about the submission tool chops author information
off. I reported it as a bug.

cheers,
jamal

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Sat, Oct 13, 2012 at 11:19 AM
Subject: I-D Action: draft-djjhs-forces-lfbstate-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : ForCES LFB Instance State
        Author(s)       : Damascane M. Joachimpillai
                          Mojatatu Networks
        Filename        : draft-djjhs-forces-lfbstate-00.txt
        Pages           : 7
        Date            : 2012-10-13

Abstract:
   The ForCES LFB Topology currently defines that once an instance of an
   LFB class is created it becomes immediately active in the datatapath.
   This document makes a slight extension to add state to an
   instantiated LFB class allowing the CE to decide when an LFB instance
   becomes operational on the datapath.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-djjhs-forces-lfbstate

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-djjhs-forces-lfbstate-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 13 Oct 2012 19:31:40 -0400

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?
The normal sequence I would expect would be:
Instantiate the LFB
Set the elements to the desired values
connect the output ports of the new LFB to the proper places in the topology
connect the input ports in the lfb to the proper paces in the topology
i necessary, change tables in other lfbs to make use of these new links.

I am missing the reason for havig a new state for the LF a a whole.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 14 Oct 2012 07:02:56 -0400

On Sat, Oct 13, 2012 at 7:31 PM, Joel M. Halpern <[email-masked]> wrote:
> 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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 14 Oct 2012 07:04:59 -0400

Meant:

On Sun, Oct 14, 2012 at 7:02 AM, Jamal Hadi Salim <[email-masked]> wrote:

>  but that is also victim to LFBTopology

"victim to modifiabletopology..."

 cheers,
 jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 14 Oct 2012 12:42:09 -0400

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 15 Oct 2012 06:47:14 -0400

On Sun, Oct 14, 2012 at 12:42 PM, Joel M. Halpern <[email-masked]> 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.

> connected, LFB can be meaningfully and safely disabled.

It may end up being implementation specific as is the
case of FEO::FEState.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Oct 2012 10:28:56 -0400

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.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 16 Oct 2012 07:57:21 -0400

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 <[email-masked]> wrote:
> 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.
> 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
>
>>> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Oct 2012 09:49:40 -0400

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 17 Oct 2012 06:59:43 -0400

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 <[email-masked]> wrote:
> 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.
>
> 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.
>
>>> apply
>>> not
>>> In
>>> this
>>> arranges