[rbridge] Proposed changes to the architecture based on IETF-70...

[Eric Gray]

Folks,

Several people pointed out that the architecture should not assume a
DRB election process will be used.  This is technically correct, and
- for that reason - not directly something that needs consensus to
change, at least in theory.

Before going into specific proposed changes, I would like to mention
(in passing) why this is not a trivial change - as I explicitly said
during the meeting.  In fact, the reason why use of DRB election is
assumed in the protocol specification are manifold and - by not making 
the same assumption in the architecture - we task the architecture 
with the onus of expressly stating the reasons why any protocol 
specification will almost certainly need to use a DRB election.  This
is quite arguably an appropriate task for the architecture document,
which does nothing to make it easy.

Interestingly enough, most people did not see this as all that hard
to do.  One or two people even offered to help.  Below is what we've 
come up with.  Given the shortage of time, my default assumption is
that these changes should be incorporated in a version to be posted
by the dead-line next Monday.
______________________________________________________________________

At a high level, any solution needs not only to deal with ingress and
egress of frames traversing the RBridge Campus in the normal case, it
must aslo deal with the folowing exception cases:

o	receiving a frame from an end station previousy not heard from,
o	flooding frames for unknown destinations,
o	broadcast of frames to reach all possible end stations - known
	or unknown.

In short it is not simply a matter of determining which RBridge it is
that forwards frames in each specific case, it is also a matter of
determining which RBridge learns and floods in each specific case -
where one has to recognize that it is not always going to be the case
that RBridges have a priori knowledge required to make a determination
in some arbitrary and as yet undefined determination process.

Also, the method of selecting which RBridge is responsible for all of
the above cannot be completely arbitrary.  As it turns out, in order 
to maintain compatibility with 802.1Q (or 802.1D) bridges, RBridges
must handle ingress onto and egress off of the RBridge Campus in a
way that is consistent within a consistent forwarding context used by
any local bridges that may be present.

And - of course - there is always the consideration of which RBridge
sends routing
advertisements._________________________________________________________
_____________

Anyway, on to the specific issues and proposed changes...
----------------------------------------------------------------------
So, here are the issues, and my proposed changes to account for them.
______________________________________________________________________

First, there is the definition of Designated RBridge.  The definition 
needs to remain, but it must be changed to reflect the fact that this 
is merely one way to handle the issue(s) addressed using a DRB.

I propose a replacement definition as follows:

"Designated RBridge (DRB): one approach to resolving several issues 
 associated with having multiple RBridges as candidate ingress and
 egress points from a single LAN is to designate an RBridge to act 
 as the ingress and egress in that case.  The RBridge designated
 to handle ingress and egress traffic to a specific Ethernet link 
 (or VLAN associated with that link), having shared access and 
 multiple RBridges is such a link's "Designated RBridge", or DRB. A 
 Designated RBridge may (for example) be determined by an election 
 process among those RBridges having shared access via a single LAN,
 or may be selected by some other means."
______________________________________________________________________

Also, the definition of Encapsulation Database contains a (what is - 
in retrospect - probably innappropriate) use of Designated RBridge. 

I propose a litteral replacement of - 

	"Designated RBridge (ingress)" 

- with - 

	"Ingress RBridge"
______________________________________________________________________

Section 4.1 has two problem areas.  In the second paragraph, the use
of DRB as the the primary point of attachment for an end station is
assumed.  I propose modification as follows:

"At an architectural level, it is sufficient to note that every end 
 station attached to a TRILL Campus should have a primary point of
 attachment to the TRILL Campus, as might be defined (for example)
 by a Designated RBridge. Furthermore, if it is possible that there
 are 802.1Q (or 802.1D) bridges in a local LAN, the association of 
 specific RBridges and the end stations to which they act as primary
 point of attachment must be determined in a way that is consistent
 with forwarding in an 802.1Q (or 802.1D) network.  If a DRB election 
 process were used, each TRILL Link (or VLAN group within a TRILL 
 Link) attached to a TRILL Campus would have a single Designated 
 RBridge (either for the link, or for a subset of the VLANs on the 
 link); using DRBs as an example, the DRB would be where all traffic 
 intended to transit a TRILL Campus enters and exits.

"Other approaches might be used as well.  For example, the primary 
 point of attachment for each end-station might be configured, or 
 determined in some other way, on a per end station basis.  Any
 such approach must either allow for the possibility of LAN bridges
 or not be used when such a possibility exists."

The last paragraph in section 4.1 ("TRILL Campus Auto-configuration")
specifically includes DRB election.  I propose a small modification 
to read as follows:

"High-level steps that may be included in auto-configuration are: 
 RBridge peer discovery, topology discovery, determination of end 
 station primary points of attachment (DRB election, for example), 
 learning and forwarding (tunneling) TRILL encapsulated frames."
______________________________________________________________________

Section 4.4 needs to be re-written (and re-titled). I propose:

"4.4. Determination of End Station Primary Points of Attachment

"The mechanisms and details of how end stations are associated with
 a specific Rbridge - when multiple RBridges are available - for the
 purpose of providing ingress to and egress from the RBridge Campus,
 will be provided by protocol specification(s). A potential approach
 to be considered is the use of a 'Designated RBridge Election', on
 either a per link, or per VLAN (set) basis.

"Architecturally, it is important to note that this determination 
 must be based on an accurate view of the topology, including the
 availability of certain links in a given topology for traffic 
 associated with any given VLAN.  Otherwise, it is possible to 
 partition a TRILL Link-local LAN (assuming that RBridge may be 
 deployed and configured to replace existing 802.1Q bridges) as a 
 result of a failure - under circumstance in which such a partition 
 would not have occurred with previously deployed 802.1Q bridges.

"Protocol specification(s) need to define how accurate VLAN topology 
 is to be determined and applied in determination of end station 
 primary points of attachment. Protocol specification(s) also need 
 to state the limitations that any chosen mechanisms may impose on 
 the solution (in terms of scalability and ease of deployment, for 
 example). Finally protocol specification(s) need to describe how
 determination is made with respect to which RBridge is responsible
 for learning new end station information, and for the flooding and 
 broadcast frames for reaching known and unknown end stations on any
 link or VLAN."
______________________________________________________________________

Section 5.1 use the expression "Designated RBridge Election" in the
first paragraph.  I propose to replace the first paragraph with:

"As described in sections above, operations that apply to all 
 RBridges include peer and topology discovery (including hello 
 messaging, negotiation of RBridge identifiers and link-state 
 routing), determination of RBridge primary point of attachment
 (for local end stations - possibly via DRB election), shortest 
 path (SPF) computation and either learning or advertising L2 
 MAC Ethernet destination reach-ability for addresses within a 
 broadcast domain."
______________________________________________________________________

Section 5.2 is intended to describe architectural considerations
that apply to ingress and egress operations.  These include how
learning is expected to occur, and how forwarding onto and off of
the RBridge Campus occurs.  As such, the section is closely tied
in with the presumption of using a DRB (as elected or otherwise
determined).  One solution to this issue would have been to make
the term DRB - in this document - apply effectively on a per end
station basis (however complicated this might seem, it is what we
must consider to be the minimalist architectural requirement). 

In order to avoid confusing use of the term DRB, however, I would 
rather not use that approach (and have not done so in my proposed 
changes thus far).  Instead, I propose changing several of the
paragraphs of section 5.2 to read as follows:
______________________________________________________________________

"5.2.Ingress/Egress Operations

"Operation specific to edge RBridges involves RBridge learning, 
 advertisement, encapsulation and decapsulation (at ingress and
 egress RBridges, respectively).

"As described previously, RBridge learning is similar to typical 
 bridge learning - i.e. - RBridges listen promiscuously to L2 
 Frames on each local LAN and acquire end station location 
 information associated with source MAC addresses in L2 frames 
 they observe.

"If multiple RBridges are available, a determination must be made
 as to which RBridge is the primary point of attachment for each
 end station (or end stations by groups - using, for example, the
 VLAN associations of VLAN aware end stations) requiring ingress 
 and egress services from an RBridge campus.  This is a minimal 
 requirement, and there is no reason why this same determination 
 might not be made in all cases, even including a degenerate case 
 in which only one RBridge may be used.  This would be the case, 
 for instance, if DRB election is done in all case, including when 
 the DRB can only be the one and only RBridge to which local end 
 stations might be attached.  

"In the degenerate case - where only one RBridge is connected to a 
 specific Ethernet LAN - obviously that RBridge will be (or become)
 the primary point of attachment for local end stations requiring
 ingress/egress services from the RBridge Campus.

"Minimally, only the RBridge determined as the primary point of 
 attachment for a given (set of) end station(s) is required to
 performs RBridge learning for that (set of) end station(s) while 
 they remain associated with interface(s) connected to the local 
 LAN or VLAN.

"Note that - in some cases - the determination of primary points
 of attachment and learning may be tightly bound operations.  This 
 might be the case if - for example - the determination is based 
 on litteral configuration of end station and RBridge attachments.
 In other cases, learning would occur in a more conventional - and
 flexible way - if (for example) an automated process of selecting 
 a DRB (such as DRB election) is used on  a per link or per VLAN 
 (set) basis.

"Assuming learning is required by a specific solution described in
 any protocol specification(s), as RBridges learn segment-local MAC 
 source addresses, ..."

 - and further on -

"... to limit the scope of advertisement flooding.

"If it is desired - in any specific solution - to support discovery
 of new end station attachments, RBridges may also discover that a
 new end station has become locally attached (for which they may be
 or become an edge RBridge) as a result of receiving un-encapsulated 
 frames that require forwarding.  Any such solution must specify how
 a primary end station point of attachment is determined when this
 occurs.  Several possible approaches exist.  

"If an automated DRB selection process (such as DRB election) is the 
 approach in use for a specific solution (on a per link or per VLAN 
 basis), this determination is automatic for any specific link or 
 VLAN on a local link. If an RBridge is the Designated RBridge for a 
 local link or VLAN, and has not previously learned that the MAC 
 destination for a frame is local (this could be the case for the 
 very first frame an RBridge observes), then the RBridge could be 
 required to forward (or flood) the frame  via the TRILL Campus to 
 all other RBridges (potentially within a VLAN scope). 

"Protocol specifications intended to support recognition of new end
 station attachments must specify how the determination of a primary 
 point of attachment is to be accomplished for newly discovered end
 stations.

"When a frame is received which must be forwarded across the RBridge
 Campus, the responsible RBridge would flood the frame unless it has 
 already created a Unicast TRILL Forwarding Database entry for the 
 frame's MAC destination address.  If it has a corresponding Unicast 
 TRILL Forwarding Database entry, then it would use that.  The 
 RBridge in this instance would be an ingress RBridge for the frame 
 being forwarded across the RBridge Campus.

"The encapsulation used by this ingress RBridge would be determined 
 by the Unicast TRILL Forwarding Database - if one exists - or the 
 Unicast TRILL Forwarding Database-equivalent entry for the RBridge 
 Distribution Tree.

"When the encapsulated frame arrives at egress RBridge(s), it is 
 decapsulated and forwarded via the egress interface(s) onto the 
 local link (or VLAN on the local link).

"In using the approach of learning from the data plane, the egress 
 RBridge stores information related to content of the frame's TRILL
 encapsulation for use in subsequent reverse traffic in a manner
 directly analogous to bridge learning.

