Subject: [forces] Fwd: ID Tracker State Update Notice: <draft-ietf-forces-lfb-lib-09.txt>

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 11 Dec 2012 08:37:02 -0500

Sorry, I meant for this to go to the list as well.
I should clarify on one of my comments below:
While the conjoined FIB/NH is common it is not as common as
a disjoint model which is what is defined here. So "optimize
for the common" is relevant in this scope.

cheers,
jamal

---------- Forwarded message ----------
From: Jamal Hadi Salim <[email-masked]>
Date: Tue, Dec 11, 2012 at 8:30 AM
Subject: Re: ID Tracker State Update Notice: <draft-ietf-forces-lfb-lib-09.txt>
To: IETF Secretariat <[email-masked]>
Cc: [email-masked], [email-masked]

Excellent review Adrian - and you made my job as shepherd easier by posting
on the list (I dont have to go chase the authors ;-> I see they picked
it up already).

On Mon, Dec 10, 2012 at 7:06 PM, IETF Secretariat
<[email-masked]> wrote:
>
> In 4.4 in IPv4PrefixTableInfo, what is this all about...
>
>
>                 Reserved
>                 Reserved for future use
>                 uchar
>
>
> Actually, I see several similar (e.g. in VlanInputTableEntryType)
>
> If this is an extensible format (I thought it was) why do you have
> reserved fields?
>

I believe this was my suggestion based on implementation experience of
these LFBs.
The idea is to ensure that everything is 32 bit aligned. The protocol requires
that we have 32 bit alignment and those specific things you are looking
at labelled as "reserved" have "holes" which will end up being padded to
meet that requirement (and so they can be properly parsed at the receiver).
I suggested they be labelled as "reserved" to make them visible.

> Section 5.3 discusses the actual and potential implementation
> architectures and implies that some are more suited to this library than
> others. That bothers me: this whole project is supposed to be about
> abstraction and the abstraction is supposed to suit any (reasonable)
> implementation model since it is the functions of forwarding that are
> described, not the components of an implementation.
>
> So I think the section should not make (what I think are dubious)
> statements about "typical" and "usual" implementations. If it is
> necessary to mention implementations (which I don't think it is) you
> should do so in a light way and just note that this library is agnostic
> to the implementation model and can be applied across all
> implementations with recognition that the functional elements described
> in the LFBs might be realised in a different way in an implementation,
> but that the functions performed will be identical.
>

So herein lies the dilema in general in modelling vs existing implementations.
Some implementation approach will be "penalized" relative to others. Joel
and I often disagree on this mostly; i think he  is in the same camp as you
that the model shouldnt worry about the implementations. The engineer
in me refused to let it go.
I insisted on calling this part out because those two approaches are very
common implementations. And the model favors one over the other i.e
implementations with a conjoined FIB/NH tables will have to do more of
a translation.
I agree on the "light" call of this issue - but not sure how much more you
can tone it down.

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Tue, 11 Dec 2012 09:56:26 -0500

Actually, I do no tthink that the issue is common vs uncommon.  If we 
had to make a call on that basis, it would indicate a problem in the 
structure.

Rather, the issue is ease of mapping. Given a model which represent FIB 
and Next-Hop as separate pieces, it is very easy for hardware which 
combines them to express the adjacency restriction and to map the two 
sets of information to one hardware construct.  Conversely, if we 
represented them as one LFB, there would be o way to represent the 
possibility in some devices that there could be LFBs between the two 
functions.  And the mapping into separate logic, from a single LFB 
instance, would be much harder.

Yours,
Joel M. Halpern

On 12/11/2012 8:37 AM, Jamal Hadi Salim wrote:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 11 Dec 2012 16:16:01 -0000

Yes, I agree with Joel's view on this. The reason why functional architectures
split things into separate functional components is to allow implementation
freedom in which one can implement the architecture or combine the blocks in
different ways.

Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joel
> Sent: 11 December 2012 14:56
> To: Jamal Hadi Salim
> Cc: [email-masked]; draft-ietf-forces-lfb-lib
> Subject: Re: [forces] Fwd: ID Tracker State Update Notice:
<draft-ietf-forces-lfb-
> lib-09.txt> - model structures
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 11 Dec 2012 12:19:58 -0500

So I am not disagreeing on the functional architectural view that the model
takes. I was hoping that the extra info, as described, would reduce confusion
for an implementer; if that goal is not achieved then it not useful to have.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 22 Dec 2012 13:47:51 +0800

Hi, 

On this issue, I'm going to modify the text in 5.3 section by adopting words proposed by Andrian: 

The text used to be:
--------
5.3.  IP Forwarding LFBs
...
   A typical IP unicast forwarding job is usually realized by looking up
   the forwarding information table to find next hop information, and
   then based on the next hop information, forwarding packets to
   specific physical output ports.  It usually takes two steps to do so,
   firstly to look up a forwarding information table by means of Longest
   Prefix Matching(LPM) rule to find a next hop index, then to use the
   index as a search key to look up a next hop information table to find
   enough information to submit packets to output ports.  This document
   abstracts the forwarding processes mainly based on the two steps
   model.  However, there actually exists other models, like one which
   may only have a forwarding information base that have conjoined next
   hop information together with forwarding information.  In this case,
   if ForCES technology is to be applied, some translation work will
   have to be done in the FE to translate attributes defined by this
   document into attributes related to the implementation.
--------------

To modify above text to: 
-------------
5.3.  IP Forwarding LFBs
...
   An IP unicast forwarding job is usually realized by looking up
   the forwarding information table to find next hop information, and
   then based on the next hop information, forwarding packets to
   specific physical output ports.  It usually takes two steps to do so,
   firstly to look up a forwarding information table by means of Longest
   Prefix Matching(LPM) rule to find a next hop index, then to use the
   index as a search key to look up a next hop information table to find
   enough information to submit packets to output ports.  This document
   abstracts the forwarding processes based on the two steps
   model. Whereas, this document is agnostic to the implementation model 
   and can be applied across all implementations with recognition that the functional elements described
   in the LFBs might be realised in a different way in an implementation, but that the functions performed will be identical.
-------------

Pls give response if you'v any thoughts.

thanks,
Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>