[rbridge] Fwd: question on draft-ietf-trill-rbridge-protocol-16

[Donald Eastlake]

The following may be useful. Forwarded with permission and anonymized as
requested:

---------- Forwarded message ----------
From: Donald Eastlake <d3e3e3 at gmail.com>
Date: Sun, May 2, 2010 at 5:38 PM
Subject: Re: question on draft-ietf-trill-rbridge-protocol-16

Hi ...,

See below...

On Sun, May 2, 2010 at 12:05 PM, ... wrote:

> Hi,
>
> I'm a bit confused about a point in the draft regarding multiple ports
> attached to the same link.
>
> In the two sections below, it states:
>  "All such frames that are part of the same flow must be accepted on the
> same port to avoid re-ordering."
>
>    4.5.2 Multi-destination Frame Checks
>
>      Port Group Check: If an RBridge has multiple ports attached to the
>      same link, a multi-destination frame it is receiving will arrive
>      on all of them. All but one received copy of such a frame MUST be
>      discarded to avoid duplication. All such frames that are part of
>      the same flow must be accepted on the same port to avoid re-
>      ordering.
>
>
>    4.6.1.2 Native Multicast and Broadcast Frames
>
>         If the RBridge has multiple ports attached to the same link, all
> but
>         one received copy of a native multicast or broadcast frame is
>         discarded to avoid duplication. All such frames that are part of
> the
>         same flow must be accepted on the same port to avoid re-ordering.
>
>
> But given that for native multicast only one port of the port group is the
> Appointed VLAN-X Forwarder, and for multi-destination TRILL packets only one
> port of the port group will forward TRILL packets, so I don't see the need
> to be "flow aware" -- packets are just processed in the order the packets
> are received on the port.  Can you explain?
>

Although only a single port is DRB, the appointment of an Appointed
Forwarder on a link is by RBridge, not by port. If you look at the
appointment sub-TLV in draft-ietf-isis-layer2-05 you will see that it is
appointed by nickname. Thus, the particular RBridge that is Appointed
Forwarder for VLAN-X may have multiple ports attached to the link. In this
message I'll call an RBridge with multiple ports on a link a "multiport
RBridge". The easiest thing is just to, in effect, turn all but one of the
ports off, but if the link is actually some complex bridged LAN with lots of
end stations, it might help to spread different VLANs across the different
ports.

The multiport RBridge can, if it is appointed forwarder for more than one
VLAN, distribute those to different ports on the link or, in principle, it
could do even more complex stuff, like splitting the ingress/egress of
native frames in a particular VLAN between ports on the link based on
whether the end station MAC address is odd or even or in even more bizarre
ways.

As far as TRILL data frames go, appointed forwarder status is irrelevant and
any other RBridge on the link can choose to send unicast TRILL data frames
to any of the ports (that it has two way connectivity to as determined by
TRILL Hellos), so it is up to the sending RBridge that, if it wants a simple
strategy, could simply send such unicast TRILL data frames to the port with
the lowest MAC address or whatever. This is all local as, to the rest of the
campus, there just appears to be one adjacency between such an RBridge and
the multiport RBridge.

I guess that in theory special language might not be needed for multicast or
broadcast native frames as the multiport RBridge has to sort out which port
it is going in ingress/egress native frames on anyway, since none of the
native frames are normally addressed to the RBridge itself, but it seems
better to emphasize the point about flows. A TRILL data frame sent to
All-RBridges will arrive on all the ports and the multiport RBridge is
required to not duplicate it but it could, in principle, do something like
process different priorities of such multicast TRILL data frames on
different ports or other bizarre things. As long as it keeps the flows
straight. (GhostBusters quote: "Don't cross the flows...")

So, if they adopt simple strategies, you are right that such RBridges do not
necessarily need to be "flow aware". But if they are trying to be more
efficient by adopting complex strategies, the statements about flows in the
draft are the criterion for correct operation.

...

Thanks,
Donald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100503/40b3664b/attachment.html