Subject: [forces] LFB LPM issue

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 10 Apr 2011 10:16:51 -0400

Weiming,

I have attached a couple of slides without going into
the little details of the LFBs. Slide 2 demonstrates i think
what we agreed on at the meeting.
I hope you and the other authors can review and respond. I
do have many other comments on the doc - mostly in regards
to readability.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 11 Apr 2011 21:02:06 +0800

Hi Jamal,  

Thanks for the comments. Pls see inline of texts copied from your slides for the reply.  

Joel and Chuanhuang, may I also have your some attention on the reply of some issue inside?

thanks a lot.
Weiming

-----
● NH outputs as part of metadata EncapOutputIndex
    ●Already available, just not used currently
Re: in current version of NH LFB, the EncapOutputIndex is used by this NH LFB itself to select the output from the output group. For instance, if the group output 1 is connected to a downstream EtherEncap LFB, then the packets with the EncapOutputIndex assigned to 1 means to output to an Ether encapsulator. 

I'm not sure if you mean to define  this EncapOutputIndex as a metadata  output via the NH output port? if so, how can we distinguish different encapsulators followed, saying we have other encapsulations other than Ethernet followed.

●ARP/ND resolution removed
Re: not sure the details, you mean the ARP/ND function will be included in the EtherEncap LFB?

    ● EtherEncap is not aware of IPV4 or V6
Re: Yes, current version of EtherEncap includes IPv4 and v6.

         ● Up to implementation if IP is ignored or how it is used (ARP/ND)
Re: could this be described  more? I just can not catch up well with what it means behind.

    ● New EncapTable in EtherEncap LFB indexed by EncapOutputIndex
Re: I just can not understand well how can EncapOutputIndex be used as index for packets to find out encap information for the packets?  Could you provide more on this? thanks.
        ● No IP information stored
        ● No LogicalPortID, we already have one from NH
Re: In current EtherEncap LFB, we'v defined a VLAN output table, which is used for a packet to find out an output logical port ID and a VlanID by an input logical port ID which is from upstream NH LFB.  This means, the logical port ID generated by NextHop table in NH is different from the logical port ID generated by this EtherEncap LFB. 
We designed this after some discussions between Joel and Chuanhuang. I hope you two tuys can provide more information on this design. Thanks.

        ● Store dstmac and possibly a EncapSrcIndex
        ● Find srcmac and VLAN details within EncapTable by one-of:
            ● Use stored EncapSrcIndex to index another srcEncap table
            ● Store srcmac and optional vlan information in EncapTable
Re: I'm sorry that I still can not catch up here well. Why don't we just define a table in which dstmac and srcmac are included, just as the ArpTable does in  current version EtherEncap LFB? 
----

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

> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 11 Apr 2011 10:02:15 -0400

Hi Weiming,

Comments below:

> Re: in current version of NH LFB, the EncapOutputIndex is used by this NH LFB >itself to select the output from the output group. For instance, if the group output 1 is >connected to a downstream EtherEncap LFB, then the packets with the >EncapOutputIndex assigned to 1 means to output to an Ether encapsulator.
>
> I'm not sure if you mean to define  this EncapOutputIndex as a metadata  output via >the NH output port? if so, how can we distinguish different encapsulators followed, >saying we have other encapsulations other than Ethernet followed.
>

I misunderstood the meaning of that index because I dont think what
you just described above is in the text of the draft.
Am i mistaken? If i am not, then please add to the TODO list
such an explanation. Also, maybe somewhere we need to say that
the design choices of the LFBs is so that we can have genericity in
Link layers (although we currently only focus on Ethernet) as evidenced
by the presence of EncapOutputIndex.

Having said that:
What i meant is we need some index which is output as metadata from NH.
The value of this metadata will be used to index into a table in the
Ether encapsulator. I called it EncapOutputIndex but change its
name to something else. For example, lets call it NHEncapInfoIndex

> Re: could this be described  more? I just can not catch up well with what it means behind.

I meant we have only the useful encapsulation information for the nexthop
link layer details - not how such information is gathered.
This information is indexed by what i called NHEncapInfoIndex above.
This will allow someone to install all the details of dstmac, srcmac and VLAN
info without needing for FE to be aware of ARP. Or if they decide to use
ARP when the packet gets to that point, then they can choose to do so
(even though i think that is a bad idea).

