Subject: [forces] Directly Connected Routes WAS(Re: EtherEncap review WAS(Re: BasicMetadataDispatch WAS(Re: LFB LPM issue

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 23 Apr 2011 12:21:58 -0400

On Sat, Apr 23, 2011 at 11:58 AM, Jamal Hadi Salim <[email-masked]> wrote:

> I still think this is an optimization. I also dont think that ARP is
> the right spot
> to make L3 decisions. Let me set that up as a separate discussion. I will change
> the subject and send out new email to discuss this topic so it is not lost.

I will provide some context so other people can follow - so this is going to
a long email. Authors please correct me if i misunderstood.
There is a current optimization for directly connected routes as defined by
draft-03 achieved by the presence of ARP in the EtherEncapsulator LFB.

The ARP table, looked using  NextHopIP address metadat, on success will match
directly connected routes and allows us to send out to the on link host with
the correct dstmac and media port without requiring us to store this routing
entry in the LPM.
The optimization in this case is that i) we dont have many entries in the LPM
table and ii) it separates the directly connected routes from non-direct ones.

While i agree that the optimization may be of value to say an edge router
(which has presence of many direct hosts), I have counter-arguements.
I would argue (using IPV4 as an example):

- from a model abstraction view, LPM (not ARP) is the proper abstraction
for "L3 Lookups".
- the optimization is of no value to a core router with very few hosts
connected.
- the number of table entries are no different if you put these table entries
in the ARP or LPM tables. i.e if you have 10 directly connected hosts, you
will either have 10 ARP entries or 10 LPM entries.
- the approach described in -03 is implementation specific. I have seen
implementations which address this issue via two levels of lookups.
First you lookup an LPM for directly connected hosts (Longest prefix)
using one algorith which is efficient for /32 then  you lookup the next
LPM for prefixes other than /32. In such an implementation we dont need
to have ARP and assuming a mandatory presence of ARP just complicates
things.

So my suggestion is this should stay out of the model. The model would
still support the described text by assuming that etherencap can be connected
via an LFB-port to ARP for exception handling. And that the ARP table can
have these details as described in L3 and forward on the packet to the host.

Having said that:
We should have text discussing this issue so we dont have to go scan emails
later to figure how we reached the decision.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 23 Apr 2011 13:32:17 -0400

I could live with this.
I think we do end up with more entries this way in edge routers.  But 
your argument about generality is sufficient for me.

Yours,
Joel

On 4/23/2011 12:21 PM, Jamal Hadi Salim wrote:
> On Sat, Apr 23, 2011 at 11:58 AM, Jamal Hadi Salim<[email-masked]>  wrote:
>