Subject: [forces] Avoiding need to issue a draft every time WAS(Re: FEO events

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 20 Nov 2014 09:57:04 -0500

As i was saying in the FEO email - the idea that i have to send
draft updates for every component or event is becoming
burdensome. I have quiet a few but dont have the energy to
publish them given the process.
In the last few months we have implemented a few LFBs based
on open source datapath code. In all cases, there is a continous
stream of new LFB components initially with trickles down afterwards
to what seems to be stability. "Stability" in some cases means we
have one new component added every 2-3 months.
IOW, *churn is a way of life*.
Clearly our current model is going to be burdensome with heavy
standardization process (some of it bordering on the ridiculous).

The fact that i have to suffer through this for some time now
because of the pace at which opensource is moving and recent
comments from  Julian Reschke on why we dont even need to revise
versions re-ignited this issue for me.

Two approaches come to mind for ForCES:
a) publish a base LFB document - we then have a living document
somewhere which gets updates. There may be no point in coming back
to the IETF after this.
b) build discoverabillty in. Something along the same line of get properties
semantics we have but that returns all the supported components for example.

At least our implementation is adding #b but it is proprietary. I just wanted
to bounce this off the list first and see what at least the usual suspects feel.

Thoughts?

cheers,
jamal

On Thu, Nov 20, 2014 at 9:31 AM, Jamal Hadi Salim <[email-masked]> wrote:
> I have a use case for a control app needing to know when
> an LFB class instance is created or destroyed (without polling
> for changes). I have added (and currently coding) the attached patch
> to FEObject LFB.
>
>  Is there any objection to this approach?
>
> It is becoming painful that i have to submit a draft every time we make
> such a small change. This generally speaks to the issue of "standards"
> and IETF in general than anything else. I will make another posting
> so this thread doesnt go on a tangent.
>
> cheers,
> jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 Nov 2014 10:32:34 -0500

I think that there are several issues combined here.

We already have mechanisms so that anyone can define LFBs.  And that 
includes new subclasses of existing LFBs.  Note that he information as 
to what LFB classes and subclasses an FE supports is easily 
discoverable, by design.

There is the question of whether event mechanism should be more easily 
extended than a new subclass.  I have trouble seeing how we could do 
that, since in many instances it will require different code in the FE 
to generate new events.

Then there is the question of changes to the FEO (or FEPO).  For 
itneroperability, those have to be very stable.  In this case, for 
example, if your CE needs those events, you can only work with FEs that 
have been upgraded to generate those events from the FEO.   If we allow 
random changes to the FEO, the probability of interoperability between 
independent implementations is very low.  So while I am sympathetic, I 
am reluctant to go down a path the makes interoperability harder.

Yours,
Joel

On 11/20/14, 9:57 AM, Jamal Hadi Salim wrote:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 20 Nov 2014 10:50:17 -0500

On Thu, Nov 20, 2014 at 10:32 AM, Joel M. Halpern <[email-masked]> wrote:
> includes new subclasses of existing LFBs.  Note that he information as to
> what LFB classes and subclasses an FE supports is easily discoverable,
>by design.
>

That part works well.

Lets put FEPO/FEO to the side for the sake of discussion.
Say i defined a port LFB and I publish it and it ends up being RFC.
And then two months down the road i would like to add a new
component - the process requires me to publish a new document
and go through the same publication. That is manageable if the
churn stops at some point. It never stops in open source.
So the idea that i have to create a document and go through a standards
process doesnt scale.

> extended than a new subclass.  I have trouble seeing how we could
> do that,
> since in many instances it will require different code in the FE to generate
> new events.
>

I think the sub-classing issue also works well. What i am refering to
is more class "augmentation" than it is sub-classing.

> itneroperability, those have to be very stable.  In this case, for example,
> if your CE needs those events, you can only work with FEs that have been
> upgraded to generate those events from the FEO.   If we allow random changes
> to the FEO, the probability of interoperability between independent
> implementations is very low.  So while I am sympathetic, I am reluctant to
> go down a path the makes interoperability harder.
>

We can make an exception for FEPO/FEO. But think of other
classes which merely require a new component augmented
(not subclassing).

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 20 Nov 2014 10:58:47 -0500

On Thu, Nov 20, 2014 at 10:52 AM, Joel Halpern Direct
<[email-masked]> wrote:
> Subclassing is precisely designed to provide augmentation.
> You can also do associated classes / instances (which is what folks usually
> get with augmentation) but I prefer subclassing.
>

Sub classing requires a new class identity.

If i defined a port LFB and then inherited into
a gre LFB it makes sense because I need most of the fields
port has to offer; i can override some of them and i
can augment.

But all i wanted was to add a new field to gre meaningful
to gre, it doesnt make sense i go and subclass that.
My initial thinking (before Julian commented) was we change
the version. The scaling problem i am describing here is
this idea of adding new fields in self-contained LFB classes
is the way of life in open source. And people survive fine without
versioning.

cheers,
jamal

> Yours,
> Joel
>
> On 11/20/14, 10:50 AM, Jamal Hadi Salim wrote:
>>
>>> example,

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 20 Nov 2014 10:52:47 -0500

Subclassing is precisely designed to provide augmentation.
You can also do associated classes / instances (which is what folks 
usually get with augmentation) but I prefer subclassing.

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 20 Nov 2014 11:13:20 -0500

You can always create parallel classes (gre-augmenting-class1) which are 
used just to hold extra configuration without being in the data path. 
Yes, it is a bit awkward as you can have the back-pointer but no 
forward-pointer.  But it works.  And it requires no RFC.  Just use the 
FCFS portion of the registry.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 20 Nov 2014 11:26:48 -0500

On Thu, Nov 20, 2014 at 11:13 AM, Joel Halpern Direct
<[email-masked]> wrote:
> used just to hold extra configuration without being in the data path. Yes,
> it is a bit awkward as you can have the back-pointer but no forward-pointer.
> But it works.  And it requires no RFC.  Just use the FCFS portion of the
> registry.
>

It is awkward because it is "parallel" and because I
will have to go looking for your document.
What i am proposing is discoverability. I can query the FE to tell
me about a class components, their types etc.

cheers,
jamal

>>> usually
>>>>> to