Subject: [rbridge] it's time to summarize things

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 15 Dec 2005 13:32:32 -0500

Joe,

	We're getting closer, maybe, on this one.  Please
see below...

__
Eric

--> -----Original Message-----
--> From: Joe Touch [mailto:touch at ISI.EDU] 
--> Sent: Thursday, December 15, 2005 12:11 PM
--> To: Gray, Eric
--> Cc: Radia.Perlman at Sun.COM; 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> 
--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	I've addressed this issue before, just as you have
--> > raised it before.
--> > 
--> > 	Assuming that "external nodes" below refers to the
--> > portions of the L2 broadcast domain that are topologically
--> > outside of the RBridge campus, the RBridge campus actually
--> > looks to external nodes as if it is a (possibly largish)
--> > collection of L2 frame sources and sinks.
--> 
--> For internal traffic, sure. For ingress/egress traffic, 
--> this would need to hijack ARP to work.
--> 

Why?  ARP, at least the ARP I am familiar with, allows for the
conversion of an IP address into a LAN-local MAC address (much
the same as DNS allows for conversion of a network name into an
IP address).

The RBridge campus forwards ARP - just as the local and remote 
LAN segments do - and the appropriate entity (an L2 source/sink
such as a router or host) responds.  Why would RBridges care
about - or interfer with - ARP?

--> To external nodes, the rbridge MUST act like a transit, not 
--> a source or sink.
-->

I think we're in agreement here.  My statement was as to how the
RBridge campus "appears" to the rest of the network.  Yours is to 
how an RBridge campus "acts."

Obviously the campus does not "act" like a source or sink.  If it
did, it would be a gibbering black-hole.  It merely appears like
a collection of sources or sinks to external nodes.

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 15 Dec 2005 11:01:40 -0800

> about - or interfer with - ARP?

Because somehow the traffic from external nodes needs to arrive at
ingresses. Ingresses don't have (or at least don't use) external
addresses; the traffic from external nodes needs to arrive at ingresses
based on the external spanning trees, NOT based on being addressed to
ingresses.

In fact, there is NO external traffic that should ever be directed at an
ingress address - thus I believe that rbridge campuses do not
participate in ARP. That is a substantial difference from a router,
which DO participate in ARP.

Which means that the rbridge campus does NOT look like a collection of
sources and sinks to external devices w.r.t. ingress/egress traffic. The
only aspect in which rbridges DO look like conventional sources/sinks is
for internal traffic.

> how an RBridge campus "acts."

I'm confused about the difference. If all you mean by source/sink is
'traffic goes in that direction', then you're talking about
upstream/downstream channels, not sources or sinks. IMO, a source/sink
appears as a source/destination in a packet haeader, and (I now think we
agree) that never happens for ingress/egress traffic.

> a collection of sources or sinks to external nodes.

I'm not sure how that description is useful. Can you explain how?

Joe

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Thu, 15 Dec 2005 14:38:02 -0500

> based on the external spanning trees, NOT based on being addressed to

Let us suppose that an RBridge is connected to a legacy bridge's port
directly, and all RBridges block BPDUs. Then the RBridge looks like, from
the perspective of the legacy brige, either (i) a single end-host (with the
MAC address that of the RBridge) if the RBridge is not the designated
RBridge, or (ii) a shared media (like a hub; is the standard term
"segment"?) with potentially a lot of MAC addresses attached to it (in fact,
all the MAC addresses whose packets this designated RBridge forwards),
including the MAC address of the RBridge, but no other legacy bridge, if the
RBridge is the designated RBridge. In both cases, that port of the legacy
bridge will be in the forwarding state. Thus, any broadcast traffic,
including ARP packets, will reach the RBridge. The ARP packet will then be
encapsulated and forwarded over the RBridge-based broadcast tree by the
designated RBridge, and decapsulated and forwarded over every legacy part by
each designated RBridge. Now suppose that the inquirer end-host has MAC
address A and it was looking for MAC address B. Then, in the reverse path,
all the legacy bridges that form the legacy part of the network that holds
the end-host with MAC address B will associate the MAC address A with the
"direction" of the RBridge that is designated for this legacy part, and the
answer to the ARP query will also come back (as a unicast traffic) without
any problem. The ARP (and any broadcast traffic) cannot loop in the
steady-state.

So what exactly do you think is the problem with ARP?

---

From: shep at alum.mit.edu (Tim Shepard)
Date: Thu, 15 Dec 2005 18:42:03 -0500

> "segment"?) with potentially a lot of MAC addresses attached to it (in fact,
[....]
> So what exactly do you think is the problem with ARP?

I'm not sure I follow all of the postings on this issue.

But after reading through this thread, I'm still left wondering what
is supposed to make sure packets don't loop forever when there are a
mix of bridges and rbridges plugged together (in some crazy accidental
way, creating whatever kind of loop involving bridges and rbridges
that causes the most trouble).

It seems to me that if rbridges block the spanning tree forming
packets, but do forward (e.g.) ARP traffic, then there could be loops
that are not broken by either the rbridge system or the usual bridge
spanning-tree-forming algorithm.

Could someone explain succinctly (for someone who is just barely
following this thread) how a system (of mixed bridges and rbridges,
plugged together by some Byzantine net admin) will ensure that packets
are not forwarded in a loop?

(And ARP is a good example, since it is supposed to go everywhere, but
not loop.)

Or will there be configuration rules that forbid some ways of plugging
together bridges and rbridges?

			-Tim Shepard
			 shep at alum.mit.edu

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Thu, 15 Dec 2005 19:10:52 -0500

The simplest, if not the most rigorous, explanation is as follows. Replace
each legacy part of the network by a hub (i.e., first remove all RBridges
from the topology. Then choose a legacy bridge and replace this bridge and
all legacy bridges that have a path to it by a single hub, and let all
end-hosts served by those legacy bridges be connected to this hub. Repeat
this procedure until all legacy bridges are replaced. Then finally put the
RBridges back.). Now, one and only one RBridge forwards and receives
unencapsulated packets from each hub (through designated RBridge). Thus for
a loop formation, a packet must loop back to a designated RBridge, which is
not possible since RBridges use their own spanning tree for sending
(encapsulated) broadcast traffic.

Hope this helps.

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Tim Shepard
> Sent: Thursday, December 15, 2005 6:42 PM
> To: Developing a hybrid router/bridge.
> Cc: Radia.Perlman at Sun.COM; 'Joe Touch'
> Subject: Re: [rbridge] it's time to summarize things
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

---

From: shep at alum.mit.edu (Tim Shepard)
Date: Thu, 15 Dec 2005 20:12:40 -0500

> Hope this helps.

Yes, that helps.  Thanks.   I should have looked in the draft.

			-Tim Shepard
			 shep at alum.mit.edu

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Fri, 16 Dec 2005 08:50:18 +0200 (EET)

That's one darned big and convoluted summary.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 16 Dec 2005 10:35:17 +0100

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Gray, Eric wrote:
>  
>
>>Joe,
>>
My understanding was that Rbridges would do ARP proxying and would 
forward ARP requests to other Rbridges. Am I still right?.

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDob2UE5f5cImnZrsRAsUaAJ44nwX7pA7yBDIGpwXKPtkcZA0kaACeNyeg
>hco5aPY+Wji9vTw8f94UCnU=
>=nqbN
>-----END PGP SIGNATURE-----

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 16 Dec 2005 12:39:49 +0100

Saikat Ray wrote:

>unencapsulated packets from each hub (through designated RBridge).
>
But what happens when two separate hubs with separate RBridges 
forwarding each one traffic are connected
by a link restoration between them?. A single "hub" will be created with 
two Designated RBridges till the
detect the situation. How (and how fast), the DR election mechanims 
should work in this situation?
Guillermo

 Thus for

>>>directly, and all RBridges block BPDUs. Then the RBridge looks like,
>>>      
>>>
>>from
>>    
>>
>>>the perspective of the legacy brige, either (i) a single end-host (with
>>>      
>>>
>>the
>>    
>>
>>>"segment"?) with potentially a lot of MAC addresses attached to it (in
>>>      
>>>
>>fact,
>>[....]
>>    
>>

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 07:08:30 -0800

>> forward ARP requests to other Rbridges. Am I still right?.

Not proxying; they forward ARPs like all other L2 traffic. They don't
generate ARPs directed at their own L2 addresses in response to seeing
other ARPs (proxying).

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051216/efa3e042/signature.bin

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 16 Dec 2005 16:16:39 +0100

ARP Proxying by the Designated Rbridge was considered an acceptable 
optimization,  right?
GI
Joe Touch wrote:

>------------------------------------------------------------------------
>

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Fri, 16 Dec 2005 10:31:30 -0500 (EST)

> should work in this situation?

This was discussed long before. The frequency of RBridge hello messages
will determine the length of transience (once a hello is sent, the
presence of two RBridges on the same "hub" will be detected). Radia had
some comments about the numerical value of the frequency, which I do not
remember; it is in one of the emails on the list :)

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 07:58:29 -0800

There are two ARP issues to be considered:

Proxy ARP, no - i.e., there should be no point at which an rbridge
preemptively replies to an incoming ARP with an ARP reply with its own
MAC address. Rbridge MAC addresses should never appear in external node
(host/router) ARP tables.

The optimization we discussed is based on snooping and reply via replay,
which could be called ARP Replay, i.e., to emit the ARP that the rbridge
thinks will be emitted from the ultimate destination, rather than to
broadcast the ARP throughout in search of that host. There are issues
with that procedure - notably, when nodes silently renumber, where that
replayed reply could be in error, which need to be considered, but
that's a later discussion.

I'm not aware ARP Replay being called Proxy ARP - is anyone else? Is
there a better name than ARP Replay?

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051216/304cfbe7/signature.bin

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 16 Dec 2005 13:04:06 -0800

I'm changing the subject line to make it easier, as least for me, to
find mail on specific issues.

I remember writing up alternatives for ARP/ND proxying and
sending the choices and pros and cons to the list, and I'm not sure there
was ever strong opinions voiced on any of them.
However, I am quite sure the WG did not rule
out ARP proxying.

I prefer ARP proxying, rather than treating ARP like any other L2 traffic.
We could make things a bit fancier, for instance,
a) further cutting down on
traffic by having an RBridge suppress an ARP request to a particular 
target if
it knows that another one has occurred recently (either because it
iniated it as ingress RBridge or because it forwarded the encapsulated ARP
query)
b) getting rid of stale ARP caches faster by sometimes (we'd have to decide
under what circumstances) sending the ARP query directly to the
assumed target's link, and making the target respond.

