Subject: [rbridge] An ARP/ND draft

From: Donald Eastlake <[email-masked]>
Date: Tue, 6 Jul 2010 23:25:51 -0400

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   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 12 Jul 2010 17:47:58 -0500

Hi Donald, 

Reading through your draft, I have several questions. Hope you can explain:

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? 
b.	The MAC DA is a broadcast address: ff:ff:ff:ff:ff:ff, right?
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? 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? 
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? 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. 
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. 
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? 
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. 
7.	Section 5, second paragraph: "leared"? Is it a typo? 
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"? 

Thanks, Linda Dunbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Donald Eastlake
Sent: Tuesday, July 06, 2010 10:26 PM
To: [email-masked]
Subject: [rbridge] An ARP/ND draft

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 13 Jul 2010 00:17:22 -0400

Hi Linda,

> Reading through your draft, I have several questions. Hope you can explain:

Thanks. I'll try...

> a.      Why there is no 3 bits Priority tag and 12 bits VLAN tag in your

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.

> 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

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.

> 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

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.

> 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

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.

> 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.

> that the Sender IPv4 Address in the frame for the frame's VLAN maps") What

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,
Donald

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jul 2010 16:24:30 -0700

Hi, Donald,

I agree with Linda that this is just describing an existing mechanism to 
respond with a cached ARP reply (not proxy ARP, though - see below). 
IMO, that means this doc could boil down to a few simple sentences, 
i.e., that the rbridge ingress can perform cached ARP reply. What else 
is there to really add?

NB: proxy ARP is when you respond NOT with the intended destination MAC, 
but with *your own*, i.e., it is intended for cases where you will act 
as a relay for subsequent traffic.

On other points:

I think this doc warrants a specific security considerations section. In 
particular, it can amplify the effects of ARP poisoning, as it presents 
another place where proxy ARPs could continue to respond with incorrect 
information.

Further, the third alternative (forward the ARP to the known egress 
rbridge) defeats visibility of such requests by the legitimate receiver 
if on another egress, which defeats its ability to respond with a 
potentially colliding (and thus informative) response.

This seems worth noting, IMO.

As others have noted, I don't see the utility in variant 3 (forward the 
ARP to the known egress). Either the ingress knows the ARP response and 
can proxy it, or it does not, in which case why would it know the egress 
merely from the L2 info? I don't see why an rbridge would cache the 
egress:IP correlation and not simply cache the proxy ARP response. 
What's the benefit to this alternative?

As others have noted, rbridges should not repeatedly flood ARPs. That's 
the source's job. I don't see utility - or safety - in assuming that 
ingress rbridges throttle or otherwise affect ARP traffic. IMO, they 
either proxy it or leave it alone (and broadcast it). Whatever it does, 
it should do for every ARP it sees independently, statelessly.

Joe

---

From: Michael Kantowski <[email-masked]>
Date: Fri, 16 Jul 2010 17:01:34 -0700 (PDT)

I agree with Joe's final statement about stateless handling of ARP.  After all, 
neither bridges nor routers do this sort of advanced ARP handling, so why should 
rbridges take this on.  Isn't the amount of steady state broadcast traffic 
something that we worried about on hubs?

Unless we are concerned that TRILL will lead to the creation of humongous 
broadcast domains, perhaps ARP optimization/handling should be toned down to the 
bare essentials.

-mike

----- Original Message ----
From: Joe Touch <[email-masked]>
To: Donald Eastlake <[email-masked]>
Cc: [email-masked]
Sent: Fri, July 16, 2010 6:24:30 PM
Subject: Re: [rbridge] An ARP/ND draft

Hi, Donald,

On other points:

Joe

---

From: Radia Perlman <[email-masked]>
Date: Fri, 16 Jul 2010 17:21:14 -0700

As the draft says, when an RBridge receives a native ARP/ND, it has
three choices:
a) forward it like any multicast
b) proxy
c) unicast to the suspected egress RBridge

The first is most costly, but is (presumably) most definitive. The
second is least costly, but has the problem that if the cache at the
ingress RB is incorrect, it will leave a black hole. The third can be
done in cases where the ingress thinks it knows who the egress is, but
wants to check, without doing a full broadcast.

In theory, bridges could do something like this. And perhaps there
could be some sort of generic mechanism. But TRILL is an ideal place
for this sort of thing because it straddles layers 2 and 3. It can
pass layer 3 information such as (layer 3, layer 2) addresses in
ESADI.

In theory this really was in the original charter of TRILL, since it
was in the original document that TRILL was based on. It was deferred
though, since the mechanisms all could be done optionally, and
therefore, added incrementally.

One comment that was made in this thread was that the source endnode
should rate-limit, and not the ingress RBridge. Sure...the source
should rate-limit. But having the RBridge rate limit (in addition)
handles the case of a misbehaving source, as well as multiple sources
looking for the same destination.

Radia

---

From: James Carlson <[email-masked]>
Date: Sat, 17 Jul 2010 10:29:19 -0400

> broadcast domains, perhaps ARP optimization/handling should be toned down to the 

I think that "humongous broadcast domains" is pretty much the focus of
the mechanism at hand.  With moderate-sized networks, nobody really
cares.  In fact, for most networks I've looked at, finding a way to
quiet down the chatty broadcast application protocols that some vendors
like to use would do much more to restore sanity than any ARP tweak.

But given the analogies with both regular unicast and multicast with
IGMP snooping, I think it's not a bad idea to document this _possible_
optimization -- perhaps with caveats about the known dangers -- rather
than just leaving it to the imagination.

(Though, really, I do prefer leaving optimizations and deployment
specifics to the imagination, because what's true today may well change
tomorrow, and it's hard to predict how smart -- or dumb -- implementers
will be.)

I do think we're losing sight of the fact that this is an IETF document.
 There's no "conformance" specified.  Implementers are free to make
choices that they think will make the protocol work better, or will give
them advantages in certain markets, or even to correct mistakes that
we've made.  Attempting to constrain the results overly just won't work.
 We don't have the control we might imagine.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Joe Touch <[email-masked]>
Date: Sat, 17 Jul 2010 08:21:21 -0700

Hi, James,

On 7/17/2010 7:29 AM, James Carlson wrote:
> the mechanism at hand.

As per the PAS doc (RFC5556), Sec 2.6:

    Solutions to TRILL need not support deployment of larger scales of
    Ethernet link subnets than current broadcast domains can support
    (e.g., around 1,000 end-hosts in a single bridged LAN of 100 bridges,
    or 100,000 end-hosts inside 1,000 VLANs served by 10,000 bridges).

If this is all about supporting scales beyond current deployments of 
ethernets, it is neither needed nor in-scope for this WG.

Joe

---

From: Eric Gray <[email-masked]>
Date: Sat, 17 Jul 2010 20:43:06 -0400

Radia, 

	See "EG> " below...

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
Sent: Friday, July 16, 2010 8:21 PM
To: [email-masked]
Subject: Re: [rbridge] An ARP/ND draft

EG> Actually, until you include stuff like ARP Optimization, TRILL
EG> does nothing of the sort.  TRILL uses a shortest-path determination
EG> algorithm commonly used in L3 routing, but use a particular version
EG> that is addressing-agnostic - for L2 destinations.  TRILL otherwise
EG> uses L2 forwarding with an extra (shim) header (which itself has no
EG> legitimate association with L3).
EG> 
EG> Basically, RBridges use SPF routing to control unicast forwarding 
EG> of L2 frames.  There is nothing about this that feels to me like
EG> "straddling" L2 and L3...

--- [SNIP] ---

---

From: Joe Touch <[email-masked]>
Date: Sat, 17 Jul 2010 18:14:13 -0700

> 	See "EG>  " below...
...
> EG>  "straddling" L2 and L3...

This was my view as well - AFAICT, nothing in TRILL tracks L3 addresses. 
There may be snooping of L3 (or more specifically L2/L3) protocols, such 
as IGMP and ARP, but no tables of IP addresses.

IMO, this "optimization" is a bad place to start that. It presents a new 
opportunity to do things in the name of optimization that could be 
incorrect and hard to debug, or worse, present new vulnerabilities.

Consider the three choices:
a) forward it like any multicast
b) proxy
c) unicast to the suspected egress RBridge

IMO, #3 should be omitted, as it cannot be implemented without tracking 
L3 addresses.

Joe

---

From: Eric Gray <[email-masked]>
Date: Sat, 17 Jul 2010 21:56:23 -0400

James,

	In response to the message in which you said (in part): 

"I do think we're losing sight of the fact that this is an IETF document.
 There's no "conformance" specified.  Implementers are free to make
 choices that they think will make the protocol work better, or will give
 them advantages in certain markets, or even to correct mistakes that
 we've made.  Attempting to constrain the results overly just won't work.
 We don't have the control we might imagine."

You are pretty much correct.  It is very difficult to prevent people from
putting really silly stuff in an RFC.  So much so that many people share
your view that there is no conformance specified in IETF documents.

