[rbridge] TRILL Header Format

[Joe Touch]

Comments below...

Eastlake III Donald-LDE008 wrote:
> Hi Joe,
> 
> First I want to refine an earlier statement of mine. The VLAN ID
> information isn't involved in all forwarding decisions by Rbridges. But
> it is involved in all multi-destination forwarding decisions by Rbridges
> and for unicast it is involved in all ingress and egress processing. The
> priority information, which is also in the VLAN tag information, is
> relevant to queuing at every transit Rbridge.
> 
> See below at @@@ 
> 
> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU] 
> Sent: Wednesday, May 02, 2007 11:00 AM
> To: Eastlake III Donald-LDE008
> Cc: Rbridge at postel.org
> Subject: Re: [rbridge] TRILL Header Format
> 
> Eastlake III Donald-LDE008 wrote:
>> Hi Joe,
>>
>> I don't see any reason to assume any bridges are involved. 
> 
> Agreed. All functions that rbridges do that are identical to what
> bridges do should be stated as an assumption (rbridges can subsume all
> bridge functions except the rest of our discussion.
> 
> My point is that if a bridge (in an rbridge or not) adds a VLAN tag,
> then a bridge (in an rbridge or not) nearest the destination host will
> remove that tag. Even when the tag-adding bridge is the ingress rbridge,
> we cannot assume in our architecture that the tag-removing bridge is the
> egress rbridge; it could as easily be a bridge later in the arch.
> 
> @@@ When you say "a bridge (in an rbridge or not)" you seem to imply
> that there is a bridge inside every rbridge.

There can be; there need not be. More specifically, conventional bridge
functions such as VLAN tagging could be supported inside an rbridge.

> That doesn't make any sense
> to me. There isn't a bridge "inside" an Rbridge. The Rbridge is an
> integrated device that is a bridge (Rbridge stands for "Routing
> Bridge"). It is a better bridge.

That would presume we subsumed the entirety of what bridges do; we have
to date focused on what has changed.

> It uses IS-IS instead of *STP. It uses
> different formats on the wire between Rbridges. It may or may not have
> various optimizations. It's not an 802.1 bridge but it is a bridge
> nevertheless.

Then there could be 802.1 bridge functions additionally supported.

> And once a frame is ingressed by an Rbridge and has a
> TRILL Header added, every bit after the TRILL Ethertype through to just
> before the FCS is completely private to TRILL capable devices and TRILL
> capable software.

I disagree; TRILL devices are not encryption tunneling devices. As such,
the innermost header may be utilized at any rbridge, though one would
hope neither the innermost header nor the TRILL header would be used by
non-rbridge devices.

> Nothing TRILL ignorant will be able to parse past the
> TRILL Ethertype. It seems only reasonable to format that information for
> Rbridge convenience and efficiency.

It does, but it isn't required that information inside that header be
copied; that is neither efficient nor necessarily more convenient.

> To the extent that rbridges do this function (adding VLAN tags or
> removing them), that happens to the inner header. That function has
> nothing to do with rbridges per se; it doesn't belong in the rbridge
> header. If rbridge functions need to refer to that tag, they know where
> it would be and how to find it.

If an rbridge adds VLAN tags, it can do so in two places - the innermost
header or the outermost header; the innermost header would represent
'conventional' VLAN tagging, and the outermost would represent VLAN tags
used for intra-campus traversal.

If an rbridge supports conventional VLAN tagging (i.e., conventional
bridge capability), then the egress would NOT be the place to remove
that tag, so it would make no sense to have that tag anywhere other than
the innermost header.

> @@@ Rbridges are bridges. Your artificially carving out of the VLAN
> functionality, part of the heart of how Rbridges work, and declaring it
> to have nothing to do with Rbridges makes no sense at all.

I disagree, as above. It is orthogonal to rbridge functionality.

> @@@ The best view of VLAN ID, the multi-destination bit, frame priority,
> the "egress Rbridge", ... is that these are all pieces of
> meta-information that are not part of the actual data frame. They exist
> even when they are never encoded into a wire format.

Agreed, except for VLAN ID; that could be removed elsewhere, e.g.,
outside the campus, and as such has no business being in the TRILL header.

Keep in mind that rbridges may be a superset of bridges, but I don't
assume they replace all bridges everywhere. If there are bridges after
the egress, the VLAN tag would need to stay in place.

> @@@ In the future situation we are aiming for, the normal case will be
> that this meta-information will by synthesized when an Rbridge receives
> a native frame. It would never be wire encoded if the frame is between
> two end stations both directly connected to that Rbridge.

Agreed. But that again presumes a world where there are no bridges in a
campus - either used for rbridge-rbridge or rbridge-endstation. I don't
agree that's to be assumed.

> If the frame
> has to be forwarded to another Rbridge, then the meta-information does
> have to be wire encoded but such inter-Rbridge frames always have a
> TRILL Header which is the obvious place for all this meta-information
> all of which will be of interest to the receiving RBridge.
> 
>> What happens when such a message is received by a transit Rbridge?
> There
>> might be an outer 802.1AE tag or the like, which is removed and
>> processed at the port. There might be an outer VLAN tag which is
>> logically removed on receipt so frame now logically and perhaps
>> physically starts with a TRILL Ethertype. The Rbridge MUST then derive
>> inner VLAN tag information to decide how to forward the frame. With
>> Solution 2, it is at a fixed offset from the TRILL Ethertype and close
>> to the beginning of the frame, to speed cut through switching. With
>> Solution 1, the Rbridge has to skip over a variable amount of
> extension
>> data and extract the VLAN tag information from deeper in the frame at
> a
>> variable offset from the TRILL Ethertype.
> 
> This argument would imply that if the rbridge were not there that a
> bridge would need to extract the VLAN tag from the inner header at a
> variable offset. Since that's already done, I see no problem.
>
> @@@ I don't understand your comment above at all. Sure, if your replace
> all your Rbridges with 802.1Q bridges, then you have an 802.1Q bridge
> synthesizing a more limited set of meta-information. And if you have
> inter-802.1Q-bridge forwarding, then that meta-information is
> wire-encoded in the 802.1Q format of a Ethertype followed by the two
> bytes of Q/S-tag information. If you have Rbridges, then there is a
> larger set of meta-information and if you have an inter-Rbridge
> forwarding, then this larger set of meta-information is wire-encoded and
> that wire-encoding is whatever we say it is. This encoding will only be
> parsed by TRILL capable devices. It just makes no sense to me that, in
> the Rbridge case, you want to split this meta-information into two
> parts, throw away two bytes on an extra Ethertype, move the information
> which corresponds to that in a Q/S tag at least 14 bytes deeper into the
> frame to slow down cut through switching, and, in almost all cases,
> modify the frame being encapsulated by inserting this part of the meta
> information inside it.

The reason, as above, to repeat, is that I don't assume all bridges or
all rbridges; I believe a mixed deployment is not only likely in
transition, but should be supported regardless.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

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