Joe...you seem to be definitively stating that the WG has ruled out 
ARP/ND proxy.
I may have missed some of the emails on the list (it's *really* hard
to keep up with the volume of traffic). Was this debated and concluded 
somehow?
Or were you just misremembering? Ruling proxy out is definitely a change 
from
the original intent, and changes such as this should not be done 
arbitrarily.

Radia

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 13:13:06 -0800

> Joe...you seem to be definitively stating that the WG has ruled out 

We need to be clear about the difference between ARP Proxy and ARP
Replay. Replay is closer to what we have always been talking about. We
never talked about proxying.

For proxying to work:

	1- a designated rbridge would intercept an ARP
 	and reply with its own MAC address

	2- the rbridge would need to know to which egress to forward
	the packet

	3- the egress would need to know the MAC on the destination LAN

steps 2 and 3 involve a new set of state in the rbridge campus that we
haven't talked about.

My impression is thus that we've been talking about replay more than
proxy. Correct me (anyone) if that's not accurate...

Joe

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 16 Dec 2005 13:19:05 -0800

>That's one darned big and convoluted summary.

Is that a way of saying you volunteer to do the next summary? :-)

Actually, there's enough volume of email at this point that it would be good
to have another summary. My preference would be to separate out
different technical issues and do separate summaries of each, rather than
a "summary of the state of the mailing list". Perhaps the issues at this 
point
are whether to participate in spanning tree (I strongly vote that RBridges
drop spanning tree messages, with the option to build a colocated 
bridge/RBridge,
but certainly not to have RBridges merge spanning trees), whether to do
proxy ARP/ND (I vote yes), and perhaps there are other issues I've missed.

Anyway...I think it's useful for anyone, at any point, to do a summary, so
if you have the energy, it would be much appreciated. In my view of
how a mortal can follow a mailing list without spending full time on the one
mailing list, is that once someone does a summary, all previous emails can
be ignored...anyone that doesn't think the summary is accurate can send
reply to the summary. And there would need to be some sort of sequence
number on email messages so we know which ones are
before and which after a summary, but I'm assuming the time stamp will 
be good enough.

Thanks,

Radia

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 13:29:21 -0800

> (encapsulated) broadcast traffic.

Here's a variant that maps to only existing technologies:

	- remove the rbridges (as Saikat said)
		this leaves some number of disconnected
		bridged ethernet segments

	- replace the entirety of each bridged ethernet segment
	with a single hub (again, as Saikat said)
		I'm not positive this is valid; it will
		be if you replace the segment with a bridge, though.
		I'm worried about doubly-connected hosts, etc.

	- replace the rbridge campus with a bridge
		FORCE that bridge to be the root of the spanning tree

*IF* there is at most one rbridge campus in a LAN *AND* that campus can
end up knowing it is root of all the edge spanning trees, there can't be
a loop.

The key are the IF and AND clauses.

The IF is effectively forced by the HELLO messages; all rbridge devices
will coalesce into a single campus. This means you can't use multiple
campuses to handle scalability in a LAN, however.

The AND is assumed; if there is any other device that tries the same
trick and makes the same assumption (whether another rbridge, or an
rbridge-like system that doesn't use rbridge messages), the assumption
will be invalid.

Joe

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 16 Dec 2005 13:37:26 -0800

Yes Joe, you are right. This was a confusion over the word. I have used
"ARP proxy" to mean someone replies to the request, whether it be with
the target's actual MAC address, or with one's own MAC address. So with
your definition ("proxy" means you reply with your own MAC address), 
then you
are right...we do not want RBridges to do ARP proxy. But we
do want them to do ARP replay.

I suspect I'm not the only one who uses "ARP proxy" in the more general way,
so we have to be careful not to confuse people when we say RBridges will
not do it.

But whatever we call things, I'm glad we aren't disagreeing about how 
the thing
works functionally.

Radia

Joe Touch wrote:

>iD8DBQFDoy3iE5f5cImnZrsRAt5qAKC9NMQuOkDFJuBg5uT8PQQBywFmhgCdEA2v
>IQMHjRlNxrTNAsFDK7jRkrc=
>=3qHZ

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 13:41:37 -0800

> so we have to be careful not to confuse people when we say RBridges will

Right - I checked online and most of the times Proxy ARP is used it
means what routers do, rather than replay. I didn't see any other uses,
so I'll add both definitions to the PAS doc.

> But whatever we call things, I'm glad we aren't disagreeing about how 

I'll put that in the list of things to update (issues list, but listed
as resolved).

Joe

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sat, 17 Dec 2005 09:42:06 +0100

I agree fully with Radia.
In the recently submitted Abridges draft I propose the use of a kind ARP 
servers/registrars that splits the addresses to be resolved via hashing 
of IP address. Each server is responsible for caching the set of IP 
addresses that satisfies the same hash(IP) result (a hash length of a 
few bits may be sufficient to distribute the load among several 
servers). This requires a previous registering of the IP address-MAC 
address  that is performed by the Rbridge (Agent Bridge of host) upon 
detection of a  packet originated by  host "new" to the Abridge. This 
mechanism may also be used to reduce ARP based attacks by tightly 
controlling registration.
 Guillermo

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sat, 17 Dec 2005 09:54:51 +0100

Joe,

> 	and reply with its own MAC address
This seems to be right for the term "proxying"

>steps 2 and 3 involve a new set of state in the rbridge campus that we
To provide some ideas on 2 and 3  you mention, in the Abridges draft  
recently submitted, determination
of destination host MAC address (ARP  resolution) and destination 
Rbridge (Abridge) are performed
simultaneously by the ARP/AB server (they were registered together by 
the host Agent Bridge).

>proxy. Correct me (anyone) if that's not accurate...
I do not know if "replay" is the best suited term, but I agree that 
proxying is not accurate.

Guillermo

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sat, 17 Dec 2005 10:09:54 +0100

Saikat, see below
Guillermo

>remember; it is in one of the emails on the list :)
Well, it seems then that we can have loops for all that time.  If
subsecond intervals are needed, Hello Time must be
lower than 1 second. I find this mechanism more costly than using RSTP,
(already used by the bridges in the hub) to detect the double DR
situation.  By using the Root bridge election mechanism of
RSTP (via colocated bridge), the process uses the standard RSTP BPDUs
and selects in a reliable form a unique Root bridge and DR, assuming the
default bridge priority of bridges for election is worse than the
default priority of Rbridges (this can be defined at will).  Although it
means a small dependency on the 802.1D standard, it seems more advisable
to rely in a standard mechanism to act in a consistent way than
duplicate the mechanism and ignore RSTP protocol to obtain full
independency.
Rbridges ignoring fully RSTP BPDUs means all that means for knowing
"link" and tree status are dropped, the risk for malfunction is
increased as  long as Rbridges ignore BPDU information as useless.
One difference is that if DR Hello messages are not received, or
messages from new bridges appear, Rbridges might use received RSTP BPDU
information to confirm the cause and motivation of messages, so
decisions more consistent with RSTP can be taken.
Perhaps the main argument is that Root bridge election stops inmediatly
the frame forwarding in link (hub) blocking the loop, while via DR, the
stopping is done by Rbridges election. That is not the case if spanning
tree remains active while two DRs coexist on the link reinjecting the
traffic in the link through the Rbridge campus. The process requires
full communication between Rbridges through the link while there is a
loop on it.  Root bridge election does not.
Guillermo

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Sat, 17 Dec 2005 08:11:17 -0600

Without discussing whether it's a good idea or not, the "decisions more 
consistent with RSTP" function seems more like a performance optimization 
that isn't required for correct operation. Could this be something we don't 
define, but vendors making real Rbridges just decide to do? Like sniffing 
multicast control packets?

Spencer

p.s. Before we generate a whole lot more text - is there a canonical 
capitialization of RBRIDGE? I'm seeing all-caps, initial caps, and no caps 
in my own e-mail (which is usually matching the capitalization in e-mail I'm 
replying to), and it would be nice if (for example) all the TRILL documents 
used the same convention...

----- Original Message ----- 
From: "Guillermo Ib??ez" <gibanez at it.uc3m.es>
To: "Saikat Ray" <saikat at seas.upenn.edu>; "Developing a hybrid 
router/bridge." <rbridge at postel.org>
Sent: Saturday, December 17, 2005 3:09 AM
Subject: Re: [rbridge] it's time to summarize things

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Sat, 17 Dec 2005 10:53:09 -0500 (EST)

This was also discussed :) I raised precisely the same issues. Please see

http://www.postel.org/pipermail/rbridge/2005-October/000687.html

Radia had sent a reply, which I couldn't find in the list. Anyway, it is
sufficient that RBridges see the BPDU's to stop packet forwarding when a
legacy spanning tree starts to change, they do not need to be a part of
the spanning tree for this purpose. But I agree that merging the spanning
tree root bridge selection process with DR selection seems to be a nice
idea.

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sun, 18 Dec 2005 20:49:46 +0100

I was not aware of this mail. I am glad to know you see it in the same 
way.  I see it more than an optimization, a way  to make consistent 
operation, although very loosely coupled, between RSTP and  RBridges IS-IS.
Guillermo