That is NOT an excuse for an argument that we shouldn't try to do better.

There are plenty of examples in the networking industry where a protocol
has been defined based on interesting results reported from laboratory
(or "toy") networks and early implementation.  In some cases, these are
sufficiently interesting that they "capture the imagination" of customers
and end up in (possibly wide-spread) deployment.  

It is frequently the case (in the networking industry, at least) that we
discover scaling issues only after wide-spread deployment is a fact.  In
the IETF, the fact that "we don't have the control we might imagine" is
a big factor in making the IETF pretty far from the least offender when 
it comes to this sort of behavior.

Unfortunately, the easiest sanity test to over-ride is anything that is
based on the (quite reasonable) supposition that we should slow things
down so that "the experts" can take a look at them.  This flies in the
face of the fundamental way that the IETF works in two ways:

1) The IETF (usually) focuses on work in areas where they are the experts
2) Whether or not point 1 is correct in any particular instance, the IETF 
   expects "the experts" to find the time necessary to keep up with what 
   is going on.

If these things are not true, however, then having the IETF documenting 
each and every optimization that might come to mind can be a really BAD 
idea.  At least leaving it to the imagination does no lasting harm to our 
credibility as an SDO...

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 17 Jul 2010 22:13:22 -0400

Hi Joe,

On Fri, Jul 16, 2010 at 7:24 PM, Joe Touch <[email-masked]> wrote:
> respond with a cached ARP reply (not proxy ARP, though - see below). IMO,
> that means this doc could boil down to a few simple sentences, i.e., that
> the rbridge ingress can perform cached ARP reply. What else is there to
> really add?

Even just within the scope of ARP/ND optimization for RBridges there
are things like
- differentiation between handling at ingress, transit, and egress
- ESADI distribution of information
- confidence: TRILL has the facility for learned MAC information from
different sources to have confidence levels associated such that
information with a higher confidence level dominates. I don't see why
you wouldn't want to do a similar thing for learned IP address
information.
- configuration: especially if you are using ESADI, it seems likely
that some mechanism should exist to assure consistent configuration of
any timing variables in ARP/ND optimization at various RBridges.

While I'm not claiming this is rocket science or anything, it seems to
me that ARP/ND optimization for RBridges is significantly more than I
understand you to have been implying. And I think it is more than a
few sentences.

> NB: proxy ARP is when you respond NOT with the intended destination MAC, but
> with *your own*, i.e., it is intended for cases where you will act as a
> relay for subsequent traffic.

Agreed, that is the usual use.

> Further, the third alternative (forward the ARP to the known egress rbridge)
> defeats visibility of such requests by the legitimate receiver if on another
> egress, which defeats its ability to respond with a potentially colliding
> (and thus informative) response.
>

Those are good points to mention in the Security Considerations.

> As others have noted, I don't see the utility in variant 3 (forward the ARP
> to the known egress). Either the ingress knows the ARP response and can
> proxy it, or it does not, in which case why would it know the egress merely
> from the L2 info? I don't see why an rbridge would cache the egress:IP
> correlation and not simply cache the proxy ARP response. What's the benefit
> to this alternative?

I think that ARP/ND optimization should conceptually cache IP-->MAC
mappings, as it says in the draft. And RBridges already have
MAC-->egress mappings. So, conceptually, variant 3 can be implemented
by going through a two stage IP-->MAC-->egress mapping, although you
can obviously implement all of this however you want.

To some extent we are using "ARP" to stand for ARP/ND/SEND and I
believe that you need the third variant for SEND (Secure ND). However,
the 3rd variant is primarily intended for confirmation and you can
imagine it interacting with cache timing in a number of ways.
      Consider the following as an example which assumes no ESADI and
no statically configured information for simplicity: if you get an ARP
query  and have no information about the target IP address, you flood
it (possibly rate limited, a different argument.) If you get a
response, you cache the IP-->MAC mapping in the response as well as
returning it to the original client. In this example method, cache
entries never time out but have two timers associated with them, an
"age" timer that starts counting up as soon the the entry is added
(and the oldest are discarded if the cached overflows) and a
confirmation timer described below. If you get a query matching a
cache entry with age <t1, you just respond locally. If the cache entry
age is >t1 you enter a confirmation cycle and the confirmation timer
for the entry is set to t2, unless the entry is already in a
confirmation cycle, and the confirmation timer counts down. There are
several variations possible but the basic idea is that when you get an
ARP response confirming (or updating) the cache entry, you re-set the
age to zero and terminate the confirmation cycle but if you con't get
a response back, the entry is removed when the confirmation timer gets
to zero.
      The "stateless" version would be that you just forward a client