> Re: I just can not understand well how can EncapOutputIndex be used as index for >packets to find out encap information for the packets?  Could you provide more on >this? thanks.

Table name: NHEncapTable
Table index: NHEncapInfoIndex
Table entries option 1:
dstmac, srcmac, optional vlan information
or Table entries option 1:
dstmac, EncapSrcIndex
and then use EncapSrcIndex to find srcmac and optional VLAN information.

I hope this makes sense.

>        ● No IP information stored

As evidence from above, you can see no IP information needed by
ethernet encapsulator. NHIP is still passed as metadata - so if your
implementation
wants to do ARP or ND to populate dsmac address, they can do that.

> Re: In current EtherEncap LFB, we'v defined a VLAN output table, which is used for >a packet to find out an output logical port ID and a VlanID by an input logical port ID >which is from upstream NH LFB.  This means, the logical port ID generated by >NextHop table in NH is different from the logical port ID generated by this >EtherEncap LFB.
> We designed this after some discussions between Joel and Chuanhuang. I hope you > two guys can provide more information on this design. Thanks.
>

I didnt quiet follow the reasoning.
The route (LPM+NH) points to a logical port where the packet is to go out. Does
this mean some other policy downstream will make the decision to change this?
Joel/Chuanhuang?

> Re: I'm sorry that I still can not catch up here well. Why don't we just define a table >in which dstmac and srcmac are included, just as the ArpTable does in  current >version EtherEncap LFB?

We could. Using an index will use less memory - but we can optimize later.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 11 Apr 2011 22:48:22 +0800

Hi Jamal, more reply inline. 

thanks,
Weiming
----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>
> by the presence of EncapOutputIndex.

WRe: Jamal, 5.3.2.  IPv4NextHop section has described the use of the Index, pls check p.50 of LFB lib v3, although more words may be added to state the genericity in link layers. 

> name to something else. For example, lets call it NHEncapInfoIndex
WRe: currently we have used the logical port ID as the metadata output by the NH LFB to index the table in Etherencap LFB. I'm not sure if you mean this kind of index, or totally other one? 

> and then use EncapSrcIndex to find srcmac and optional VLAN information.
WRe: Jamal, to this point, I get to understand more on what you thought. 
Your thought might be: 
. LPM LFB to find an NHID
.NH LFB uses the NHID to find a port ID and some index (you call EncapInfoIndex)
. Encap LFB uses the index to find all encap information, WHILE keeping the port ID unchanged to output port to downstream LFB.

While our current version uses the following steps: 
. LPM LFB to find an NHID
. NH LFB uses the NHID to find a port  ID (logical port ID)
. Encap LFB uses the port ID to find a new output logical port ID and a VLAN id, then via the output logical port ID to find more encap information in an ArpTabel. Moreover, the output logical port  ID is output to downstream LFB. 

So, the key difference is what we shall call the ID generated by NH LFB(you call it an index, we currently just call it logical port ID).  I remember we call it logical port ID because some L2 bridging LFBs may also possibly generate this kind of logical port IDs to input to Etherencap LFB for encap information. I need Joel/Chuanhuang to verify this. 

> this mean some other policy downstream will make the decision to change this?
WRe: I think this question has linked to the quesion one above.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 11 Apr 2011 11:09:25 -0400

Hi Weiming,

On Mon, Apr 11, 2011 at 10:48 AM, Wang,Weiming <[email-masked]> wrote:

> WRe: Jamal, 5.3.2.  IPv4NextHop section has described the use of the Index, pls >check p.50 of LFB lib v3, although more words may be added to state the genericity >in link layers.

I am looking at the text now and i see it mentioned as "encapsulation output
index". I searched for "EncapOutputIndex" in the text.
So i am not sure if i am at fault - or you need to fix the text and
call it "EncapOutputIndex" for consistency.

> WRe: currently we have used the logical port ID as the metadata output by the NH >LFB to index the table in Etherencap LFB. I'm not sure if you mean this kind
> of index, or totally other one?

My thinking is that logical port ID is related to what output logical port it is
going out. I notice you use it to index into this table - but i think we need
a new index for this table. We can continue to pass the logical port ID
as is or derive it from here ..

> . Encap LFB uses the index to find all encap information, WHILE keeping the port ID unchanged to output port to downstream LFB.

I am not fixated on where the logical port id is stored. It could be in the
encap LFB.

