Subject: Re: input ports/groups

From: "Yang, Lily L" <[email-masked]>
Date: Mon, 15 Mar 2004 20:14:58 -0800

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Monday, March 15, 2004 5:47 PM
To: [email-masked]
Subject: input ports/groups

Trying to catchup with reviewing the model draft.
<LY> I am glad you are doing this. It's about time :-) </LY>

I think it would be valuable in future revisions to post a diff
of the text files; or maybe a annotated pdf so people can see
the difference. I just finished reading section 3. Hopefully i will
finish the rest this week; would be faster to review if i could compare
against what i looked at previously.
<LY> Well, I assure you that doing diff for this revision isn't as
helpful 
as you imagined. Because the changes are all over the place, on every
page if not every paragraph. You will not want to look at the diff.
Trust me on this one. Maybe later when we are really close.
</LY>

On the topic of input and input groups. This maybe something different
from what is being discussed in other thread, if not i apologize in
advance:
I am struggling trying to understand the value of

a) ports. Are ports not reflected by metadata?
What exactly is the value of a port? Is it an index into some state
table?
<LY> You mean input/output? We shouldn't use "ports" as our terminology
for input/output, because later we have "port LFB" which are real ports.
</LY>

b) more than one input. From a semantic view i see only one input which
brings in a packet and metadata (with one or the other missing).
It is counterintuitive to me to see multiple inputs if theres consistent
input data.
Is there anything else other than those two entities that comes into an
LFB? Maybe another input is an event?

<LY> We are NOT advocating multiple inputs. Actually, we strongly
recommend against that. But we suggest that you might have multiple
input streams from different datapaths converging at one LFB. If you
want to still differentiate the packets from different paths, you can
view them as a "input groups" of a bunch of similar inputs, with a label
(input id) telling you what path it came from. But one input group of 3
inputs, is regarded as one input.
I will think more on this and get back to you on this one. 
</LY>

In a mixed topological + encoded state setup i see that policies
will be such that connecting instances of LFBs to each other is mostly
sufficient to describe a packet path i.e these instances of LFBs are
bound together by the CE; the compensation for addendum data needed for
processing is carried within metadata. I dont see how multiple inputs
fit in that model.
<LY> Again, not multiple input really. One input group of multiple
*similar* inputs, can be regarded as one input with a metadata called
"pathID", I guess. So it can be thought of as a special metadata that is
just called out explicitly here. 
Again, I will think about this and get back to you. I have some second
thoughts myself.
</LY>

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 16 Mar 2004 09:51:50 -0500

> <LY> I am glad you are doing this. It's about time :-) </LY>

It wouldnt have been complete if i didnt review it, you should know
that;->

> Trust me on this one. Maybe later when we are really close.

How about a PDF with changes recorded (cut-through lines to show deleted
lines etc)?
The diff of the original xml document would be useful. I can see what
you mean by diffing the IETF draft file though - it would be painful to
just see the headers/trailers repeated a hundered times.

> for input/output, because later we have "port LFB" which are real ports.

I saw the term "port" used by Joel and other people in the discussion
in reference to things like in:1, in:2 in figure 3b).
This is begining to sound almost like an implementation detail.

> recommend against that.

For something that you are making recommendations against you are giving
it way too much byte space.
If you look at all the xml for example it seems to be assuming this is
kosher. Why even bother modeling this detail?

> But we suggest that you might have multiple
> want to still differentiate the packets from different paths,

Is metadata insufficient to reflect this "from LFB x" detail? Sure, you
can draw a diagram showing arrows from multiple LFBs, but i think its
pushing it going into input groups (and even referencing inpiut ports).
Note that in a purely topological approach, the LFBs path is bound
at the CE level, so the detail of what the last LFB was is not useful.

> you can

I think it is more confusing than help to maintain it in the text.

> Again, I will think about this and get back to you. I have some second

ok.

cheers,
jamal