Subject: [rbridge] Abridged history of the RBridge header

From: Kris Price <[email-masked]>
Date: Wed, 11 Mar 2009 17:25:34 +1300

Hi,

Since the last time I bothered the mailing list with questions about 
MPLS I found the relevant period where the header changed shape. And 
FWIW I compiled the following abridged history.

(Only late 2007 onwards to go in my reading of the mailing list now. 
<plod> <plod> ...)

*An abridged history of the RBridge header*

Note: Names and references have been excluded to prevent anyone being 
unwillingly associated with my interpretation of events. Naturally I 
have no visibility of meetings or private discussions. The details can 
be found by reading the TRILL mailing list archive of the period from 
October to December, 2006.

TRILL initially looked to use MPLS based encapsulation for RBridges, as 
described in draft-bryant-perlman-trill-pwe-encap-00. The approach 
created a global MPLS labelspace from which RBridges selected their 
nicknames. The MPLS header would only include egress RBridge, CoS, and 
TTL information. An RBridge would make additional forwarding decisions, 
for example to constrain delivery of a VLAN tagged frame to only those 
links on which that VLAN is active, by using the information in the 
encapsulated MAC header. This was a deviation from the general 
architecture of MPLS that such forwarding decisions are made at the edge 
by selecting the correct label switch path. The responsibility falling 
to the control-plane to set up the necessary label switched paths 
accordingly. Hence the amount of hardware re-use at the time may have 
been limited depending on whether this filtering became a strict 
requirement or an option that could be phased in as new hardware was 
developed. Because this type of filtering has unrelated benefits it may 
well find its way into many platforms anyway, and today some platforms 
may already have some of this capability for that reason.

A potential requirement for the inclusion of ingress RBridge information 
within the header was raised on the mailing list in October 2006. It was 
based on the need to possibly support 802.1au Congestion Notification, 
in which notifications must be returned to the end-station that sent the 
triggering frame. To do this, it was argued that an RBridge trying to 
send such a notification would need to know the ingress RBridge. It was 
suggested that the ingress RBridge could be identified by looking at the 
source MAC address in the encapsulated MAC header. One group felt it was 
inappropriate for a core RBridge to maintain all of the MAC reachability 
information, as would be required in order to do this lookup. Another 
group felt this was reasonable, as that is what core IEEE bridges to 
today. In the case where all of the MAC reachability information was not 
maintained, the approach of sending the notification over the 
multi-destination delivery tree (since it is then effectively an unknown 
destination frame) was rejected as having negative impacts.

Other fields were also proposed for inclusion in the header at this 
time, as described in draft-gai-perlman-trill-encap-00, but these were 
eventually ruled out, or incorporated in other ways. The resulting 
approach that was settled on was to include ingress and egress RBridge 
information. This was seen as more natural and flexible to future 
requirements. The option of continuing to use MPLS based encapsulation 
was raised, using a label stack, with the top label as per the original 
proposal, and the bottom label identifying the ingress RBridge. This 
appears to have received very little attention. I can only speculate 
that it was rejected out of a belief that MPLS based encapsulation 
brought little benefit, in which case a simplified 6-byte header versus 
an 8-byte header was more elegant.

The use of the encapsulation defined for 802.1ah Provider Backbone 
Bridges was raised at the IETF-67 meeting in November, 2006. At the time 
802.1ah was on its way to becoming a standard, and the question was 
whether there were any synergies between it and RBridges that could be 
capitalised on. Subsequent discussions on the mailing list ultimately 
rejected the idea for a few reasons. There was a feeling that 802.1ah 
was targeted at the provider market and so unsuitable for the enterprise 
and data centre market, although it is unclear why this made it 
unsuitable. There was a larger concern that 802.1ah would require a 
partial move away from zero configuration, although this was never 
clearly detailed. The clearest arguments against the use of 802.1ah were 
the lack of a TTL in the header, and the lack of a next-hop address. It 
was suggested that a TTL could be accommodated in the header before the 
standard was finalised, but the lack of a next-hop address was 
unresolved. RBridges uses the outer MAC encapsulation to define the 
next-hop on each link, this allows load balancing to multiple next-hop 
RBridges across a shared link. It is unclear whether the benefits of 
this versus the benefits of a shared encapsulation were weighed.

When 802.1ah based encapsulation was proposed it was noted that by using 
a non-IEEE frame format TRILL would be assuming responsibility for 
implementing all of the features developed by IEEE.

Subsequent to this the header acquired the options field to permit 
extensions, and it has resulted in the TRILL header seen today.

The end.

Regards

Kris
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge