Internet Engineering Task Force (IETF) D. Eastlake 3rd Request for Comments: 7978 Huawei Updates: 7178 M. Umair Category: Standards Track IPinfusion ISSN: 2070-1721 Y. Li Huawei September 2016
Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension
Abstract
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism (specified in RFC 7178) called RBridge Channel for the transmission of typed messages between TRILL switches in the same campus and the transmission of such messages between TRILL switches and end stations on the same link. This document specifies extensions to the RBridge Channel protocol header to support two features as follows: (1) a standard method to tunnel payloads whose type can be indicated by Ethertype through encapsulation in RBridge Channel messages; and (2) a method to support security facilities for RBridge Channel messages. This document updates RFC 7178.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7978.
Eastlake, et al. Standards Track [Page 1]
RFC 7978 TRILL: RBridge Channel Extension September 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Eastlake, et al. Standards Track [Page 2]
RFC 7978 TRILL: RBridge Channel Extension September 2016
The IETF TRILL base protocol [RFC6325] [RFC7780] has been extended with the RBridge Channel [RFC7178] facility to support transmission of typed messages (for example, Bidirectional Forwarding Detection (BFD) [RFC7175]) between two TRILL switches (RBridges) in the same campus and the transmission of such messages between RBridges and end stations on the same link. When sent between RBridges in the same campus, a TRILL Data packet with a TRILL Header is used, and the destination RBridge is indicated by nickname. When sent between a RBridge and an end station on the same link in either direction, a native RBridge Channel message [RFC7178] is used with no TRILL Header, and the destination port or ports are indicated by a Media Access Control (MAC) address. (There is no mechanism to stop end stations on the same link from sending native RBridge Channel messages to each other; however, such use is outside the scope of this document.)
This document updates [RFC7178] and specifies extensions to the RBridge Channel header that provide two additional facilities as follows:
(1) A standard method to tunnel payloads, whose type may be indicated by Ethertype, through encapsulation in RBridge Channel messages.
(2) A method to provide security facilities for RBridge Channel messages. Example uses requiring such facilities are the security of Pull Directory messages [RFC7067], address flush messages [AddrFlush], and port shutdown messages [TRILL-AF].
Use of each of these facilities is optional, except that, as specified below, if this header extension is implemented, there are two payload types that MUST be implemented. Both of the above facilities can be used in the same packet. In case of conflict between this document and [RFC7178], this document takes precedence.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This document uses terminology and abbreviations defined in [RFC6325] and [RFC7178]. Some of these are listed below for convenience along with new terms and abbreviations.
Eastlake, et al. Standards Track [Page 4]
RFC 7978 TRILL: RBridge Channel Extension September 2016
The general structure of an RBridge Channel message between two TRILL switches (RBridges) in the same campus is shown in Figure 1 below. The structure of a native RBridge Channel message sent between an RBridge and an end station on the same link, in either direction, is shown in Figure 2 and, compared with the first case, omits the TRILL Header, inner Ethernet addresses, and Data Label. A Protocol field in the RBridge Channel Header gives the type of RBridge Channel message and indicates how to interpret the Channel-Protocol-Specific Payload [RFC7178].
Eastlake, et al. Standards Track [Page 5]
RFC 7978 TRILL: RBridge Channel Extension September 2016
+-----------------------------------+ | Link Header | +-----------------------------------+ | TRILL Header | +-----------------------------------+ | Inner Ethernet Addresses | +-----------------------------------+ | Data Label (VLAN or FGL) | +-----------------------------------+ | RBridge Channel Header | +-----------------------------------+ | Channel-Protocol-Specific Payload | +-----------------------------------+ | Link Trailer (FCS if Ethernet) | +-----------------------------------+
where 0x8946 is the RBridge-Channel Ethertype and CHV is the Channel Header Version. This document is based on RBridge Channel version zero.
Eastlake, et al. Standards Track [Page 6]
RFC 7978 TRILL: RBridge Channel Extension September 2016
The header extensions specified herein are in the form of an RBridge Channel protocol, the Extended RBridge Channel Protocol. Figure 4 below expands the RBridge Channel Header and Protocol-Specific Payload above for the case where the header extension is present.
The RBridge Channel Header Protocol field is used to indicate that the header extension is present. Its contents MUST be the value allocated for this purpose (see Section 6). The use of an RBridge Channel protocol to indicate extensions makes it easy to determine if a remote RBridge in the campus supports extensions since RBridges advertise in their LSP which such protocols they support.
The Extended RBridge Channel-Protocol-Specific Data fields are as follows:
SubERR: This field provides further details when an error is indicated in the RBridge Channel ERR field. If ERR is zero, then SubERR MUST be sent as zero and ignored on receipt. See Section 5.
RESV4: This field MUST be sent as zero. If non-zero when received, this is an error condition. See Section 5.
SType: This field describes the type of security information and features, including keying material, being used or provided by the extended RBridge Channel message. See Section 4.
PType: Payload Type. This describes the tunneled data. See Section 3.
Eastlake, et al. Standards Track [Page 7]
RFC 7978 TRILL: RBridge Channel Extension September 2016
Security Information: Variable-length information. Length is zero if SType is zero. See Section 4.
The RBridge Channel Header Extension is integrated with the RBridge Channel facility. Extension errors are reported as if they were RBridge Channel errors, using newly allocated code points in the ERR field of the RBridge Channel Header supplemented by the SubERR field.
The Extended RBridge Channel Protocol can carry a variety of payloads as indicated by the PType (Payload Type) field. Values are shown in the table below with further explanation below the table (see also Section 6.2.2).
While implementation of the RBridge Channel Header Extension is optional, if it is implemented, PType 1 (Null) MUST be implemented and PType 2 (Ethertyped Payload) with the RBridge-Channel Ethertype MUST be implemented. PType 2 for any Ethertypes other than the RBridge-Channel Ethertype MAY be implemented. PType 3 MAY be implemented.
The processing of any particular extended header RBridge Channel message and its payload depends on meeting local security and other policy at the destination TRILL switch or end station.
The Null payload type (PType = 1) is intended to be used for testing or for messages such as key negotiation or the like where only security information is present. It indicates that there is no user data payload. Any tunneled user data after the Security Information field is ignored. If the RBridge Channel Header Extension is implemented, the Null Payload MUST be supported in the sense that an "Unsupported PType" error is not returned (see Section 5). Any particular use of the Null Payload should specify what VLAN or FGL
Eastlake, et al. Standards Track [Page 8]
RFC 7978 TRILL: RBridge Channel Extension September 2016
and what priority should be used in the inner Data Label of the RBridge Channel message (or in an outer VLAN tag for the native RBridge Channel message case) when those values are relevant.
A PType of 2 indicates that the payload (tunneled data) of the extended RBridge Channel message begins with an Ethertype. A TRILL switch supporting the RBridge Channel Header Extension MUST support a PType of 2 with a payload beginning with the RBridge-Channel Ethertype as described in Section 3.2.1. Other Ethertypes, including the TRILL and L2-IS-IS Ethertypes as described in Sections 3.2.2 and 3.2.3, MAY be supported.
A PType of 2 whose payload has an initial RBridge-Channel Ethertype indicates an encapsulated RBridge Channel message. A typical reason for sending an RBridge Channel message inside an extended RBridge Channel message is to provide security services, such as authentication or encryption, for the encapsulated message.
This RBridge Channel message type looks like the following:
A PType of 2 whose payload has an initial TRILL Ethertype indicates an encapsulated TRILL Data packet as shown in Figure 6. If this Ethertype is supported for PType = 2 and the message meets local policy for acceptance, the TRILL Data packet is handled as if it had been received by the destination TRILL switch on the port where the Extended RBridge Channel message was received.
A PType of 2 and an initial L2-IS-IS Ethertype indicate that the payload of the Extended RBridge Channel protocol message is an encapsulated TRILL IS-IS PDU as shown in Figure 7. If this Ethertype is supported for PType = 2, the tunneled TRILL IS-IS packet is processed by the destination RBridge if it meets local policy. One possible use is to expedite the receipt of a link state PDU (LSP) by
Eastlake, et al. Standards Track [Page 10]
RFC 7978 TRILL: RBridge Channel Extension September 2016
some TRILL switch or switches with an immediate requirement for the link state information. A link local IS-IS PDU would not normally be sent via this Extended RBridge Channel method except possibly to encrypt the PDU since such PDUs can just be transmitted on the link and do not normally need RBridge Channel handling. (Link local IS-IS PDUs are (1) Hello, CSNP, PSNP [IS-IS]; (2) MTU-probe, MTU-ack [RFC7176]; and (3) circuit scoped FS-LSP, FS-CSNP, and FS-PSNP [RFC7356].)
If PType is 3, the extended RBridge Channel payload is an Ethernet frame as might be received from or sent to an end station except that the encapsulated Ethernet frame's FCS is omitted, as shown in Figure 8. (There is still an overall final FCS if the RBridge Channel message is being sent on an Ethernet link.) If this PType is implemented and the message meets local policy, the encapsulated frame is handled as if it had been received on the port on which the Extended RBridge Channel message was received.
The priority of the RBridge Channel message can be copied from the Ethernet frame VLAN tag, if one is present, except that priority 7 SHOULD only be used for messages critical to establishing or maintaining adjacency and priority 6 SHOULD only be used for other important control messages.
Eastlake, et al. Standards Track [Page 11]
RFC 7978 TRILL: RBridge Channel Extension September 2016
Figure 8: Message Structure with Ethernet Frame Payload
In the case of a non-Ethernet link, such as a PPP (Point-to-Point Protocol) link [RFC6361], the ports on the link are considered to have link-local synthetic 48-bit MAC addresses constructed as described below. Such a constructed address MAY be used as a MacSA. If the RBridge Channel message is individually addressed to a link- local port, the source TRILL switch will have the information to construct such a MAC address for the destination TRILL switch port, and that MAC address MAY be used as the MacDA. By the use of such a MacSA and either such a unicast MacDA or a group-addressed MacDA, an Ethernet frame can be sent between two TRILL switch ports connected by a non-Ethernet link.
These synthetic TRILL switch port MAC addresses for non-Ethernet ports are constructed as follows (and as shown in Figure 9): 0xFEFF, the nickname of the TRILL switch used in TRILL Hellos sent on that port, and the Port ID that the TRILL switch has assigned to that port. (Both the Port ID of the port on which a TRILL Hello is sent and the nickname of the sending TRILL switch appear in the Special VLANs and Flags sub-TLV [RFC7176] in TRILL IS-IS Hellos.) The resulting MAC address has the Local bit on and the Group bit off [RFC7042]. However, since there will be no Ethernet end stations on a non-Ethernet link in a TRILL campus, such synthetic MAC addresses cannot conflict on the link with a real Ethernet port address regardless of their values.
Eastlake, et al. Standards Track [Page 12]
RFC 7978 TRILL: RBridge Channel Extension September 2016
Table 2 below gives the assigned values of the SType (Security Type) field and their meaning. Use of DTLS Pairwise Security (SType = 2) or Composite Security (SType = 3) is RECOMMENDED.
While IS-IS CRYPTO_AUTH-based authentication is also specified and can be used for both pairwise and multi-destination traffic, it provides only authentication and is not considered to meet current security standards. For example, it does not provide for key negotiation; thus, its use is NOT RECOMMENDED.
The Extended RBridge Channel DTLS-based security specified in Section 4.4 and the Composite Security specified in Section 4.5 are intended for pairwise (known unicast) use. That is, the case where the M bit in the TRILL Header is zero and any Outer.MacDA is individually addressed.
Multi-destination Extended RBridge Channel packets would be those with the M bit in the TRILL Header set to one or, in the native RBridge Channel case, the Outer.MacDA would be group addressed. The DTLS Pairwise Security and Composite Security STypes can also be used in the multi-destination case by serially unicasting the messages to all data-accessible RBridges (or stations in the native RBridge Channel case) in the recipient group. For TRILL Data packets, that group is specified by the Data Label; for native frames, the group is specified by the groupcast destination MAC address. It is intended to specify a true group keyed SType to secure multi-destination packets in a separate document [GroupKey].
Eastlake, et al. Standards Track [Page 13]
RFC 7978 TRILL: RBridge Channel Extension September 2016
In some cases, it is possible to use material derived from IS-IS CRYPTO_AUTH keying material [RFC5310] as an element of Extended RBridge Channel security. It is assumed that the IS-IS keying material is of high quality. The material actually used is derived from the IS-IS keying material as follows:
Derived Material = HKDF-Expand-SHA256 ( IS-IS-key, "Extended Channel" | 0x0S, L )
where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is as in [RFC6234], IS-IS-key is the input IS-IS keying material, "Extended Channel" is the 16-character ASCII [RFC20] string indicated without any leading length byte or trailing zero byte, 0x0S is a single byte where S is the SType for which this key derivation is being used and the upper nibble is zero, and L is the length of the output-derived material needed.
Whenever IS-IS keying material is being used as above, the underlying IS-IS CRYPTO_AUTH keying material [RFC5310] might expire or be invalidated. At the time of or before such expiration or invalidation, the use of the Derived Material from the IS-IS keying material MUST cease. Continued security MAY use new derived material from currently valid IS-IS CRYPTO_AUTH keying material.
This SType provides security for Extended RBridge Channel messages similar to that provided for [IS-IS] PDUs by the [IS-IS] Authentication TLV. The Security Information (see Figure 4) is as shown in Figure 10.
o RESV: Four bits that MUST be sent as zero and ignored on receipt.
o Size: Set to 2 + the size of Authentication Data in bytes.
o Key ID: specifies the keying value and authentication algorithm that the Key ID specifies for TRILL IS-IS LSP [RFC5310] Authentication TLVs. The keying material actually used is always derived as shown in Section 4.1.
o Authentication Data: The authentication data produced by the derived key and algorithm associated with the Key ID acting on the part of the TRILL Data packet shown. Length of the authentication data depends on the algorithm. The authentication value is included in the security information field and is treated as zero when authentication is calculated.
As show in Figure 11, the area covered by this authentication starts with the byte immediately after the TRILL Header optional Flag Word if it is present. If the Flag Word is not present, it starts after the TRILL Header Ingress Nickname. In either case, it extends to just before the TRILL Data packet link trailer. For example, for an Ethernet packet it would extend to just before the FCS.
Eastlake, et al. Standards Track [Page 15]
RFC 7978 TRILL: RBridge Channel Extension September 2016
In the native RBridge Channel case, this authentication coverage is as specified in the above paragraph except that it starts with the RBridge-Channel Ethertype, since there is no TRILL Header, inner Ethernet addresses, or inner Data Label (see Figure 12).
RBridges, which are IS-IS routers, can reasonably be expected to hold IS-IS CRYPTO_AUTH keying material [RFC5310] so that this SType can be used for RBridge Channel messages, which go between RBridges. How end stations might come to hold IS-IS CRYPTO_AUTH keying material is
Eastlake, et al. Standards Track [Page 16]
RFC 7978 TRILL: RBridge Channel Extension September 2016
beyond the scope of this document. Thus, this SType might not be applicable to native RBridge Channel messages, which are between an RBridge and an end station.
DTLS [RFC6347] supports key negotiation and provides both encryption and authentication. The RBridge Channel Extended Header DTLS Pairwise SType uses a negotiated DTLS version that MUST NOT be less than 1.2.
When DTLS pairwise security is used, the entire payload of the Extended RBridge Channel packet, starting just after the null Security Information and ending just before the link trailer, is one or more DTLS records [RFC6347]. As specified in [RFC6347], DTLS records MUST be limited by the path MTU, in this case so that each record fits entirely within a single Extended RBridge Channel message. A minimum path MTU can be determined from the TRILL campus minimum MTU Sz, which will not be less than 1470 bytes, by allowing for the TRILL Data packet, extended RBridge Channel, and DTLS framing overhead. With this SType, the security information between the extended RBridge Channel header and the payload is null because all the security information is in the payload area.
The DTLS Pairwise keying is set up between a pair of RBridges, independent of Data Label, using messages of a priority configurable at the RBridge level, which defaults to priority 6. DTLS message types other than application_data can be the payload of an extended RBridge Channel message with a TRILL Header using any Data Label, and, for such DTLS message types, the PType in the RBridge Channel Header Extension is ignored.
Actual application_data sent within such a message using this SType SHOULD use the Data Label and priority as specified for that application_data. In this case, the PType value in the RBridge Channel Header Extension applies to the decrypted application_data.
TRILL switches that implement the extended RBridge Channel DTLS Pairwise SType SHOULD support the use of certificates for DTLS, but certificate size may be limited by the DTLS requirement that each record fit within a single message. Appropriate certificate contents are out of scope for this document.
TRILL switches that support the extended RBridge Channel DTLS Pairwise SType MUST support the use of pre-shared keys. If the psk_identity (see [RFC4279]) is two bytes, it is interpreted as a Key ID as defined in [RFC5310], and the value derived as shown in Section 4.1 from that key is used as a pre-shared key for DTLS
Eastlake, et al. Standards Track [Page 17]
RFC 7978 TRILL: RBridge Channel Extension September 2016
negotiation. A psk_identity with a length other than two bytes MAY be used to indicate other implementation-dependent pre-shared keys. Pre-shared keys used for DTLS negotiation SHOULD be shared only by the pair of endpoints; otherwise, security could be attacked by diverting messages to another endpoint holding that pre-shared key.
Composite Security (SType = 3) is the combination of DTLS Pairwise Security and IS-IS CRYPTO_AUTH-Based Authentication. On transmission, the DTLS record or records to be sent are secured as specified in Section 4.4 then used as the payload for the application of Authentication as specified in Section 4.3. On reception, the IS-IS CRYPTO_AUTH-based authentication is verified first and an error is returned if it fails. If the IS-IS CRYPTO_AUTH-based authentication succeeds, then the DTLS record or records are processed.
An advantage of Composite Security is that the payload is authenticated and encrypted with a modern security protocol; in addition, the RBridge Channel Header and (except in the native case) preceding the MAC addresses and Data Label are provided with some authentication.
RBridge Channel Header Extension errors are reported like RBridge Channel errors. The ERR field is set to one of the following error codes:
Value RBridge Channel Error Code Meaning ----- ------------------------------------ 6 Unknown or unsupported field value 7 Authentication failure 8 Error in nested RBridge Channel message
Table 3: Additional ERR Values
Eastlake, et al. Standards Track [Page 18]
RFC 7978 TRILL: RBridge Channel Extension September 2016
If the ERR field is 6, the SubERR field indicates the problematic field or value as shown in the table below. At this time no suberrror codes are assigned under any other ERR field value.
Err SubERR Meaning (for ERR = 6) --- ------ ----------------------- 0 No Error; suberrors not allowed 1-5 (no suberrors assigned) 6 0 Reserved 6 1 Non-zero RESV4 nibble 6 2 Unsupported SType 6 3 Unsupported PType 6 4 Unknown Key ID 6 5 Unsupported Ethertype with PType = 2 6 6 Unsupported authentication algorithm for SType = 1 6 7 Non-zero SubERR with zero ERR field 7-14 (no suberrors assigned) 15 Reserved
If o an extended RBridge Channel message is sent with security and with a payload type (PType) indicating an Ethertyped payload and the Ethertype indicates a nested RBridge Channel message and o there is an error in the processing of that nested message that results in a return RBridge Channel message with a non-zero ERR field, then that returned message SHOULD also be nested in an extended RBridge Channel message using the same type of security. In this case, the ERR field in the Extended RBridge Channel envelope is set to 8 indicating that there is a nested error in the message being tunneled back.
IANA has assigned 0x004 from the range assigned by Standards Action [RFC5226] as the RBridge Channel protocol number to indicate RBridge Channel Header Extension.
Eastlake, et al. Standards Track [Page 19]
RFC 7978 TRILL: RBridge Channel Extension September 2016
The added "RBridge Channel Protocols" registry in the TRILL Parameters registry is as follows:
IANA has assigned three additional code points in the "RBridge Channel Error Codes" subregistry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry. The additional entries are as shown in Table 3 in Section 5 and the "Reference" column value is "RFC 7978" for those rows.
IANA has created a subregistry indented under the "RBridge Channel Error Codes" registry, for RBridge Channel SubError Codes. The initial contents of this subregistry are shown in Table 4 in Section 5.1 and the fourth column "Reference" includes value "RFC 7978" for all rows. The header information is as follows:
IANA has created an "Extended RBridge Channel Payload Types" subregistry after the "RBridge Channel Protocols" registry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry. The header information is as follows:
IANA has created an "Extended RBridge Channel Security Types" subregistry after the "Extended RBridge Channel Payload Types" registry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry. The header information is as follows:
The RBridge Channel Header Extension has potentially positive and negative effects on security.
On the positive side, it provides optional security that can be used to authenticate and/or encrypt RBridge Channel messages. Some RBridge Channel message payloads, such as BFD [RFC7175], provide their own security but where this is not true, consideration should be given, when specifying an RBridge Channel protocol, to recommending or requiring use of the security features of the RBridge Channel Header Extension.
On the negative side, the optional ability to tunnel more payload types, and to tunnel them between TRILL switches and to and from end stations, can increase risk unless precautions are taken. The processing of decapsulated extended RBridge Channel payloads is a place where you SHOULD NOT be liberal in what you accept. This is because the tunneling facility makes it easier for unexpected messages to pop up in unexpected places in a TRILL campus due to accidents or the actions of an adversary. Local policies SHOULD generally be strict and only accept payload types required and then only with adequate security for the particular circumstances.
See the first paragraph of Section 4 for recommendations on SType usage.
See [RFC7457] for security considerations of DTLS.
If IS-IS authentication is not being used, then IS-IS CRYPTO_AUTH keying material [RFC5310] would not normally be available but that presumably represents a judgment by the TRILL campus operator that no security is needed.
Eastlake, et al. Standards Track [Page 21]
RFC 7978 TRILL: RBridge Channel Extension September 2016
See [RFC7178] for general RBridge Channel security considerations and [RFC6325] for general TRILL security considerations.
[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, 2002.
RFC 7978 TRILL: RBridge Channel Extension September 2016
[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>.
[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>.
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, DOI 10.17487/RFC7175, May 2014, <http://www.rfc-editor.org/info/rfc7175>.
[AddrFlush] Hao, W., Eastlake, D., and Y. Li, "TRILL: Address Flush Message", Work in Progress, draft-ietf-trill-address- flush-00, May 2016.
[GroupKey] Eastlake, D., "TRILL: Group Keying", Work in Progress, draft-eastlake-trill-group-keying-00, July 2016.
[TRILL-AF] Eastlake, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "TRILL: Appointed Forwarders", Work in Progress, draft-ietf-trill-rfc6439bis-03, August 2016.
Eastlake, et al. Standards Track [Page 24]
RFC 7978 TRILL: RBridge Channel Extension September 2016
Acknowledgements
The contributions of the following are hereby gratefully acknowledged:
Stephen Farrell, Jonathan Hardwick, Susan Hares, Gayle Noble, Alvaro Retana, Yaron Sheffer, and Peter Yee.
Authors' Addresses
Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
Phone: +1-508-333-2270 Email: d3e3e3@gmail.com
Mohammed Umair IPinfusion
Email: mohammed.umair2@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China