Subject: [rbridge] VLAN and learning questions

From: jzeng at fabric7.com (Jianlin Zeng)
Date: Fri, 17 Feb 2006 14:21:01 -0800

Hi,

I've studied the document draft-perlman-trill-rbridge-protocol-00.txt
and have the following questions/suggestions:

1.	Should the VLAN tag be carried on the outer header only? Legacy
bridges needs the VLAN tag from outer header if the frame is not
received from the default VLAN of the ingress port. RBridge can always
derive VLAN of the received frame based on VLAN tag in the outer header
or default port VLAN if the tag is not there.
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20060217/4abcbd32/attachment.html

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Fri, 17 Feb 2006 15:12:07 -0800

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

>       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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sat, 18 Feb 2006 13:26:38 +0100

Regarding 2, this is also called dual-MAC learning, as used in Global 
Open Ethernet and others. I agree it is an efficient mechanism although 
for big networks the ARP broadcast may not be acceptable.
Regards
Guillermo
Jianlin Zeng wrote:

> Hi,
>
> I?ve studied the document draft-perlman-trill-rbridge-protocol-00.txt 
>       received from the default VLAN of the ingress port. RBridge can
>       always derive VLAN of the received frame based on VLAN tag in
>       the outer header or default port VLAN if the tag is not there.
>       having designated RBridges to query/learn end node information
>       and broadcast to every RBridges consume too much bandwidth and

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