query you get for an entry with age >t1 to the egress (as well as
starting a confirmation cycle if it isn't already in one). If the
confirmation timer counts down all the way and the cache entry is
cleared, the next query will be broadcast. (You could have an even
simpler version without the confirmation cycle timer, so if the cache
entry is old, the next client query is sent as unicast but any after
that, before a response, would be flooded, but this wouldn't perfom
too well if you got a burst of ARP queries.)
      Jumping to the stateful version, in the spirt of the current
early draft, the RBridge would logically discard the original client
query and take over confirming the old cache entry but would remember
the client and any other clients that query for the same IP during the
confirmation cycle. The RBridge would transmit some number of queries
to the egress where it believes the IP address is, then try flooding a
query if the queries encapsulated as unicast to the egress don't
produce any response.
       Meanwhile, the egress has similar logic and can respond
directly to queries it decapsulates based on young local cache entries
but, if the cache entry is old, enters a local confirmation cycle.
Simlar statefulness possibilities are available here, it is just that
it is sending out native query frames on a local link.

In the stateful model you could have two layers of aggregation of
queries. So, for example, 10,000 end stations could wake up at around
the same time and try to access the same server they last talked to a
week ago. If they are hooked 100 each to 100 RBridges and the
information is still in cache, you end up with just 100 queries
forwarded as unicast to the remembered egress RBridge which can either
respond immediately, if the server was recently active, or can
aggregate down to one query send on the link where the server is
believed to be attached.

I've got no problem with the stateful model being optional and the
stateless model being the default but the rate limiting stateful
behavior seems like it could be useful if someone wants to implement
it.

In any case, the ability to use "old" cached IP-->MAC mapping as a
hint for an RBridge to try first when a query comes along seems like
it could significantly reduce broadcasts.

Thanks,
Donald

...

---

From: Joe Touch <[email-masked]>
Date: Sat, 17 Jul 2010 22:37:36 -0700

> it could significantly reduce broadcasts.

OK, I'll bite. Why is this useful?

And - more importantly - how do you debug it when it is wrong or 
spoofed? Are you really asking users of this "optimization" to wait for 
some (new) timeout to get their hardware to work as expected?

AFAICT, either the ingress rbridge knows the ARP response or it doesn't. 
If it doesn't, it should clearly NOT be limiting the scope of the ARP in 
finding the address.

Joe

---

From: Radia Perlman <[email-masked]>
Date: Sat, 17 Jul 2010 23:01:53 -0700

Reading through this thread, there seems to be one misconception:

When "unicasting" an ARP/ND query to the probably egress RBridge, (say
R2) the Ethernet frame as transmitted by the source does *not* have to
be modified in any way.

The ingress RBridge, say R1, merely encapsulates it as a unicast TRILL
frame (by not setting the multidestination bit in the TRILL header,
and putting the nickname R2 into the egress field.

------
As for the various possibilities for verifying the ARP cache: if R1
thinks it knows the answer, rather than flooding the
query, it can
a) proxy ARP and assume it just knows
b) unicast the ARP to R2, and only if it doesn't get a response, then
flood an ARP

The idea is that R1 might think it knows, just like bridges think they
know where an endnode MAC is, but they discard it on a timeout in case
it's wrong. This optimization gives an RBridge an opportunity to
cheaply verify an entry.

Radia

---

From: Arien Vijn <[email-masked]>
Date: Sun, 18 Jul 2010 17:23:05 +0200

On Jul 18, 2010, at 4:13 AM, Donald Eastlake wrote:

[..]

> it could significantly reduce broadcasts.

For what I have seen in practice, the far majority of broadcasted ARP queries are for unreachable hosts cq. unused IP addresses. The broadcast levels are significantly lower for reachable hosts. 

It is the same story with regards to IPv6. The total level of ND messages for unknown addresses is considerably higher than for reachable addresses. However, hosts only have to listen to their own multicast group. All other queries can be ignored by the NICs.

For example, I just looked at one of my routers. It transmitted 1047 IPv6 ND queries over a five minute period. Of which, 1041 queries were for 15 non-existing addresses. So 6 queries would have been optimized and 1041 would have been flooded. 

Hence I think that mapping known IPs to MACs would reduce broadcasts/multicasts due to ARP/ND queries by just a tiny bit. Blocking futile queries would significantly reduce broadcasts/multicasts.

My 2 euro cents.

-- Arien

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 18 Jul 2010 12:43:40 -0400