> So, the key difference is what we shall call the ID generated by NH LFB(you call it >an index, we currently just call it logical port ID).  I remember we call it logical port ID >because some L2 bridging LFBs may also possibly generate this kind of logical port >IDs to input to Etherencap LFB for encap information. I need Joel/Chuanhuang to >verify this.
>

This may explain why you repeat the port information further down.
I dont think you should call that thing "logical port ID" - it confuses
the terms.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Apr 2011 11:01:13 -0400

The NH LFB needs to generate both a port ID and an encapsulation index.

The encapsulation index does not select the port, as each port has its 
own encapsulation table (conceptually.  Implementation-wise we may 
design the LFB to use both indices if you want.)

If the output port selected by the NH LFB is actually a bridged port, 
then the encapsualtion information will also need to provide a more 
specific output port.  Normally, it will be the same output port index 
as the input port index.

Yours,
Joel

On 4/11/2011 10:48 AM, Wang,Weiming wrote:
> From: "Jamal Hadi Salim"<[email-masked]>
>>> -----
>>> Re: in current version of NH LFB, the EncapOutputIndex is used by this NH LFB>itself to select the output from the output group. For instance, if the group output 1 is>connected to a downstream EtherEncap LFB, then the packets with the>EncapOutputIndex assigned to 1 means to output to an Ether encapsulator.
>>>
>>> I'm not sure if you mean to define this EncapOutputIndex as a metadata output via>the NH output port? if so, how can we distinguish different encapsulators followed,>saying we have other encapsulations other than Ethernet followed.
>>>
>>
>>> Re: I just can not understand well how can EncapOutputIndex be used as index for>packets to find out encap information for the packets? Could you provide more on>this? thanks.
>>
>> Table name: NHEncapTable
>>> Re: In current EtherEncap LFB, we'v defined a VLAN output table, which is used for>a packet to find out an output logical port ID and a VlanID by an input logical port ID>which is from upstream NH LFB. This means, the logical port ID generated by>NextHop table in NH is different from the logical port ID generated by this>EtherEncap LFB.
>>> We designed this after some discussions between Joel and Chuanhuang. I hope you>  two guys can provide more information on this design. Thanks.
>>>
>>
>>> Re: I'm sorry that I still can not catch up here well. Why don't we just define a table>in which dstmac and srcmac are included, just as the ArpTable does in current>version EtherEncap LFB?
>>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 11 Apr 2011 11:25:31 -0400

Hi Joel,

On Mon, Apr 11, 2011 at 11:01 AM, Joel M. Halpern <[email-masked]> wrote:
> The encapsulation index does not select the port, as each port has its own
> encapsulation table (conceptually.  Implementation-wise we may design the
> LFB to use both indices if you want.)
>
> If the output port selected by the NH LFB is actually a bridged port, then
> the encapsualtion information will also need to provide a more specific
> output port.  Normally, it will be the same output port index as the input
> port index.
>

So you have a two level mux? i.e
a) Selection encapsulation table (type?) - in current case Ethernet
b) Select port which may have its own encap table.

The discussion with Weiming is what to select within an encap table
(my suggestion of a new index) i.e while two packets may go out
the same port, they may use different src/dstmac as well as VLAN info.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 11 Apr 2011 23:29:06 +0800

Joel, 

On the encapsulation index, I think we have reached a consensus that the index is as a port selector for NH LFB group output. I just checked the messages as the following time again:

Sent: Friday, September 10, 2010 8:37 PM
Subject: Re: Definition of IPv4NextHopApplicator LFB

Sent: Saturday, September 11, 2010 12:57 AM
Subject: Re: Definition of IPv4NextHopApplicator LFB

thanks,
Weiming

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>

---

From: Joel <[email-masked]>
Date: Mon, 11 Apr 2011 11:40:52 -0400

Lets trace it out:
The Longest Prefix Match (LPM) LFB looks up the destination IP address, 
and profuces a next hop index.
the packet is then sent to the Next Hop (NH) LFB.
The NH LFB uses the next hop index to pick up several pieces of 
information.  this includes the next hop IP address (if any), the output 
index for the group port, used locally to select which next LFB to send 
the packet to, and an encapsulation index metadata, and a logical output 
port ID.
Note1: at this stage, this is a logical port as seen by L3 processing.

