Subject: Re: FW: Feedback on ForCES Model v02

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Mar 2004 13:38:17 -0500

Two reasons:
1) Supporting multiple versions in the same FE adds complexity to the model
and the protocol.
2) We could not see significant utility in such support.  If there are two
LFB classes where some FEs will support one, and some will support another,
then those should be distinct classes, not new versions of the same class.

Another way of looking at this is that versioning is for when we make
mistakes.  Subclassing is for when we extend functionality.

Yours,
Joel

At 10:00 AM 3/12/2004 -0800, Putzolu, David wrote:
> > 3.2.5 last para: Why are FEs disallowed from
> > supporting multiple versions of a particular
> > class?
>
>Because that is supported by inheritance, silly.
>
>I'm not sure what the rationale is for this statement, so I defer to my
>coauthors.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Mar 2004 13:45:13 -0500

[Sorry for not getting this clarified sooner.]
The FE notion of NeighborID and NeighborInterface are configured
information about FE neighbors.  The ID is not a CE assigned name, but
rather (as I tried to suggest in the second sentence) a CE known ID.  The
idea is that the CE would know the IDs and port identifiers of all its
FEs.  it would then look at the neighbor table and be able to tell if any
FE has neighbors who are also known to the CE.
Note that there is also NeighborNetworkAddress and
NeighborMacAddress.  Presumably, one could match on those.

If we use NeighborID, that would be a field configured by the FE / CE
owner, where each FE would be configured with its own ID and any known
neighbor IDs.

We should probably decide whether entity ID + port identifier or interface
IP address or interface MAC address should be used to identify neighboring
FEs.  (I put in all of them just to capture the alternatives.)

Yours,
Joel

At 10:00 AM 3/12/2004 -0800, Putzolu, David wrote:
> > 5.2.2.4.1 Don't understand what namespace this is.
> > FE has no way of knowing what names the CE is assigning
> > to other FEs, so this must be something that the other
> > FEs communicate to the FE - should be a valid identifier
> > prior to CE<->FE connection, otherwise this becomes a
> > chicken & egg problem.  Each FE should have some unique
> > ID - maybe just use a MAC address perhaps that the FE owns.
> > Or is this what 5.2.2.4.4 is?
>
>It would seem so.  Joel?

---

From: "Putzolu, David" <[email-masked]>
Date: Mon, 15 Mar 2004 09:50:29 -0800

Hi Steve.

Thanks for the model clarifications & I understand the
reasoning for the approaches taken with tunnel encap/decap, 
interface, and LFB independence.

I am not sure I understand the input groups yet but let me
take a stab at it and tell me if I got it right:

