Subject: Re: output port groups WAS(Re: Revised LFB input/output text

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 15 Jul 2004 09:00:21 -0400

Joel,

Is this was the last discussion we had?

To be honest i am not sure making that change would be sufficient
or even needed. What i am looking for could be just better explanations
rather than cutting out "features".
The answer could be "this is easier to model with XML".

How about we take a small step back. Lets talk about ports and their
semantics. Put aside the groups for now.
I apologize in advance since we may rehash some of that past discussion.

To begin with i think that theres inconsitency between input and output
port sections in the text. The output text seems to be talking about
those appendages out of LFB _classes_; the input section seems to be
focussing on LFB _instances_. The later is more appropriate if you talk
about installed policies (in the shape of a topology graph). This may
explain some of the confusion at least on my part.

So item 0: Can we agree on the semantics to be centred around
topological view?
There are instances in particular when you involve classifiers (which we
lump under LFBs) that it is more intuitive to talk about LFB classes.
But even in such cases, you can still draw out topological
representations based on LFB instances.
Heres an example (ignoring input port):

V4fwding entry index X --boundto-->
NH entry index Y --boundto-->
Src address table index Z --boundto-->
egress port A.

In other words although you can use figure 3.d to represent an IPV4 LPM
class output, the above is representative just as well if not better.
The connections are bound at policy installation time

Item 1:
So what exactly is a port and what makes a port unique?
Actually one step back. What is an input or output? Is it more
appropriate to talk about in/outputs into/outof an LFB or is it out/into
an LFB instance?
What is the criteria for making an in/output unique?
>From reading the text that a out/input may produce/consume multiple Ps
and Ms. So we can rule out uniqueness based on those two parameters out.
Another criteria to select a unique in/output is by type of previous of
nexthop LFB instance. Is this the criteria?

Lets resolve this then move on to the next item which is grouping of
said ports. Hopefully we can reach some consensus.

cheers,
jamal

On Fri, 2004-05-14 at 17:23, Joel M. Halpern wrote:
> Would it sufficiently address your concerns if in the definition of the
> rules for LFB class definition (the schema for the LFB class XML) for
> output ports from an LFB, the definition allowed any number of named
> singleton output ports, and only allowed up to one named output port group?
> Would you like a similar restriction on the definition for the input side?
>
> If that would leave you significantly more comfortable, I am willing to
> accept that.
>
> Yours,
> Joel M. Halpern
>
> PS: Just to be clear, I do not think that the protocol or the LFB class
> schema will be more complex if we allow multiple groups.  Since the LFB
> class definition will only be more complex it actually uses multiple output
> groups, I would prefer that the schema allowed for that.  However, since it
> seems likely that LFB classes which should use multiple groups are rare, I
> can live without the capability.
>
>
> At 10:15 AM 5/14/2004 -0400, Jamal Hadi Salim wrote:
> >On Wed, 2004-05-12 at 12:35, Deleganes, Ellen M wrote:
> > > I should have been clearer in the first paragraph. In the last sentence
> > > what I really meant to say is: I don't believe the FE model intends to
> > > disallow an implementation from specifying multiple singleton outputs. I
> > > view the output group as a convenient concept or notation, to describe
> > > multiple outputs with similar characteristics. Whether an array is used
> > > to specify the members of the group or individual names are given to
> > > each singleton output is completely up to the implementer. It doesn't
> > > take that much imagination to see that individual outputs within an
> > > output group could be specified as individual units. It is slightly more
> > > difficult to determine which outputs have enough in common to put into a
> > > group, and the model team is attempting to describe when it is
> > > appropriate to group outputs.
> >
> >The logic doesnt make sense. Lets see:
> >You create something called a output group and then by induction logic
> >create even more extensions to it. Somehow you overlooked if there was a
> >requirement for it to begin with? Why is this an afterthought?
> >
> >The problem is i actually think you have a reason for it - which maybe
> >implementation specific. I wish you would come out and describe what it
> >is because you are not making any progress convincing me (Neither I
> >convincing you).
> >
> >
> >cheers,
> >jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Jul 2004 15:57:39 -0400

A clarification, and an attempted explanation.

Firstly, you are correct that an LFB port (input or output) is bound on the
instance level.  Obviously, the class definition tells you what ports (or
port groups) must exist, can exist, etc.  But the binding of ports is on an
instance level.  If we are at all unclear on that in the text, we need to
fix it.

Given an IPv4 DiffServ Redirecting Classifier LFB Class, there may be one
or more instances of such an LFB in the data path.  (Sorry for the long
name.  We currently still have in the model sample LFB classes for
classifiers which just generate meta-data and classifiers which
redirect.  For this purpose I am interested in the redirecting example.)

For this discussion, I am simply inventing the structure of the LFB
class.  The real one may not look like this.

Such an LFB instance will have a collection of tables (structure still to
be defined) which will result in deciding that a given packet is to be
given certain meta-data, and sent to a certain neighbor.  The LFB really
has two semantically different classes of results.  One for packets which
matched an entry in the table, and one for packets which failed to match
anything.  (We could avoid this by requiring wildcard entries, but allow me
the liberty of this view.)  In that case, the CE needs to be able to set up
the connection for where failed packets go, i.e. to connect that specific
output port to some next LFB.  It also needs to set up the selectable
connections that the table entries can use.  It seems natural to put those
connections into an array (a port group) and allow the classifier results
to include an output port index from the port group.

Obviously, if there is only one group, and if we don't care about semantic
naming, we could just declare that there are output ports, and they are
indexed, and be done with it.

It seems helpful to assign semantic names to things.  So we end up wanting
to assign names to collections of ports with similar
semantics.  (Admitedly, similar is in the eye of the beholder.)  An real
LFB may well have only indexed port connections.  The FE control logic
which translates between ForCES and actual device control will need to
maintain mapping tables.  The complexity of those tables will depend upon
many details, but it should not be hard in any particularly case.

Once we went that far, it seemed natural (again very subjective) to state
that any situation where you want a variable number of connections, those
connections should be in a port group.

As another example, an IPv4 Next Hop director (that is designed to be
adjacent to the FE egress) might well have a port group with connections to
the various "physical" ports on the FE.  It might also have an error output
port that is used for packets that arrive with meta-data that can not be
used to select an exit.

I hope that this is somewhat helpful.
Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 15 Jul 2004 22:33:57 -0400

> instance level.  If we are at all unclear on that in the text, we need to

I mentioned those two sections earlier that may need syncing on class vs
instance. Another one maybe section 3.3.2
It may help to just walk the draft and double check. I will try to point
out any obvious ones i can find.

Unless other people insist, lets defer the other discussion to probably
a meeting or a concal. It would be a lot more effective that way.

cheers,
jamal

---

From: Steven Blake <[email-masked]>
Date: Wed, 28 Jul 2004 12:21:33 -0400

> instance. Another one maybe section 3.3.2

Section 3.3.2 in -03 looks pretty carefully written to me.  What were
the other sections you had concern about (I looked in the archives but
didn't find a reference)?

> a meeting or a concal. It would be a lot more effective that way.

I'll be in SD and happy to talk.

Regards,

// Steve

---

From: Steven Blake <[email-masked]>
Date: Wed, 28 Jul 2004 12:43:29 -0400

> to include an output port index from the port group.

In addition, the "failed" packets sent out of an "exception" output
might need additional metadata (e.g., failure code) that doesn't need to
accompany packets sent out of the "normal" outputs.

> connections should be in a port group.

I'd like to add that the intent is to group outputs in an LFB
class definition based on the processing done to the packet (e.g.,
packets sent out group A may have had different processing performed on
them vs. those sent out group B), as well as the accompanying metadata
(see example above).  The first condition will probably be applied
rarely, and we may find that we find that we can define LFB classes in
an granular enough manner that we don't need to worry about having to
processes packets differently within an LFB in such a way that it has to
be visible in the model.  The latter condition will be applied more
frequently.

Regards,

// Steve

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 29 Jul 2004 13:13:52 -0400

> didn't find a reference)?

I dont have my notes with me, but lets start with 3.3.2:

Changing topologies which is strictly speaking related to LFB
_instances_ (LFBs contain LFB instances); the reference in the text is
only to LFBs, some sample in reference to topology:
".. changes to the LFBs along the datapaths ..", or,
"..instantiating or deleting LFBs.." or,
"..an LFB topology based entirely on an encoded state approach may have
to change the topology at times, for example, to bypass some LFBs or
insert new LFBs.."

> > out any obvious ones i can find.

This still applies. I will look for my notes and send details.

> I'll be in SD and happy to talk.

I think we were going in cycles; value of email ceases at that point.
ceases to be useful. Face to face would help.
I have very selfish goals actually: whatever the model result is, it
needs to encompass mine.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 29 Jul 2004 13:39:46 -0400

> accompany packets sent out of the "normal" outputs.

I think the definition will be stronger with a little more preciseness.
As an example defining it to be a product of metadata+packettype.
This is one of those things that i said we are going in cycles on; so a
meeting would help.

> be visible in the model.  The latter condition will be applied more

Lets discuss in SD. I am sure we can resolve this.

cheers,
jamal