Re: [rbridge] An ARP/ND draft

[Donald Eastlake <[e-mail]>]

Hi Linda,

On Mon, Jul 12, 2010 at 6:47 PM, Linda Dunbar <[e-mail]> wrote:
> Hi Donald,
>
> Reading through your draft, I have several questions. Hope you can explain:

Thanks. I'll try...

> 1.      Page 8 Figure 3.1 ARP Frame Format:
>
> a.      Why there is no 3 bits Priority tag and 12 bits VLAN tag in your
> frame format?

It should probably be shown in that figure. But a VLAN tag might not
always be there, depending on whether an end-station added the tag or
a bridge or egress RBridge port stripped out the VLAN tag.

> b.      The MAC DA is a broadcast address: ff:ff:ff:ff:ff:ff, right?

Many ARP frames are broadcast to that address but some can be unicast.
The reply to an ARP query can be either unicast or broadcast.

> 2.      Section 2.1.1, bullet 3: you stated "encapsulate the query to the
> target's egress RBridge". The ARP query will have broadcast DA. How does
> RBridge know which Egress RBridge it is?

It can do this encapsulation and unicasting only if it knows the
egress RBridge for the target IP address in the ARP request.

>                                                                  I realized that you want all
> RBridge to snoop every ARP query traversing by to record the MAC-IP mapping.
> But there is no information on the egress RBridge, is there? A typical ARP
> Proxy will change Broadcast to an Unicast if the target IP is found its
> cache. Why not use similar mechanism?

RBridges already learn MAC-->egress-RBridge mapping. So, if they learn
IP-->MAC mapping, they can then map IP-->MAC-->egress. Seems to me
that the mechanism is similar to what you describe for an ARP proxy.

> 3.      It is very possible that ARP broadcast message will traverse
> multiple RBridges, does it mean all RBridge will process those message and
> send multiple Unicast ARP queries to the target host?

No. Special treatment of ARP/ND is only at the first and/or last
RBridge, the ingress and egress. That is why 2.1.1 is called "Native
Queries ...". In TRILL a "native" frame is one that has not yet been
TRILL encapsulated. Once it is encapsulated, it is just a TRILL data
frame and any transit RBridges it goes through take no special action
(as it says for ARP in Section 3.2).

>                                                                                   If some RBridges has
> the entry and others don't, the target host will receive bunch of ARP
> broadcast messages in addition to some Unicast ARP query. It will create a
> lot of traffic into the network.

Right. So it is the ingress RBridge, the first RBridge that accepts
the original unencapsulated native ARP/ND query that decides what to
do. It can just reply, if it knowns enough. Or it can flood the ARP/ND
as a broadcast/multicast. Or it can unicast it to what it believes is
the RBridge directly connected to the end-station with the target IP
address, in which case it encapsulates the query to that RBridge as
egress.

Unless the ingress RBridge responds directly, the encpasulated ARP
query is then processed at transit RBridges just like any TRILL data
frame.
      If it is unicast, it is just routed hop-by-hop to the egress.
      If it is broadcast, it is sent on a distribution tree. And, in
the broadcast case, every RBridge, if it has stations connected to the
VLAN of the ARP query, also acts as an egress, decapsulating a copy of
the original ARP query frame, and sending it out on local links that
are in the frame's VLAN.

> 4.      Section 2.1.2, second paragraph: You stated that Rbridge
> "peridocially repeats flooding this query for a limited number of times if
> it has not received a response". I don't think it is good practice and it is
> really not necessary. Host, who initiate the ARP request, will repeat the
> request if there is no response. Therefore, intermediate bridges (or
> Rbridges) should not generate the ARP request.

This is something we can discuss.

First of all, it is only the ingress RBridge that is doing this, not
any other intermediate (transit) RBridge. Second, what if the end
station sends too many ARPs too quickly? Or what if lots of different
end stations send the same ARP at about the same time? My idea was to
put the ingress RBridge in charge of any needed repeat queries. When
the ingress RBridge is doing this, it would throw away any repeated
identical native query frames from one or more end stations.

But this could be handled differently or which mode it was using could
be controlled by configuration...

> 5.      Section 3: Your statement "…maintains a cache with a mapping between
> IPv4 and VLAN to MAC address in the same VLAN" is confusing. Do you mean
> maintaining a cache with IP and MAC-VLAN mapping?

The wording should be improved. I was trying to say a cache of IPv4 to
MAC address mapping per VLAN. After all, if you are careful, you can
have the same MAC address or the same IP address appear in different
places in different VLANs.

> 6.      Section 3 Bullet 3: Why need to keep track of IP addresses for
> Rbridge ports? Hosts only send ARP for other hosts. They don't send ARP
> request with target being intermediate switches/bridges port.

If an RBridge has no IP addresses, then there is nothing to keep track
of. But, while RBridges are designed so they do not need IP addresses,
I think it will be common for them to have an IP address for SNMP, or
so you can SSH to them for control, or for other reasons. If an
RBridge does have an IP address, it should automatically know its
mapping to a MAC address.

> 7.      Section 5, second paragraph: "leared"? Is it a typo?

Yes, thanks, should be learned.

> 8.      You mentioned in several places of "frame's VLAN maps". (e.g. "Learn
> that the Sender IPv4 Address in the frame for the frame's VLAN maps") What
> is "frame VLAN maps"?

Ahhh, this wording needs to be improved so the grouping is clear. It
is not "Learn that the Sender IPv4 Address in the frame for the
(frame's VLAN maps)" but more like "Learn that ((the Sender IPv4
Address in the frame) for the frame's VLAN) maps"... I'll try to make
it clearer in the next version...

> Thanks, Linda Dunbar

Thanks,
Donald

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Donald Eastlake
> Sent: Tuesday, July 06, 2010 10:26 PM
> To: [e-mail]
> Subject: [rbridge] An ARP/ND draft
>
> An early ARP/ND draft is available at
>
> http://pothole.com./~dee3/drafts/draft-eastlake-trill-rbridge-arp-xx.txt
>
> It is primarily based on material that was in the -03 and earlier
>
> versions of the TRILL base protocol draft. It was not submitted in
>
> time to get into the Internet Draft directories before the upcoming
>
> IETF meeting.
>
> Thanks,
>
> Donald
>
> =============================
>
>  Donald E. Eastlake 3rd   [phone] (cell)
>
>  155 Beaver Street
>
>  Milford, MA 01757 USA
>
>  [e-mail]
>
> _______________________________________________
>
> rbridge mailing list
>
> [e-mail]
>
> http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge