TRILL-Hello Contents and Timing

The TRILL-Hello has a new IS-IS message type. It starts with the same fixed header as an IS-IS LAN Hello, which includes the 7-bit priority for the issuing RBridge to be DRB on that link. Hellos are sent with the same timing as IS-IS LAN Hellos.

TRILL-Hello messages, including their Outer.MacDA and Outer.MacSA, but excluding any Outer.VLAN or other tags, MUST NOT exceed 1470 octets in length and SHOULD NOT be padded. The following information MUST appear in every TRILL-Hello. References to "TLV" may actually be a "sub-TLV" as specified in separate documents [RFC6165]

[RFC6326].

1. The VLAN ID of the Designated VLAN for the link.

2. A copy of the Outer.VLAN ID with which the Hello was tagged on sending.

3. A 16-bit port ID assigned by the sending RBridge to the port the TRILL-Hello is sent on such that no two ports of that RBridge have the same port ID.

4. A nickname of the sending RBridge.

5. Two flags as follows:

5.a. A flag that, if set, indicates that the sender has detected VLAN mapping on the link, within the past 2 of its Holding Times.

5.b. A flag that, if set, indicates that the sender believes it is appointed forwarder for the VLAN and port on which the Hello was sent.

The following information MAY appear:

1. The set of VLANs for which end-station service is enabled on the port.

2. Several flags as follows:

2.a. A flag that, if set, indicates that the sender’s port was configured as an access port.

2.b. A flag that, if set, indicates that the sender’s port was configured as a trunk port.

2.c. A bypass pseudonode flag, as described below in this section.

3. If the sender is the DRB, the Rbridges (excluding itself) that it appoints as forwarders for that link and the VLANs for which it appoints them. As described below, this TLV is designed so that not all the appointment information need be included in each Hello. Its absence means that appointed forwarders should continue as previously assigned.

4. The TRILL neighbor list. This is a new TLV, not the same as the IS-IS Neighbor TLV, in order to accommodate fragmentation and reporting MTU on the link (see Section 4.4.2.1).

The Appointed Forwarders TLV specifies a range of VLANs and, within that range, specifies which Rbridge, if any, other than the DRB, is appointed forwarder for the VLANs in that range [RFC6326].

Appointing an RBridge as forwarder on a port for a VLAN that is not enabled on that port has no effect.

It is anticipated that many links between RBridges will be point, in which case using a pseudonode merely adds to the

complexity. If the DRB specifies the bypass pseudonode bit in its TRILL-Hellos, the RBridges on the link just report their adjacencies as point-to-point. This has no effect on how LSPs are flooded on a link. It only affects what LSPs are generated.

For example, if RB1 and RB2 are the only RBridges on the link and RB1 is the DRB, then if RB1 creates a pseudonode that is used, there are 3 LSPs: for, say, RB1.25 (the pseudonode), RB1, and RB2, where RB1.25 reports connectivity to RB1 and RB2, and RB1 and RB2 each just say they are connected to RB1.25. Whereas if DRB RB1 sets the bypass pseudonode bit in its Hellos, then there will be only 2 LSPs: RB1 and RB2 each reporting connectivity to each other.

A DRB SHOULD set the bypass pseudonode bit for its links unless, for a particular link, it has seen at least two simultaneous adjacencies on the link at some point since it last rebooted.

4.4.2.1. TRILL Neighbor List

The new TRILL Neighbor TLV includes the following information for each neighbor it lists:

1. The neighbor’s MAC address.

2. MTU size to this neighbor as a 2-octet unsigned integer in units of 4-octet chunks. The value zero indicates that the MTU is untested.

3. A flag for "failed minimum MTU test".

To allow partial reporting of neighbors, the neighbor IDs MUST be sorted by ID. If a set of neighbors { X1, X2, X3, ... Xn } is reported in RB1’s Hello, then X1 < X2 < X3, ... < Xn. If RBridge RB2’s ID is between X1 and Xn, and does not appear in RB1’s Hello, then RB2 knows that RB1 has not heard RB2’s Hello.

Additionally there are two overall TRILL Neighbor List TLV flags:

"the smallest ID I reported in this Hello is the smallest ID of any neighbor", and "the largest ID I reported in this Hello is the largest ID of any neighbor". If all the neighbors fit in RB1’s TRILL-Hello, both flags will be set.

If RB1 reports { X1, ... Xn } in its Hello, with the "smallest" flag set, and RB2’s ID is smaller than X1, then RB2 knows that RB1 has not heard RB2’s Hello. Similarly, if RB2’s ID is larger than Xn and the "largest" flag is set, then RB2 knows that RB1 has not heard RB2’s Hello.

To ensure that any RBridge RB2 can definitively determine whether RB1 can hear RB2, RB1’s neighbor list MUST eventually cover every

possible range of IDs, that is, within a period that depends on RB1’s policy and not necessarily within any specific period such as the holding time. In other words, if X1 is the smallest ID reported in one of RB1’s neighbor lists, and the "smallest" flag is not set, then X1 MUST also appear as the largest ID reported in a different Hello neighbor list. Or, fragments may overlap, as long as there is no gap, such that some range, say, between Xi and Xj, never appears in any fragment.