Eventually, the packet arrives at a media specific encapsulator.  Let us 
assume that ARP information is all filled in.  The media encapsulator 
knows how to add the proper header to the packet, and send it onward.
Note2: If we want to design to allow a single instance of the media 
encapsulator to handle multiple L3 output ports, then we use the output 
port index as well as the encapsualtion index as table indicies.  If 
each Media encapsulation LFB instance handles only one L3 output port, 
then only the encapsulation index is used as the table index.
Note3: To allow for different ways of handling ARP, I would define the 
table here to have an indication if the entry is unfilled.  If a packet 
arrives with an encapsulation index pointing to an unfilled entry, then 
it needs to be sent for ARP processing (either an APR LFB or the CE...)
One of the things the media encapsulator has to do is to cope with the 
fact that there may be L2 bridging under the L3 port.  As such, the 
output port ID may be refined / replaced with a more specific valuye by 
this processing.
Note 4: The NH LFB can not do this refinement because it operates above 
the level where this is visible.

Yours,
Joel

On 4/11/2011 11:25 AM, Jamal Hadi Salim wrote:
> Hi Joel,
>
> On Mon, Apr 11, 2011 at 11:01 AM, Joel M. Halpern<[email-masked]>  wrote:

---

From: "Chuanhuang Li" <[email-masked]>
Date: Tue, 12 Apr 2011 00:52:58 +0800

Hi, All

I know what Jamal had suggested. In that case, the "NHEncapInfoIndex" is not 
the same as "EncapOutputIndex" which we have currently defined in NH table.  
"NHEncapInfoIndex" will be used for the selection of different entry in Encap Table 
in EtherEncap LFB. "EncapOutputIndex" is still for the selection of different Output 
Port in NH LFB.

But I have some worries:
1:According Jamal's suggestion, we need define both of these two index in NH table. 
This will make the logic of NH LFB complicated, because NH need to know some detailed 
things of it's followed LFBs. 
2:To the packet needed to be forwarded to local subnet host, the routing table(LPM+NH) 
need one entry for one subnet host.(Owing to the searching key is NHEncapInfoIndex in 
Encap table.). Then, if the subnet is large, the routing table is also larger.  
 Current resolution: This is indicated by "NexthopOption"  in NH table(One subnet only need 
one entry).  If the packet is for the subnet host, the metadata "NexthopIPv4Addr" will 
be changed to it's destination IP address. In EtherEncap, by using this IP address(searching key), 
the packet can found out it's encapsulation information. 
3:Also, if we define "NHEncapInfoIndex", the "NexthopIPAddr" defined in NH table may be no 
useful in the followed LFBs.

ps: In my mind, Although we will not define ARP/ND LFB in current version lib, I think it is not 
mean we should avoid everything about them in the other LFB's definition. 

Yours,
Chuanhuang	

======= 2011-04-11 23:21:48 Wang,Weiming, wrote: =======

---

From: Joel <[email-masked]>
Date: Mon, 11 Apr 2011 14:27:14 -0400

I am not following your concerns.
The CE will populate the indices.  It knows what index it assigns to the 
specific next hop, and manages the table.  There is no "coordiantion" 
between LFBs that causes problems.
The local hosts are an interesting question.  I can imagien various 
design change sto keep that simple, if we want to do so.  (For example, 
we could have special entries in the enxt hop table that mean "local 
subnet", and use a single next hop index for those, and have the next 
hop LFB look at the ARP / ND table.)

Yours,
Joel

> ======= 2011-04-11 23:21:48 Wang,Weiming, wrote: =======
...

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 11 Apr 2011 19:04:39 -0400

I am fine with this proposal. Just one or two comments below:

On Mon, Apr 11, 2011 at 11:40 AM, Joel <[email-masked]> wrote:
> Lets trace it out:
> The Longest Prefix Match (LPM) LFB looks up the destination IP address, and
> profuces a next hop index.
> The NH LFB uses the next hop index to pick up several pieces of information.
>  this includes the next hop IP address (if any), the output index for the
> group port, used locally to select which next LFB to send the packet to, and
> an encapsulation index metadata, and a logical output port ID.
> assume that ARP information is all filled in.  The media encapsulator knows
> how to add the proper header to the packet, and send it onward.
> encapsulator to handle multiple L3 output ports, then we use the output port
> index as well as the encapsualtion index as table indicies.  If each Media
> encapsulation LFB instance handles only one L3 output port, then only the
> encapsulation index is used as the table index.
> Note3: To allow for different ways of handling ARP, I would define the table
> here to have an indication if the entry is unfilled.  If a packet arrives
> with an encapsulation index pointing to an unfilled entry, then it needs to
> be sent for ARP processing (either an APR LFB or the CE...)