Example: LFB instance has three inputs. CE configures LFB 
such that the first input is associated with input group
#1 and second and third inputs are associated with 
input group #2.  The LFB may have a table that takes the
input group # as one of its inputs, treating the packet
differently based on input group #.  Since two inputs are
associated with the second input group, the group concept
adds value here because a single metadata-like value (group
#) can be associated with packets arriving on multiple ports.

Is this the general idea?

> A LFB with N ports in a single output group is equivalent to a
> LFB with a single output port paired with a Redirector LFB with N
> output ports.  Output groups allow us to avoid introducing an
> otherwise extraneous Redirector, and the output selector metadata
> it must use.
> 
> The idea in fact is to allow the output port within an output group
> to be specified on a per-attribute basis (e.g., on a per-prefix
> basis for a LPM LFB class).

On this one I still don't understand. I imagine a LFB would
have some sort of table with a key of some sort used to classify
the packet and a value that specifies the output to use. For
simplicity I will use color values for the key, but any key
(LPM, 5-tuple, etc.) could be used:

Key    | Output
===============
Red    | 1
Yellow | 1
Green  | 2

How would this table differ, and how would there be additional
benefit, in adding a output group : output # mapping?

Thanks,
David

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Mar 2004 14:17:46 -0500

Yes, your description of input port group is accurate.  (At one time it had
more reasons for existing, because we had more topology
restrictions.  Earlier drafts specified that there was no merging of
packets on the input path.  When that was the case, Input port groups were
also necessary just to handle topology.  Now, they are used primarily when
the topology itself carries useful information.)

Let's see if I can clarify output port groups...

The reason for output groups is partially syntactic and partially
semantic.  We use output groups to allow us to talk about a set of ports
used in extremely similar fashions.  Semantically, a redirector has an
output port group for the packets for which it has successfully selected a
next LFB.  The redirector might have a separate output port for error packets.
The syntactic reason is best explained by looking at a more complex
case.  Suppose that a subclass of redirector was defined to cleanly
separate packets needing application processing from those needing
metering, marking, etc.  Within each of these two sets there might be
several next LFBs.  So the definition of the ports does not want to
constrain the how many of either kind of output port there are.  But we
would like it to be clear (for both CE and human comprehension) which kind
is which.  So we could either have a property on each port about its kind,
or we could group each kind of port into a port group.   We chose to do the
later.
As a result we are also looking at a syntax where LFB descriptions can
index within an output port group for selecting a specific output port, but
the logical description will likely not allow indexing between different
port groups.  (Note that this allows us to avoid a semantic protocol
dependency.  The protocol may or may not name port groups wsith integers,
and they may or may not be successive.   Elements of a port group are
numbered with integers.)

We could do without the output port groups, but it seems to be helpful to
human beings at least to understand that a particular collection of ports
has a specific function.

Yours,
Joel M. Halpern

---

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 17 Mar 2004 19:51:00 -0800

David -- see my response to some of your earlier comments:
I took out other comments either those are editorial comments that will
be directly incorporated into the next revision, or comments that are
already addressed by my co-authors. Thanks!

> Page 12 shows "internal control" in the figure. This is
> confusing because the LFBs are still part of the ForCES
> model of the actual FE implementation.  Perhaps say
> "LFB manipulation" or "per-LFB interactions" here?

Well, here the "internal control" path actually does NOT belong to FE
model. That is exactly why we call it "internal control". Maybe "per-LFB
internal control" is better term. This is the glue between ForCES
protocol point and the FE implementation, where the commands from CE got
mapped onto FE.

> Section 3.2.1 Input group is confusing to me. If it
> is only a way of identifying which LFB sourced a packet to
> another FE, which not simply assert that LFBs are able to
> determine which input connection # a packet arrived on?
> Does input group offer anything more than this?  

I admit the wording is very confusing here. Jamal also had some comments
on this. We are in the middle of sorting this out within the model team.
So I promise you that we will get back to you on this soon.

> Section 3.2.2 It isn't clear what the use of an output
> group is. How would a FE or LFB use it?  LPM is the example 
> given but doesn't make sense. If the LFB classifies a packet 
> it will likely have a specific next LFB connection to send 
>it on.  The alternative is to just say "send this packet on 
> that output group" - but that makes for unpredictable /
> unspecified behavior, which is (correctly) identified as 
> undesirable.

Again, like the case of input group, we are working on better text and
better explanation. Point is taken. Resolution is coming soon.

> 3.2.4.2 Why must there be at least one producer and
> one consumer?  While I can see the need for a 
> consumer to require an upstream producer (aside: it
> would be better if each metadata consumer LFB, even 
> non-optional ones, also specify what happens if the 
> expected metadata is not present), there is no real 
> need for each producer require a down graph consumer.

Correct.

> 3.3.1 While hardware could influence topology, I think
> it is more important that the data path be modeled in
> a clear fashion.  If a single hardware classifier is 
> used for two logically different classifications (e.g.
> in IP in IP tunneling, one classification on the outer,
> another on the inner DIP), that still would be better
> represented as two separate LFB instances, unless one
> specifically wants to reuse the same classification 
> entries (e.g. an ACL where any access to certain ports
> is to be blocked, whether on the inside or outside of
> an IPinIP or IPsec tunnel mode connection).

Agree. Need to clarify the text.

> 3.3.1 Page 28/9 It says "One way to encode...". Not 
> sure of the relevance of that. Is it the suggested
> mechanism or the actual mechanism used in this document?
> If so say so!

Actually that whole paragraph should be deleted. Such details are left
to Section 4 in the schema.

> 4.7 Re: editor's note: Should LFB class names 
> be managed by IANA?

I think so. We will expand on our IANA section.

> Section 6 general comment: This seems to be a very good
> start on the following charter deliverable:

> o A formal definition of the controlled objects in the
>   functional model of a forwarding element. This
>   includes IP forwarding, IntServ and DiffServ QoS. An
>  existing specification language shall be used for
>  this task.

> I remember some discussion about splitting this off.
> Do you think this should remain in the base model draft, 
> or should it be split off as a separate doc/draft?

This is something we would like to hear opinions from others. At this
point, I think a very brief section on the library can be included in
the model just to demonstrate the kind of granularity on LFBs we have in
mind. But the real substance of such a library does not belong here.

> Section 6 general comment: Some ASCII art of each
> of the LFBs showing inputs, outputs, etc., would be 
Something more elaborate like that can definitely be done if it is in a
separate document.

> 6.1 Ports are tricky things. If a single LFB represents
> both send and receive then all FE graphs will look like
> cycles, which is rather confusing (and hard for a machine
> to parse).  Of course, splitting ports also is confusing -
> if one downed a receive LFB it would down the whole port,
> affecting the transmit LFB as well. This isn't a new issue,
> but the doc doesn't really explain how it will be addressed -
> better to put a stake in the ground one way or the other.

I thought we did. We decided to go with the former approach. Maybe not
clear enough.

> 6.5 The bullet ". that is maintained at a downstream LFB"
>   appears out of context, what is it referring to?

Formatting error. Should not be a bullet here, instead just part of the
last bullet.

> 6.8 mentions a "Modifier LFB" that is not explained or
>   mentioned elsewhere. 3.2.4 Mentions a Header Modifier LFB
>   that is also not mentioned elsewhere - should both of these
>   be "Packet Header Rewriter LFB"?

Good catch!

>  8.7 Need to address what happens to packets arriving at/
 >   transiting a FE during reconfiguration. Do they get 
 >   dropped on disconnected inter-LFB links? Start filling
 >   queues? Something else?
I agree something should be said here.

>  10. A model-specific security issue that should be mentioned
>    is the risk of misconfiguring a LFB graph resulting in
>    insecure behaviors.  Having software on a CE reconfigure 
>    a LFB graph is a very easy way to shoot yourself in the foot.

I can see the "shoot yourself in the foot" part, but not particularly
the "insecure behavior" part. Could you elaborate?

Thanks!

Lily