NFD

I don't think this refactoring is really needed (either short or long term). The self-discovery doesn't really need to know that two faces are connected. If it for some reason needs it, it can be accomplished via adding some Face API call without major refactoring.

The self-discovery doesn't really need to know that two faces are connected.

Self-learning doesn't need to know the relation between two existing faces. It needs to unicast toward a remote endpoint on top of a broadcast or ad hoc wireless face.

it can be accomplished via adding some Face API call without major refactoring.

If unicasting requires creation of a separate point-to-point face, the alternative solution would lead to much higher overhead: face creation triggers a notification in management. When an old face is recycled (destroyed), it triggers another notification, and triggers a cleanup action in FIB and PIT that enumerates these tables.

This refactoring simplifies Ethernet implementation. Ethernet faces no longer have to update pcap string whenever a unicast face is created or destroyed.
However, for the purpose of self-learning, it isn't required to remove the existing "unicast Ethernet tunnel". Adding unicast capability to Ethernet (multicast) faces would be sufficient.

Please correct me if I'm wrong. Form what I understand, the following functionalities are expected:

• Add Ethernet Unicast functionalities in the Ethernet Multicast face (need a bit more ).
• Have a method like getEndpointId() to fetch the remoteEndpoint of a received packet over this Ethernet Multicast face. This method helps to provide the EndpointId for the FIB's NextHop entry in Self-learning when Data comes back.

Junxiao Shi wrote:

This refactoring merges Ethernet multicast and Ethernet unicast communication over the same NIC into a single Ethernet face.
The new EthernetTransport considers EndpointId field on both directions. An outgoing packet is unicast if EndpointId represents a neighbor, or broadcast if EndpointId is empty. For an incoming packet, the EndpointId field is set to indicate the sender of this packet.

Here, you said broadcast a packet when EndpointId is empty. Does this mean a null value or simply 0?

Add Ethernet Unicast functionalities in the Ethernet Multicast face (need a bit more ).

Yes, and rename them to just Ethernet face.

Have a method like getEndpointId() to fetch the remoteEndpoint of a received packet over this Ethernet Multicast face. This method helps to provide the EndpointId for the FIB's NextHop entry in Self-learning when Data comes back.

It's less intrusive to use a tag similar to IncomingFaceIdTag.
You may even consolidate EndpointId into IncomingFaceIdTag, since these two always go together.

An outgoing packet is unicast if EndpointId represents a neighbor, or broadcast if EndpointId is empty.

Here, you said broadcast a packet when EndpointId is empty. Does this mean a null value or simply 0?

nullptr and 0 have same semantics. An EndpointId-aware strategy should normally use 0, while a legacy strategy would not set a tag and it's nullptr. In either case, the transport broadcasts the packet.
Note that "broadcast" here means sending to NDN multicast group address, not the Ethernet broadcast address. It's called "broadcast" because semantically it's broadcasting to all NDN nodes.

esp8266ndn's EthernetTransport is an example of the expected semantics.