Subject: [rbridge] Endnode learning from data packets vs from link stateinformation

From: jzeng at fabric7.com (Jianlin Zeng)
Date: Fri, 17 Feb 2006 16:59:06 -0800

Hi Radia,

Thanks for the answer. As you pointed out, it's a tradeoff to pick which
direction and go with it. 

The biggest advantages of RBridge as you described in the draft is
shortest paths forwarding with TTL vs STP. This along is already a huge
improvement over current layer 2 networks. If the draft can define a
base that can achieve this goal and is scalable and simple to implement,
it will be much easier to be adopted by current switch vendors. The
fancy features like ARP/ND proxy/mix link types etc can be defined as
optional add-on features to make RBridge even more attractive.

Jianlin

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Friday, February 17, 2006 3:12 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Endnode learning from data packets vs from link
stateinformation

Jianlin Zeng,

Both really good questions. I prefer (when I'm reading email threads)
to have only one technical topic in each thread, so I took the
liberty of changing the subject line and in this reply, only
asking about endnode learning.

It is an interesting variant, as you propose,
to not bother broadcasting endnode
information in link state information, and only figure it
out from encapsulated data packets. However,
for most data packets, only the "egress RBridge" is
in the shim header, not the "ingress RBridge".

As you point out though, if we have the source address
in the OUTER header be the ingress RBridge's MAC address, then
RBridges can do the mapping of ("ingress RBridge MAC address,
endnode MAC address"). Currently, the internet draft
specifies that in the outer header, the SA is the transmitting
RBridge, so the SA in the outer header would change
at each hop.
There are a couple of worries
I'd have about using original RBridge as the SA in the outer
header rather than the transmitting RBridge on that hop.

a) Might it confuse bridge learning if they see the MAC
address of the original RBridge coming from different directions?
Maybe this wouldn't be a problem because the destination
address in the outer header would always be one local to
that bridged link.

b) IS-IS uses a single 6-byte ID for the RBridge, whereas it
might have multiple MAC addresses. I suppose we could
add information into the LSP to indicate "variant MAC addresses",
since IS-IS would, without us adding that field, only tell
us how to reach the system ID of the destination RBridge.

c) I was thinking about potentially mixing link types at
some point in the future, and I think it would be
easier to do this if the outer header was link-specific,
so this would allow RBridge encapsulated
packets to traverse some mythical kind of link, with say,
4 byte addresses. If we were to do something like that,
we wouldn't be able to put in the original RBridge MAC
address into the SA of that type of header.

There might be more issues, but it would be interesting
to look at the tradeoffs. I'm not sure whether it's going to
be easy to definitely decide this, so this might
be one of those cases where we should just pick one
direction and run with it.

Radia

>    2. Regarding learning of end node information, would the action of
>       having designated RBridges to query/learn end node information
and
>       broadcast to every RBridges consume too much bandwidth and
>       processing power? This requires huge network and processing
>       resources as network gets bigger. For deployments that don't
>       require ARP/ND proxy, each RBridge can learn the (Designated
>       RBridge address, end node address) information directly from the
>       SA in the outer header and SA in the inner header. This doesn't
>       need extra broadcasting packets and can be implemented in the
>       hardware. An aging mechanism similar to legacy bridges can be
>       implemented by each RBridge to keep the end node information
>       database fresh enough.
> 
>  
> 
> Thanks,
> 
> Jianlin
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://www.postel.org/mailman/listinfo/rbridge