Mostly, this seems to be describing something that we have looked at as 
being tricky but having some benefit in some other contexts.

I do wonder about some of the tricky bits.  For example, it is possible 
for an IP address to "move."  A gratuitous ARP response is how this is 
often communicated.  If that message gets lost (they are unreliable), 
this behavior would seem to amplify the effect, causing even stations 
taht were not communicating with the moved client across the move to be 
unable to now establish communication.  In general, we have to look at 
how the information will be maintained accurately.
(In the most critical cases, the MAC address itself moves, and the 
RBridge maintenance techniques will, as I understand it, take care of 
those cases.)

Yours,
Joel M. Halpern

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 18 Jul 2010 13:05:06 -0400

Right. So you should also cache negative results. Which requires state.

Donald

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 18 Jul 2010 13:24:51 -0400

Hi Joel,

On Sun, Jul 18, 2010 at 12:43 PM, Joel M. Halpern <[email-masked]> wrote:
> I do wonder about some of the tricky bits.  For example, it is possible for
> an IP address to "move."  A gratuitous ARP response is how this is often
> communicated.  If that message gets lost (they are unreliable), this
> behavior would seem to amplify the effect, causing even stations taht were
> not communicating with the moved client across the move to be unable to now
> establish communication.  In general, we have to look at how the information
> will be maintained accurately.

If you are worried about accurate maintenance, then you should use
ESADI and periodic local verification. Then the gratuitous ARP need
only reach the ingress RBridge. That RBridge can then use ESADI to
propagate the information with extremely high reliability to all other
ingress/egress RBridges in the same VLAN. And, even in the absence of
getting a gratuitous ARP, the local periodic verification will detect
the departure of an IP address from a link so future ARPs would be
broadcast. Periodic local verification when you are using ESADI was
mentioned in the TRILL base protocol specification up through version
-03 when all of the ARP/ND optimization stuff was remove to simplify
the draft with the intent that it be put in a separate draft. Periodic
local verification is mentioned in the -xx pre-draft since some of the
text in the -xx draft was simply cut and pasted, with a little
editing, from the early base protocol specification.

> (In the most critical cases, the MAC address itself moves, and the RBridge
> maintenance techniques will, as I understand it, take care of those cases.)

If RBridges are using the default behavior of learning MAC addresses
from the data plane, they will be no better or no worse than bridges
in this regard. If they are using ESADI to propagate information about
the MAC address in question, then a MAC attachment update can
propagate more rapidly, reliably, and widely.

Thanks,
Donald

---

From: Arien Vijn <[email-masked]>
Date: Wed, 21 Jul 2010 16:04:51 +0200

> Right. So you should also cache negative results. Which requires state.

That is true, and probably undesirable because of scaling limitations.

It would be better if routers would back off when results continue to be negative. That would be cleaner because it keeps state where it belongs, at the edges.

-- Arien

---

From: Benson Schliesser <[email-masked]>
Date: Wed, 21 Jul 2010 15:23:53 -0500

> It would be better if routers would back off when results continue to be negative. That would be cleaner because it keeps state where it belongs, at the edges.

Increasing timers in response to negative results would not be perfect: bringing up new hosts could require a long wait (for the backed-off ARP timers to expire) or an explicit reset ('clear arp timer x.x.x.x' or whatever).  In some circumstances this could be seen as a DoS vector.  This could perhaps be improved by hosts that send gratuitous ARP messages, implicitly resetting timers in the routers etc. (Perhaps this is another DoS vector...)  However, both the back-off timer and gratuitous ARP behavior would have to be implemented in hosts as well as routers to make this a good solution across an entire datacenter.

I'd rather see some form of state in the network edge, such as an RBridge that knows what MAC addresses are valid and performs proxy ARP.  Assuming it could learn valid MAC addresses quickly then it would isolate broadcast requests to the link they're received on. (Quick learning might rely on gratuitous ARP and/or MAC distribution through i.e. IS-IS; a separate discussion, I think.)

Cheers,
-Benson

---

From: Jukka Manner <[email-masked]>
Date: Tue, 27 Jul 2010 14:13:41 +0200

Hi,

This RFC was mentioned a few minutes ago at the WG meeting, it 
introduces much of the same broadcast to unicast optimizations as people 
are discussing:

http://tools.ietf.org/html/rfc2643

Regards,
Jukka

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Jul 2010 08:44:34 -0400

Thanks. Another RFC that people may want to look at is RFC 5227:
"IPv4 Address Conflict Detection".

Thanks,
Donald