"Note that an egress RBridge will - in most cases - be the RBridge 
 determined to be the primary point of attachment for a destination 
 end station on the local LAN or VLAN accessed via its egress 
 interface(s).  Exceptions to this might exist under circumstances
 in which use of distinct RBridges for ingress and egress for a
 common (set of) end station(s) does not produce local forwarding
 ambiguity.  Any protocol specification that allows this must also
 unambiuously describe the precise circumstances under which it is
 allowed - as well as the limitations and issues this introduces
 in the solution specified.

"Also note that any specific solution in protocol specification(s) 
 will need to document how determination of an end station primary 
 point of attachment (RBridge) occurs for the case where a specific 
 end station has not yet been discovered at any egress or egress 
 interface - except under circumstances where support of discovery 
 of new end stations is not supported, or explicitly disallowed.  
 In the example in which a DRB election is used, this determination 
 should be both trivial and automatic. In an approach where an end 
 station and RBridge attachment/association is configured, this
 should also be relatively obvious - if inflexible.

"For the DRB example, if the destination MAC of a received frame 
 does not correspond to a learned MAC destination address at a
 specific egress interface, the DRB will forward the frame on all 
 interfaces for which it is the designated RBridge.  If a received 
 frame does correspond to a learned MAC destination address at some 
 specific egress interface, the DRB will forward the frame via that 
 interface only.

"Any specific solution's protocol specification should also allow 
 for the fact that flooded frames may arrive at a single local LAN
 (or VLAN) where local end stations may be attached via multiple
 RBridges, and properly account for how the determination of which
 RBridge is exclusively responsible for forwarding such frames is 
 to be made.  This is essential to avoid having the same frame being 
 delivered at local bridge interfaces multiple times and potentially 
 from widely disparate directions (i.e. - on different interfaces of
 individual bridges)."
______________________________________________________________________

Section 5.3.2.1 ("Broadcast" - under 5.3.2 "Broadcast, Multicast and 
Flooding", under 5.3 "Transit Forwarding Operations"), since all 
broadcast traffic is explicitly intended to reach every attached end
station (known or unknown), contains a few peripheral ties to the
use of DRB.  In a way that is very similar to proposed replacement
text in section 5.2, using any approach other than DRB has some very
extreme complications associated with it for the broadcast case (the
unkown case is already identified and addressed explicitly in the
proposed replacement text above). I propose the following change:

Replace the fourth, fifth and sixth paragraphs with the following 4 
paragraphs -

"Note that an interface over which an RBridge may egress frames is 
 any interface for which the RBridge is the primary point of end
 station attachment for one or more end stations, or the RBridge
 determined to be responsible for broadcast delivery. 
 
"RBridges must not wait to determine that one (or more) Ethernet 
 end stations are present on an interface before deciding to forward
 decapsulated broadcast frames on that interface.  An exception case
 would exist if RBridges have been configured to treat a local link
 as a point to point connection between two RBridges, or otherwise
 configured to ignore the possible presence of end stations in this 
 case.

"Forwarding information is selected for each broadcast frame received
 by any RBridge (based - for example - on identifying the ingress 
 RBridge for the frame) for all corresponding Multi-destination TRILL
 Forwarding Database entries. Each RBridge may thus be required to
 replicate one RBridge encapsulated broadcast frame for each interface
 that is determined from Multi-destination TRILL Forwarding Database
 entries corresponding to the frame's ingress RBridge. This includes
 decapsulated broadcast frames for each interface for which the 
 RBridge is responsible for egressing broadcast frames (as might have
 been determined previously by DRB election, for example).

"Note that frame replication and forwarding should be scoped by VLAN
 if VLAN support is provided. Also note that an egress RBridge may 
 be required to transmit a decapsulated frame on the same interface
 on which it received the RBridge encapsulated frame."
______________________________________________________________________

And, of course, after making these changes, update the TOC...

--
Eric Gray
Principal Engineer
Ericsson