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

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

Hi, Jamal
     About the EtherEncap, please see the following comments.
> 0) Note disappearance of ARP/ND from this draft. Also
> note this LFB is agnostic of IPV4 or IPv6.
> 1) Fix <metadataExpected> to look for OutputLogicalPortIndex
> (as passed from NH) instead of LogicalPortID and note that
> it is not optional.
Chuanhuang: As said in previous email, do you mean "NHEncapInfoIndex"?  
L3 port ID "OutputLogicalPortID" may also be needed.

> 2) We have an alternative table known as EncapTable which is very close to
> ArpTable/NbrTable. We only need one table for both IPV4 and IPV6.
> So assume as a starting point one of these.
Chuanhuang: Sorry. I have to recover the discussion about how to process the 
packets needed to be forwarded to the directly connected subnet hosts. 
If we don't define ArpTable/NbrTable, each directly connected subnet host need 
one routing entry in Prefix and NH table. From implementation experience, the 
general processing way is define an indication in NH table to indicate this routing 
entry is for some directly connected subnet host. In this way we need define the 
ArpTable/NbrTable in EtherEncap.

> i  ) I dont think LogicalPortID (componentID="1") should be part of the 
> table.
> The passed OutputLogicalPortIndex is an _index_ into the EncapTable 
> and therefore does not need to be part of the table.
Chuanhuang: Please see the same considerations in NH table in previous email .

> ii ) DstIPvxAddress is never used in this LFB.

> iii) We merge the VLAN output table into EncapTable.
Chuanhuang: VLAN output table is defined to get VLAN ID and the L2 output port before.  
> the table entry looks like:
Chuanhuang: "FillFlag" definition need to be added to this table according the previous discussion.

>        <dataTypeDef>
>           <name>EncapTableType</name>
>           <synopsis>Ethernet Encapsulation table entry type.</synopsis>
>           <struct>
>              <component componentID="1">
>                 <name>DstMac</name>
>                 <synopsis>Ethernet Mac of the Neighbor</synopsis>
>                 <typeRef>IEEEMAC</typeRef>
>              </component>
>              <component componentID="2">
>                 <name>SrcMac</name>
>                 <synopsis>Source MAC used in encapsulation</synopsis>
>                 <typeRef>IEEEMAC</typeRef>
>              </component>
>              <component componentID="3">
>                 <name>VlanID</name>
>                 <synopsis>VLAN ID.</synopsis>
>                 <typeRef>uint32</typeRef>
>              </component>
>              <component componentID="4">
>                 <name>OutputLogicalPortID</name>
>                 <synopsis>Output logical port ID.</synopsis>
>                 <typeRef>uint32</typeRef>
>              </component>
>           </struct>
>        </dataTypeDef>

Yours,
Chuanhuang

---

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

Chuanhuang,

> L3 port ID "OutputLogicalPortID" may also be needed.

Refer to my other email:
I have added L3portID and suggested a name for the Encap/MediaIndex (I
asked for name suggestion of one or other).

> ArpTable/NbrTable in EtherEncap.

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.

> Chuanhuang: Please see the same considerations in NH table in previous email .

Indeed - once we agree on the name it will apply here.

> Chuanhuang: VLAN output table is defined to get VLAN ID and the L2 output port before.

Can you explain some more? Are you saying we first take the media index
and lookup the vlan table first and therefore it needs to be a separate table?
If that is the case then this vlan table will need to output a new
media index as
well to be used to lookup encap table, no?

> Chuanhuang: "FillFlag" definition need to be added to this table according the previous >discussion.
>

Please refer again to my NH text. I made a slightly different suggestion
which has the advantage of not requiring "FillFlag" entry or metadata . To
quote (modified with "MediaIndex"):

----
CE sets MediaIndex port in NH to a value that is not allocated
in EtherEncap EncapTable. EtherEncap lookup using passed MediaIndex
will fail to find it.
The failure serves as indication some other way to resolve it may be needed.
(Could be ARP etc).
---

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Mon, 25 Apr 2011 10:18:35 +0800

Hi,Jamal

>asked for name suggestion of one or other).

I prefer to  the combined name: MediaEncapInfoIndex. "MediaIndex" seems to only indicate 
selecting a special/different media to encapsulate. 

>well to be used to lookup encap table, no?
These are our consideration before, and had been discussed with Joel:
(Precondition: not using the "MediaEncapInfoIndex".)
NH LFB will generate new metadatas: OutputLogicalPortID, NexthopIPv4Addr. 
In the entry which have been found, if "NexthopOption" is indicated that this 
packet need to be forwarded to local dirrectly connected subnet host, metadata 
NexthopIPv4Addr will be filled with the destination IP address of the packet.
For normal forwarding, next, the packet will be sent to EtherEncapsulator LFB. 
EtherEncapsulator will use OutputLogicalPortID metadata as the key of LogicalPortID 
element to lookup VlanOutputTable to get VlanID and the new OutputLogicalPortID.  
Then it will use this new OutputLogicalPortID and NexthopIPv4Addr metadata to lookup 
ArpTable to get the output Ethernet L2 information. After processed in this LFB, 
metadata OutputLogicalPortID will be updated.
In this simple case, EtherEncapsulator will deliver packets to the correct physical port 
directly.  And the OutputLogicalPortID is exactly the PHYPortID information.
However, if the device is doing bridging as well as routing (or bridging plus host applications 
like management or console services), then after the encapsulation, all that EtherEncapsulator 
knows is what logical port the packet is to be sent on.  The packet must be handed to 
the bridging logic, which will use the logical output port and the destination MAC address 
to decide what physical port to send the frame on, including the possibility that it may need 
to flood the packet out several physical ports, or add additional bridging encapsulations.

I think, If we use "MediaEncapInfoIndex" and merge VLAN output table into media enap table, 
an element, such as named "L2PortID", need to be added into the encap table.

Yours,
Chuanhuang

---

From: "Chuanhuang Li" <[email-masked]>
Date: Mon, 25 Apr 2011 10:26:36 +0800

Hi,Jamal

>The failure serves as indication some other way to resolve it may be needed.
OK, this can solve the problem. We also had used this way to indicate the ARP table having not been flushed.

Yours,
Chuanhuang

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 25 Apr 2011 08:19:30 -0400

Hi Chuanhuang,

On Sun, Apr 24, 2011 at 10:18 PM, Chuanhuang Li
<[email-masked]> wrote:

> I prefer to  the combined name: MediaEncapInfoIndex.
> "MediaIndex" seems to only indicate selecting a special/different media to
> encapsulate.

Ok, changed in my text.

> an element, such as named "L2PortID", need to be added into the encap table.

We already have OutputLogicalPortID - do you mean we need to change the
name to L2PortID?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 25 Apr 2011 08:20:07 -0400

> OK, this can solve the problem. We also had used this way to indicate the ARP table having not been flushed.

I will update the text before posting.

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Mon, 25 Apr 2011 23:40:23 +0800

Hi,Jamal
>We already have OutputLogicalPortID - do you mean we need to change the
Exactly, I'm thinking how to know the L2PortID(or PHYPortID) , If the two tables were 
merged and the merged table was searched by "MediaEncapInfoIndex" key. Where will the L3PortID 
metadata be consumed in the simple routing case ?

Yours,
Chuanhuang

---

From: Joel <[email-masked]>
Date: Mon, 25 Apr 2011 11:45:21 -0400

Remember that if there are LFBs between the NH lFB and the mediaencap 
LFB we will need to know which L3 port processing media encap LFB we 
need to hand the packet to.  As such, we need the L3 port ID as a 
metadatum passed through the system.

Yours,
Joel

On 4/25/2011 11:40 AM, Chuanhuang Li wrote:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

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

Ok, here's my handover text to Chuanhuang so i can move over to the
next issues i have. There are a few XXX in there to point to uncertainties.

cheers,
jamal

On Mon, Apr 25, 2011 at 11:45 AM, Joel <[email-masked]> wrote:
> Remember that if there are LFBs between the NH lFB and the mediaencap LFB we
> will need to know which L3 port processing media encap LFB we need to hand
> the packet to.  As such, we need the L3 port ID as a metadatum passed
> through the system.
>
> Yours,
> Joel
>
>>>> However, if the device is doing bridging as well as routing (or bridging
>>>> plus
>>>> host applications
>>>> like management or console services), then after the encapsulation, all
>>>> that
>>>> EtherEncapsulator

---

From: "Chuanhuang Li" <[email-masked]>
Date: Tue, 26 Apr 2011 19:59:28 +0800

Hi,Joel
    I think that you said is the per-port-etherencap case, and a metadata dispatcher will connect
after NH. Do you mean the NH output metadata "L3PortID" is no use, if all ports use an unified 
EtherEncap and NH connects mediaencap directlly?  Jamal also asked the same question in 
ee-suggested.txt: "XXX: is L3PortID (from NH) consumed here or should we 
be using the term L2PortID for both?"
    Sorry, maybe I have been confused about Logical Port ID again. It seems it's inconsistent 
with the consensus we have reached before.
    In previous email, you said: Given a router, that is also bridging, and sending
a packet out an itnerface which is, underneath IP, bridged across several ports, 
the processing order may be: IPv4LPM -> NextHopApplicator ->
EthernetEncapsulator->LogcalPortOutputHandler->L2Bridging
  
    In my mind, if NH connects EtherEncap directlly, NH output metadata L3PortID will be consumed 
in EtherEncap. by using L3PortID, we can get VlanID and the L2PortID (If the L2PortID exists and can 
be decided in this LFB). If  if the router has L2Bridging function, as you said, there need a LogcalPortOutputHandler 
LFB to settle the Logical port problem,

Yours,
Chuanhuang    

======= 2011-04-25 23:37:31 Joel, wrote: =======

---

From: Joel <[email-masked]>
Date: Tue, 26 Apr 2011 09:47:35 -0400

Your first description is accurate.
In principle therefore, it would at first appear that your second 
conclusion follows (if you use a single media encapsulator for all the 
ethernet ports, then the direct table index could do all the work.)
However, you need to remember that even in that case the design has to 
allow for different media, which will need different encapsulation LFB 
classes.  As such, given that there may be intermediate LFBs, it follows 
that we need a dispatcher, and the L3PortID is the correct conceptual 
dispatcher.  (It means that in some cases we may have multiple parallel 
outputs from the dispatcher going to the same next LFB isntance.  But 
that is not a problem.
I do not want to encode the media type as an explicit metadatum, as 
there are lots of potential complications.

(One example of an alternate media encapsulator which we will need to 
support later is a tunnel and there are multiple kinds of tunnels, with 
new ones being invented.  If we have a media-type metadatum, we have to 
keep expanding it.  If we use the L3PortID, it just works.)

Yours,
Joel