We could define that as a table miss exception; of which ARP/ND
is one possible resolution.

> One of the things the media encapsulator has to do is to cope with the fact
> that there may be L2 bridging under the L3 port.  As such, the output port
> ID may be refined / replaced with a more specific valuye by this processing.

This is the part i need to think about a little more. What are the circumstances
for this to happen? i.e if the CE already knows all, why would it not populate
such information at the L3 level? Given the CE already knows what headers
need to be encapsulated on an outgoing packet.

> Note 4: The NH LFB can not do this refinement because it operates above the
> level where this is visible.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 11 Apr 2011 19:11:34 -0400

On Mon, Apr 11, 2011 at 12:52 PM, Chuanhuang Li
<[email-masked]> wrote:
> This will make the logic of NH LFB complicated, because NH need to know some detailed things of it's followed LFBs.

It is the job of the CE to keep track of this info (even today downstream LFBs
depend on metadata programmed by the CE on an LFB).

> the packet can found out it's encapsulation information.

The intent is not to remove this feature. I didnt quiet follow how we loose it,
but we need to make sure it stays.

> 3:Also, if we define "NHEncapInfoIndex", the "NexthopIPAddr" defined in NH table > may be no  useful in the followed LFBs.

It may still be useful. Refer to exchange in my last email with Joel. It may
still be used to do ARP/ND when the encap table miss happens.
If i was to implement, I will make sure theres never such a table miss
and therefore no need for ARP/ND. But thats a choice i dont want to impose.

> mean we should avoid everything about them in the other LFB's definition.

Refer to above. I dont think we should really define ARP/ND LFB. We
should mention that it is possible to use ARP/ND without going into the
structure of such an LFB.

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Mon, 11 Apr 2011 19:13:30 -0400

In one sense, the CE will know all.
The basic problem is when brdging shifts thigns around.  You can, for a 
single, stable, next hop, go through the three stages:
1) Next Hop A -> L3 Output Port A -> real output port A1
2) Next Hop A -> L3 Output Port A -> unknown real output port due to 
brdging cache flush
3) Next Hop A -> L3 Output Port A -> real output port A2
We could include that real output port in the Next Hop table.  But it is 
really a media specific thing.  The information about it should be 
confined to LFBs that care about the specific media and specific logical 
output port.

related example is ARP / ND.  If you do not know what the MAC address 
is, you do not know what the real output port is, even though you do 
know the logical (L3) output port.

Yours,
Joel

---

From: "Chuanhuang Li" <[email-masked]>
Date: Tue, 12 Apr 2011 12:31:48 +0800

Hi, Joel and Jamal
>hop LFB look at the ARP / ND table.)
I think this ARP/ND table(Include IP information) is different from the Encap Table 
which Jamal had mentioned (No IP information). 
If ARP/ND is implemented on CE, these packets for local hosts will be needed to 
redirect to CE to complete the encapsulation. It's so strange. 
If ARP/ND is implemented on FE, these packets will be sent to ARP/ND 
LFB to encapsulate. In this case, the EtherEncap LFB only have some encapsulating function.

>between LFBs that causes problems.
Yes, CE knows what index it assigns, When ARP/ND is implemented on CE.
But if ARP/ND is implemented on FE, CE dons't know this information. CE can config a fix index 
to every entry, but i think this may affect the EtherEncap LFB to manager his table. 
Also, for ARP/ND LFB, it need to know whether it tells to EtherEncap LFB to flush the Encap table, 
when it gets a new L2 information.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 12 Apr 2011 05:05:30 -0400

Ok, i can see it.
So it seems to be sensible to leave out the Output Port out of the
NH level, rather have the media level decide that, no?
i.e the NH passes on the encap index to the encapsulator which resolves
not just the header level details but also the Output port.
In the case of bridges, tunnels, arp etc it should work.

cheers,
jamal

PS:- it is getting confusing sometimes in the discussion figuring whether
we are talking about a media port or an LFB port. I am assuming output
port to mean a media port.

On Mon, Apr 11, 2011 at 7:13 PM, Joel <[email-masked]> wrote:
> 2) Next Hop A -> L3 Output Port A -> unknown real output port due to brdging
> cache flush
> really a media specific thing.  The information about it should be confined
> to LFBs that care about the specific media and specific logical output port.
>
> related example is ARP / ND.  If you do not know what the MAC address is,
> you do not know what the real output port is, even though you do know the
> logical (L3) output port.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 12 Apr 2011 05:25:41 -0400

> which Jamal had mentioned (No IP information).

The necessary contents of the current doc's ARP/ND should be in the encap table.
The IP is still passed if it needs to be used. How it is used is implementation
specific.

> LFB to encapsulate. In this case, the EtherEncap LFB only have some

I didnt follow the above discussion.
Currently, the NH table is populated with an IP address that belongs
to the CE or FE. There is some flag in the table which says "this is
a local packet, therefore send it to the host".
In other words a packet arriving for the CE or FE IP should never reach
the EtherEncap LFB. A packet originated from the CE or FE should
be fine since it is destined for a different IP.
Am i mistaken?

> when it gets a new L2 information.

Ok, maybe Joel followed - I will defer to him.

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Tue, 12 Apr 2011 20:02:38 +0800

Hi,Jamal 
    Please see the inline. Thanks!
======= 2011-04-12 17:18:50 Jamal Hadi Salim, wrote: =======

>The IP is still passed if it needs to be used. How it is used is implementation
Do you mean IP address information still be needed in Encap table?
In previous email, you said no IP information needed by ethernet encapsulator.
So I'm confused. 

>be fine since it is destined for a different IP.
All I have said is based on your suggestion: there is no IP information in Ecap table.
And the packets we discussed are those need to be forwarded to the subnet hosts, not the packets 
which need to be processed on local CE. The later will go out from a special output port of NH LFB to 
RedirectOut LFB.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Apr 2011 08:12:15 -0400

Even with ARP/ND on the FE, the CE will still know what index in the 
EncapTable is assigned to the nexthop.  It will assign that index when 
it creates the nexthop.  It will be marked as pending resolution, and 
will get filled in when the ARP occurs.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Apr 2011 08:17:29 -0400

Is it your thought that we would use one mediaEncap LFB Instance per 
Level 3 output port?  If so, then the output port number in the NH LFB 
is purely diagnostic / informational, and could be removed.
(If we have to send a packet to the CE for ARP, we have to add the L3 
port number metadata then.)

Yours,
Joel

On 4/12/2011 5:05 AM, Jamal Hadi Salim wrote:
> On Mon, Apr 11, 2011 at 7:13 PM, Joel<[email-masked]>  wrote:

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 13 Apr 2011 05:15:26 -0400

Hi Chuanhuang,

On Tue, Apr 12, 2011 at 8:02 AM, Chuanhuang Li
[..]
> In previous email, you said no IP information needed by
> ethernet encapsulator. So I'm confused.

Right, no IP address in the Encap table.

NHIP address is still passed to the Etherencap as metadata.
It is to be ignored by implementation which doesnt do ARP/ND.
The NHIP can be used to do ARP/ND if implementation chooses to.
This will happen if for example, the passed Encap index does
not exist (which should never happen in an implementation that
doesnt use ARP). For implementation that does ARP/ND,
when the ARP/ND is resolved, the Encap table is populated
by CE at a chosen index. This same index is updated to the NH
so it can be used by subsequent packet.
How you do that will depend on implementation - but it seems to
make sense to have the CE do it.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 13 Apr 2011 05:32:42 -0400

On Tue, Apr 12, 2011 at 8:17 AM, Joel M. Halpern <[email-masked]> wrote:
> Is it your thought that we would use one mediaEncap LFB Instance per Level 3
> output port?

That was my initial thinking - but now that you bring it up again,
you made me look closer at figure1...  Other than EtherPHYCop, is there any
need for any other LFB instance to be per-mediaport? Indeed, the reverse
case can be also argued and you have everything per-mediaport.
But we do have ability for grouping of LFB-ports which can be used to mux
to different instances of the same LFB class etc.
Figure1 seems to have have some LFBs FE wide and some mediaport
specific (the mediaencap seems to be port specific).

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Wed, 13 Apr 2011 18:30:05 +0800

Hi,Jamal
    Sorry. From the context, Do you mean : if user need to support ARP/ND on FE, ARP/ND logic should be 
implemented in the EtherEncap LFB,?  And Etherencap LFB includes the defintions of  Encap talbe(no IP information) 
and ARP/ND table(have IP information)? 
    If so, I think there are duplicated definitions about L2 information in this LFB. 
and in my thought, the ARP/ND logic shouldn't be included in EtherEncap LFB.  
    If you mean there is only Encap talbe in EtherEncap LFB, how to resolve the problem which 
I had posted in previous email? (processing packets which need to be forwarded to the subnet hosts.)
    Thanks!

Yours,
Chuanhuang

======= 2011-04-13 17:08:36 Jamal Hadi Salim, wrote: =======

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 13 Apr 2011 06:45:40 -0400

Hi Chuanhuang,

On Wed, Apr 13, 2011 at 6:30 AM, Chuanhuang Li
<[email-masked]> wrote:
> implemented in the EtherEncap LFB,?

If they are going to be implementing ARP, IMO it should not be defined in this
specific LFB. For this LFB we assume something (CE most likely) is going
to populate neighbor L2 information. If you use ARP/ND or have static entries
and how you do so - that is the problem of the implementation, not the model.

> And Etherencap LFB includes the defintions of  Encap talbe(no IP information)

My opinion is to not have any ARP/ND table here. Maybe Joel has a different
opinion.

> and in my thought, the ARP/ND logic shouldn't be included in EtherEncap LFB.

Refer to above.

>forwarded to the subnet hosts.)

Is subnet host meaning "directly connected" routes?
I am not sure if we are distinguishing those from a host that is
say more than one hop away?
To re-iterate what i said earlier about ARP/ND implementation:

NHIP and Encap Table index (or other) are passed to the Etherencap
as metadata. One approach is to try and index with passed index
into Encap Table and fail - which means NH L2 has not been resolved.
At this point, your implementation may do ARP. The model shouldnt
care and should not have information on ARP.
When the ARP/ND is resolved, you will have enough information
so that the Encap table is populated by at a chosen table index.
This same Encap Table index is updated to the NH
so it can be used by subsequent packet (so we dont have lookup
failure in Encap Table).
Does that make sense?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Apr 2011 11:19:33 -0400

THis is a design choice which, as far as I can tell, can go either way. 
  Obviously, we have to have a class per media type, and at least one 
instance per instantiated media type.  Whether we use the logical L3 
output port as a table index, or instantiate an LFB instance per logical 
L3 output port is a decision regarding which I have no preference, but 
we should be explicit.

Yours,
Joel

On 4/13/2011 5:32 AM, Jamal Hadi Salim wrote:
> On Tue, Apr 12, 2011 at 8:17 AM, Joel M. Halpern<[email-masked]>  wrote:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Apr 2011 11:31:52 -0400

The question with regard to the ARP table is how we want to handle 
destination hosts on the local subnet.
We can do it by having an entry in the LPM, NH, and encap LFBs for each 
host.  While that is potentially a lot of entries, it is not too many to 
support (LPMs have to handle 100's of thousands of entries anyway.)

Alternatively, we could have the ARP table in the encap LFB, and just 
have a single "local" entry in the other tables.

Either design works.  In the long run, I think the later is conceptually 
cleaner in that creating an entry for a new host on the subnet means 
modifying only one table instead of three.

Yours,
Joel

---

From: "Chuanhuang Li" <[email-masked]>
Date: Thu, 14 Apr 2011 22:43:16 +0800

Hi, All
I summarzed the points that we had discussed on NH and EtherEncap LFB:
I think we have reached a consensus on the following points.
1: Add an element named "NHEncapInfoIndex" to the NH table component in NH LFB. 
2: Define an element named such as "FillFlag" to indicate whether the table entry had been filled.
3: Continue to have the LogicalPortID element in L2 information table .

And we need pick up a consensus way to solve the following points: 
4: Is L2 information table exactly ARP/ND table? or need redefine an Encap Table with no IP 
information in EtherEncap LFB? 
   L2 information table is exactly ARP/ND table: the current definition of Encap LFB will be changed a little, 
and it can solve the problem of forwarding packets to dirrectly connected hosts. As Joel said, in the long run, 
It is conceptually cleaner.   
Jamal, can you accept this resolution? and do you have any other suggestion?

5: Is "EncapInfoIndex" in L2 information table just the talbe index? or we define it as an element of the table content?
I think we define it as an table element may be good to user to manager the table.
What's your opinion?Thanks!

Yours,
Chuanhuang	

======= 2011-04-13 23:24:37 Joel M. Halpern, wrote: =======