RFC 7781
Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access
Pages: 35
Proposed Standard
Proposed Standard
Part 2 of 2 – Pages 19 to 35
6. TRILL Traffic Processing
This section provides more details of native frame and TRILL Data packet processing as it relates to the RBv's pseudo-nickname.6.1. Ingressing Native Frames
When RB1 receives a unicast native frame from one of its ports that has end-station service enabled, it processes the frame as described in Section 4.6.1.1 of [RFC6325], with the following exception: o If the port is an RBv port, RB1 uses the RBv's pseudo-nickname instead of one of its regular nickname(s) as the ingress nickname when doing TRILL encapsulation on the frame. When RB1 receives a native multi-destination (broadcast, unknown unicast, or multicast) frame from one of its access ports (including regular access ports and RBv ports), it processes the frame as described in Section 4.6.1.2 of [RFC6325], with the following exceptions: o If the incoming port is an RBv port, RB1 uses the RBv's pseudo-nickname instead of one of its regular nickname(s) as the ingress nickname when doing TRILL encapsulation on the frame.
o For the copies of the frame replicated locally to RBv ports, there
are two cases, as follows:
- If the outgoing port(s) is associated with the same
pseudo-nickname as that of the incoming port but not with the
same LAALP as the incoming port, the copies are forwarded out of
that outgoing port(s) after passing the Appointed Forwarder
check for the frame's VLAN. That is to say, the copies are
processed on such port(s), as discussed in Section 4.6.1.2 of
[RFC6325].
- Else, the Designated Forwarder (DF) check is also made on the
outgoing ports for the frame's VLAN after the Appointed
Forwarder check, and the copies are not output through any ports
that failed the DF check (i.e., RB1 is not the DF for the
frame's VLAN on the ports). Otherwise, the copies are forwarded
out of the outgoing ports that pass both the Appointed Forwarder
check and the DF check (see Section 5.2).
For any such frames received, the MAC address information learned by
observing it, together with the LAALP ID of the incoming port, SHOULD
be shared with other member RBridges in the group (see Section 7).
6.2. Egressing TRILL Data Packets
This section describes egress processing of the TRILL Data packets
received on an RBv member RBridge (say RBn). Section 6.2.1 describes
the egress processing of unicast TRILL Data packets, and
Section 6.2.2 specifies the egressing of multi-destination TRILL Data
packets.
6.2.1. Unicast TRILL Data Packets
When receiving a unicast TRILL Data packet, RBn checks the egress
nickname in the TRILL Header of the packet. If the egress nickname
is one of RBn's regular nicknames, the packet is processed as defined
in Section 4.6.2.4 of [RFC6325].
If the egress nickname is the pseudo-nickname of a local RBv, RBn is
responsible for learning the source MAC address, unless data-plane
learning has been disabled. The learned {Inner.MacSA, Data Label,
ingress nickname} triplet SHOULD be shared within the AAE group as
described in Section 7.
The packet is then decapsulated to its native form. The Inner.MacDA
and Data Label are looked up in RBn's local forwarding tables, and
one of the three following cases will occur. RBn uses the first case
that applies and ignores the remaining cases:
o If the destination end station identified by the Inner.MacDA and
Data Label is on a local link, the native frame is sent onto that
link with the VLAN from the Inner.VLAN or VLAN corresponding to
the Inner.Label if the packet is FGL.
o Else if RBn can reach the destination through another member
RBridge (say RBk), it tunnels the native frame to RBk by
re-encapsulating it into a unicast TRILL Data packet and sends it
to RBk. RBn uses RBk's regular nickname instead of the
pseudo-nickname as the egress nickname for the re-encapsulation,
and the ingress nickname remains unchanged (somewhat similar to
Section 2.4.2.1 of [RFC7780]). If the Hop Count value of the
packet is too small for it to reach RBk safely, RBn SHOULD
increase that value properly in doing the re-encapsulation.
(NOTE: When receiving that re-encapsulated TRILL Data packet, as
the egress nickname of the packet is RBk's regular nickname rather
than the pseudo-nickname of a local RBv, RBk will process it per
Section 4.6.2.4 of [RFC6325] and will not re-forward it to another
RBridge.)
o Else, RBn does not know how to reach the destination; it sends the
native frame out of all the local ports on which it is Appointed
Forwarder for the Inner.VLAN (or Appointed Forwarder for the VLAN
into which the Inner.Label maps on that port for an FGL TRILL Data
packet [RFC7172]).
6.2.2. Multi-Destination TRILL Data Packets
When RB1 receives a multi-destination TRILL Data Packet, it checks
and processes the packet as described in Section 4.6.2.5 of
[RFC6325], with the following exception:
o On each RBv port where RBn is the Appointed Forwarder for the
packet's Inner.VLAN (or for the VLAN to which the packet's
Inner.Label maps on that port if it is an FGL TRILL Data packet),
the DF check (see Section 5.2) and the ingress nickname filtering
check (see Section 5.3) are further performed. For such an RBv
port, if either the DF check or the filtering check fails, the
frame MUST NOT be egressed out of that port. Otherwise, it can be
egressed out of that port.
7. MAC Information Synchronization in Edge Group
An edge RBridge, say RB1 in LAALP1, may have learned a correspondence between a {Data Label and MAC address} and nickname for a remote host (say h1) when h1 sends a packet to CE1. The returning traffic from CE1 may go to another member RBridge of LAALP1 (for example, RB2). RB2 may not have that correspondence stored. Therefore, it has to do the flooding for unknown unicast. Such flooding is unnecessary, since the returning traffic is almost always expected and RB1 had learned the address correspondence. To avoid the unnecessary flooding, RB1 SHOULD share the correspondence with other RBridges of LAALP1. RB1 synchronizes the correspondence by using the MAC-Reachability (MAC-RI) sub-TLV [RFC6165] in its ESADI-LSPs [RFC7357]. On the other hand, RB2 has learned the MAC address and Data Label of CE1 when CE1 sends a frame to h1 through RB2. The returning traffic from h1 may go to RB1. RB1 may not have CE1's MAC address and Data Label stored even though it is in the same LAALP for CE1 as RB2. Therefore, it has to flood the traffic out of all its access ports where it is Appointed Forwarder for the VLAN (see Section 6.2.1) or the VLAN the FGL maps to on that port if the packet is FGL. Such flooding is unnecessary, since the returning traffic is almost always expected and RB2 had learned CE1's MAC and Data Label information. To avoid that unnecessary flooding, RB2 SHOULD share the MAC address and Data Label with other RBridges of LAALP1. RB2 synchronizes the MAC address and Data Label by enclosing the relative MAC-RI TLV within a pair of boundary TRILL APPsub-TLVs for LAALP1 (see Section 9.3) in its ESADI-LSP [RFC7357]. After receiving the enclosed MAC-RI TLVs, the member RBridges of LAALP1 (i.e., LAALP1 related RBridges) treat the MAC address and Data Label as if it were learned by them locally on their member port of LAALP1; the LAALP1 unrelated RBridges just ignore LAALP1's boundary APPsub-TLVs and treat the MAC address and Data Label as specified in [RFC7357]. Furthermore, in order to make the LAALP1 unrelated RBridges know that the MAC and Data Label are reachable through the RBv that provides service to LAALP1, the Topology-ID/Nickname field of the MAC-RI TLV SHOULD carry the pseudo-nickname of the RBv, rather than a zero value or one of the originating RBridge's (i.e., RB2's) regular nicknames.
8. Member Link Failure in an RBv
As shown in Figure 4, suppose that the link RB1-CE1 fails. Although a new RBv will be formed by RB2 and RB3 to provide active-active service for LAALP1 (see Section 5), the unicast traffic to CE1 might still be forwarded to RB1 before the remote RBridge learns that CE1 is attached to the new RBv. That traffic might be disrupted by the link failure. Section 8.1 discusses failure protection in this scenario. However, multi-destination TRILL Data packets can reach all member RBridges of the new RBv and be egressed to CE1 by either RB2 or RB3 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the packet's Inner.Label maps to in the new RBv). Although there might be a transient hang time between failure and the establishment of the new RBv, special actions to protect against downlink failure for such multi-destination packets are not needed. ------------------ / \ | TRILL Campus | \ / -------------------- | | | +---+ | +----+ | | | +------+ +------+ +------+ | RB1 | | RB2 | | RB3 | ooooooo|ooooo|oooooo|ooo|ooooo | o+------+ RBv +------+ +-----o+ o|oooo|ooooooo|oooo|ooooo|oo|o | | | +-|-----+ | \|/+--|-------+ | +------+ | - B | +----------|------+ | | /|\| +-----------+ | | | (| | |)<--LAALP1 (| | |)<--LAALP2 +-------+ +-------+ | CE1 | | CE2 | +-------+ +-------+ B - Failed Link or Link Bundle Figure 4: A Multi-Homed CE with a Failed Link
8.1. Link Protection for Unicast Frame Egressing
When the link CE1-RB1 fails, RB1 loses its direct connection to CE1. The MAC entry through the failed link to CE1 is removed from RB1's local forwarding table immediately. Another MAC entry learned from another member RBridge of LAALP1 (for example, RB2, since it is still a member RBridge of LAALP1) is installed into RB1's forwarding table (see Section 9.3). In that new entry, RB2 (identified by one of its regular nicknames) is the egress RBridge for CE1's MAC address. Then, when a TRILL Data packet to CE1 is delivered to RB1, it can be tunneled to RB2 after being re-encapsulated (the ingress nickname remains unchanged and the egress nickname is replaced by RB2's regular nickname) based on the above installed MAC entry (see bullet 2 in Section 6.2.1). RB2 then receives the frame and egresses it to CE1. After failure recovery, RB1 learns that it can reach CE1 via link CE1-RB1 again by observing CE1's native frames or from the MAC information synchronization by member RBridge(s) of LAALP1 as described in Section 7. It then restores the MAC entry to its previous one and downloads it to its data-plane "fast path" logic.9. TLV Extensions for Edge RBridge Group
The following subsections specify the APPsub-TLVs needed to support pseudo-nickname edge groups.9.1. PN-LAALP-Membership APPsub-TLV
This APPsub-TLV is used by an edge RBridge to announce its associated pseudo-nickname LAALP information. It is defined as a sub-TLV of the TRILL GENINFO TLV [RFC7357] and is distributed in E-L1FS FS-LSPs [RFC7780]. It has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = PN-LAALP-Membership | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ | LAALP RECORD(1) | (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ | LAALP RECORD(n) | (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ Figure 5: PN-LAALP-Membership Advertisement APPsub-TLV
where each LAALP RECORD has the following form:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 ..
+--+-+-+-+-+-+-+-+
|OE| RESV | (1 byte)
+--+-+-+-+-+-+-+-+
| Size | (1 byte)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reusing Pseudo-Nickname | (2 bytes)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID | (variable)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
o PN-LAALP-Membership (2 bytes): Defines the type of this
sub-TLV, 2.
o Length (2 bytes): The sum of the lengths of the LAALP RECORDs.
o OE (1 bit): A flag indicating whether or not the LAALP wants to
occupy an RBv by itself; 1 for occupying by itself (or Occupying
Exclusively (OE)). By default, it is set to 0 on transmit. This
bit is used for edge RBridge group auto-discovery (see
Section 4.1). For any one LAALP, the values of this flag might
conflict in the LSPs advertised by different member RBridges of
that LAALP. In that case, the flag for that LAALP is considered
to be 1.
o RESV (7 bits): MUST be transmitted as zero and ignored on receipt.
o Size (1 byte): Size of the remaining part of the LAALP RECORD
(2 plus the length of the LAALP ID).
o Reusing Pseudo-Nickname (2 bytes): Suggested pseudo-nickname of
the AAE group serving the LAALP. If the LAALP is not served by
any AAE group, this field MUST be set to zero. It is used by the
originating RBridge to help the vDRB to reuse the previous
pseudo-nickname of an AAE group (see Section 4.2).
o LAALP ID (variable): The ID of the LAALP. See Section 9.4.
On receipt of such an APPsub-TLV, if RBn is not an LAALP related edge
RBridge, it ignores the sub-TLV; otherwise, it parses the sub-TLV.
When new LAALPs are found or old ones are withdrawn compared to its
old copy, and they are also configured on RBn, RBn performs the
"Member RBridges Auto-Discovery" procedure described in Section 4.
9.2. PN-RBv APPsub-TLV
The PN-RBv APPsub-TLV is used by a Designated RBridge of a virtual RBridge (vDRB) to dictate the pseudo-nickname for the LAALPs served by the RBv. It is defined as a sub-TLV of the TRILL GENINFO TLV [RFC7357] and is distributed in E-L1FS FS-LSPs [RFC7780]. It has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = PN-RBv | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RBv's Pseudo-Nickname | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAALP ID Size | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ | LAALP ID (1) | (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ | LAALP ID (n) | (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ o PN-RBv (2 bytes): Defines the type of this sub-TLV, 3. o Length (2 bytes): 3+n*k bytes, where there are n LAALP IDs, each of size k bytes. k is found in the LAALP ID Size field below. If Length is not 3 plus an integer times k, the sub-TLV is corrupt and MUST be ignored. o RBv's Pseudo-Nickname (2 bytes): The appointed pseudo-nickname for the RBv that serves the LAALPs listed in the following fields. o LAALP ID Size (1 byte): The size of each of the following LAALP IDs in this sub-TLV. 8 if the LAALPs listed are MC-LAGs or DRNI (Section 6.3.2 of [802.1AX]). The value in this field is the k value that appears in the formula for Length above. o LAALP ID (LAALP ID Size bytes): The ID of the LAALP. See Section 9.4. This sub-TLV may occur multiple times with the same RBv pseudo-nickname; this means that all of the LAALPs listed are identified by that pseudo-nickname. For example, if there are LAALP IDs of different length, then the LAALP IDs of each size would have to be listed in a separate sub-TLV.
Because a PN-RBv APPsub-TLV is distributed as part of the application link state by using the E-L1FS FS-LSP [RFC7780], creation, changes to contents, or withdrawal of a PN-RBv APPsub-TLV is accomplished by the Designated RBridge updating and flooding an E-L1FS PDU. On receipt of such a sub-TLV, if RBn is not an LAALP related edge RBridge, it ignores the sub-TLV. Otherwise, if RBn is also a member RBridge of the RBv identified by the list of LAALPs, it associates the pseudo-nickname with the ports of these LAALPs and downloads the association to data-plane fast path logic. At the same time, RBn claims the RBv's pseudo-nickname across the campus and announces the RBv as its child on the corresponding tree or trees using the Affinity sub-TLV [RFC7176] [RFC7783].9.3. PN-MAC-RI-LAALP Boundary APPsub-TLVs
In this document, two APPsub-TLVs are used as boundary APPsub-TLVs for an edge RBridge to enclose the MAC-RI TLV(s) containing the MAC address information learned from the local port of an LAALP when this RBridge wants to share the information with other edge RBridges. They are defined as TRILL APPsub-TLVs [RFC7357]. The PN-MAC-RI-LAALP-INFO-START APPsub-TLV has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=PN-MAC-RI-LAALP-INFO-START| (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+ | LAALP ID | (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+ o PN-MAC-RI-LAALP-INFO-START (2 bytes): Defines the type of this sub-TLV, 4. o Length (2 bytes): The size of the following LAALP ID. 8 if the LAALP listed is an MC-LAG or DRNI. o LAALP ID (variable): The ID of the LAALP (see Section 9.4).
The PN-MAC-RI-LAALP-INFO-END APPsub-TLV is defined as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=PN-MAC-RI-LAALP-INFO-END | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o PN-MAC-RI-LAALP-INFO-END (2 bytes): Defines the type of this
sub-TLV, 5.
o Length (2 bytes): 0.
This pair of APPsub-TLVs can be carried multiple times in an
ESADI-LSP and in multiple ESADI-LSPs. When an LAALP related edge
RBridge (say RBn) wants to share with other edge RBridges the MAC
addresses learned on its local ports of different LAALPs, it uses one
or more pairs of such APPsub-TLVs for each such LAALP in its
ESADI-LSPs. Each encloses the MAC-RI TLVs containing the MAC
addresses learned from a specific LAALP. Furthermore, if the LAALP
is served by a local RBv, the value of the Topology-ID/Nickname field
in the relative MAC-RI TLVs SHOULD be the pseudo-nickname of the RBv,
rather than one of RBn's regular nicknames or a zero value. Then, on
receipt of such a MAC-RI TLV, remote RBridges know that the contained
MAC addresses are reachable through the RBv.
On receipt of such boundary APPsub-TLVs, when the edge RBridge is not
an LAALP related one or cannot recognize such sub-TLVs, it ignores
them and continues to parse the enclosed MAC-RI TLVs per [RFC7357].
Otherwise, the recipient parses the boundary APPsub-TLVs. The
PN-MAC-RI-LAALP-INFO-START / PN-MAC-RI-LAALP-INFO-END pair MUST occur
within one TRILL GENINFO TLV. If an END is encountered without any
previous START in the ESADI-LSP, the END APPsub-TLV is ignored.
After encountering a START, if the end of the ESADI-LSP is reached
without encountering an END, then the end of the ESADI-LSP is treated
as if it were a PN-MAC-RI-LAALP-INFO-END. The boundary APPsub-TLVs
and TLVs between them are handled as follows:
1) If the edge RBridge is configured with the contained LAALP and the
LAALP is also enabled locally, it treats all the MAC addresses
contained in the following MC-RI TLVs enclosed by the
corresponding pair of boundary APPsub-TLVs as if they were learned
from its local port of that LAALP;
2) Else, it ignores these boundary APPsub-TLVs and continues to parse
the following MAC-RI TLVs per [RFC7357] until another pair of
boundary APPsub-TLVs is encountered.
9.4. LAALP IDs
The LAALP ID identifies an AAE RBridge group in the TRILL campus and thus MUST be unique across the campus. In all of the APPsub-TLVs specified above, the length of the LAALP ID can be determined from a size field. If that length is 8 bytes, the LAALP ID is an MC-LAG or DRNI identifier as specified in Section 6.3.2 of [802.1AX]. The meaning and structure of LAALP IDs of other lengths are reserved and may be specified in future documents.10. OAM Packets
Attention must be paid when generating Operations, Administration, and Maintenance (OAM) packets. To ensure that the response messages can return to the originating member RBridge of an RBv, a pseudo-nickname cannot be used as the ingress nickname in TRILL OAM messages, except in the response to an OAM message that has that RBv's pseudo-nickname as the egress nickname. For example, assume that RB1 is a member RBridge of RBvi. RB1 cannot use RBvi's pseudo-nickname as the ingress nickname when originating OAM messages; otherwise, the responses to the messages may be delivered to another member RBridge of RBvi rather than RB1. But when RB1 responds to the OAM message with RBvi's pseudo-nickname as the egress nickname, it can use that pseudo-nickname as the ingress nickname in the response message. Since RBridges cannot use OAM messages for the learning of MAC addresses (Section 3.2.1 of [RFC7174]), it will not lead to MAC address flip-flopping at a remote RBridge, even though RB1 uses its regular nicknames as ingress nicknames in its TRILL OAM messages, and at the same time RB1 uses RBvi's pseudo-nickname in its TRILL Data packets.11. Configuration Consistency
The VLAN membership of all the RBridge ports in an LAALP MUST be the same. Any inconsistencies in VLAN membership may result in packet loss or non-shortest paths. Take Figure 1 as an example. Suppose that RB1 configures VLAN1 and VLAN2 for the CE1-RB1 link, while RB2 only configures VLAN1 for the CE1-RB2 link. Both RB1 and RB2 use the same ingress nickname RBv for all frames originating from CE1. Hence, a remote RBridge (say RBx) will learn that CE1's MAC address in VLAN2 is originating from the RBv. As a result, on the return path, RBx may deliver VLAN2 traffic to RB2. However, RB2 does not have VLAN2 configured on the CE1-RB2 link, and hence the frame may be dropped or has to be redirected to RB1 if RB2 knows that RB1 can reach CE1 in VLAN2.
How LAALP implementations maintain consistent VLAN configuration on the TRILL switch LAALP ports is out of scope for the TRILL protocol. However, considering the consequences that might be caused by inconsistencies, TRILL switches MUST disable the ports connected to an LAALP with an inconsistent VLAN configuration. It is important that if any VLAN in an LAALP is being mapped by edge RBridges to an FGL [RFC7172] the mapping MUST be the same for all edge RBridge ports in the LAALP. Otherwise, for example, unicast FGL TRILL Data packets from remote RBridges may get mapped into different VLANs, depending on which edge RBridge receives and egresses them. It is important that RBridges in an AAE group not be configured to assert the OE-flag if any RBridge in the group does not implement it. Since, as stated in [RFC7379], the RBridges in an AAE edge group are expected to be from the same vendor, due to the proprietary nature of deployed LAALPs, this will normally follow automatically from all of the RBridges in an AAE edge group supporting, or not supporting, OE.12. Security Considerations
Authenticity for contents transported in IS-IS PDUs is enforced using regular IS-IS security mechanisms [IS-IS] [RFC5310]. For security considerations pertaining to extensions transported by TRILL ESADI, see the Security Considerations section in [RFC7357]. Since currently deployed LAALPs [RFC7379] are proprietary, security over membership in, and internal management of, active-active edge groups is proprietary. If authentication is not used, a rogue RBridge that insinuates itself into an active-active edge group can disrupt end-station traffic flowing into or out of that group. For example, if there are N RBridges in the group, it could typically control 1/Nth of the traffic flowing out of that group and a similar amount of unicast traffic flowing into that group. For multi-destination traffic flowing into that group, it could control all that was in a VLAN for which it was the DF and can exercise substantial control over the DF election by changing its own System ID. For general TRILL security considerations, see [RFC6325].
13. IANA Considerations
IANA has allocated four code points from the range below 255 for the four TRILL APPsub-TLVs specified in Section 9 and added them to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry, as follows: Type Name Reference ---- -------------------------- --------- 2 PN-LAALP-Membership RFC 7781 3 PN-RBv RFC 7781 4 PN-MAC-RI-LAALP-INFO-START RFC 7781 5 PN-MAC-RI-LAALP-INFO-END RFC 778114. References
14.1. Normative References
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std 802.1AX-2014, DOI 10.1109/IEEESTD.2014.7055197, December 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>. [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, <http://www.rfc-editor.org/info/rfc6165>. [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>. [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, DOI 10.17487/RFC6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>. [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>. [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>. [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>. [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>. [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>. [RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 2016, <http://www.rfc-editor.org/info/rfc7783>.
14.2. Informative References
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002. [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, <http://www.rfc-editor.org/info/rfc7174>. [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <http://www.rfc-editor.org/info/rfc7379>. [RFC7782] Zhang, M., Perlman, R., Zhai, H., Durrani, M., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments", RFC 7782, DOI 10.17487/RFC7782, February 2016, <http://www.rfc-editor.org/info/rfc7782>.
Acknowledgments
We would like to thank Mingjiang Chen for his contributions to this document. Additionally, we would like to thank Erik Nordmark, Les Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Janardhanan Pathangi, Jon Hudson, and Fangwei Hu for their good questions and comments.Contributors
Weiguo Hao Huawei Technologies 101 Software Avenue Nanjing 210012 China Phone: +86-25-56623144 Email: haoweiguo@huawei.com Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States Phone: +1-508-333-2270 Email: d3e3e3@gmail.com
Authors' Addresses
Hongjun Zhai Jinling Institute of Technology 99 Hongjing Avenue, Jiangning District Nanjing, Jiangsu 211169 China Email: honjun.zhai@tom.com Tissa Senevirathne Consultant Email: tsenevir@gmail.com Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States Email: Radia@alum.mit.edu Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China Email: zhangmingui@huawei.com Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China Phone: +86-25-56625409 Email: liyizhou@huawei.com