12. IANA Considerations (Changed) This section lists IANA actions previously completed and new IANA actions. 12.1. Previously Completed IANA Actions (Unchanged) The following IANA actions were completed as part of [RFC7180] and are included here for completeness, since this document obsoletes [RFC7180]. 1. The nickname 0xFFC1, which was reserved by [RFC6325], is allocated for use in the TRILL Header Egress Nickname field to indicate an OOMF (Overload Originated Multi-destination Frame). 2. Bit 1 from the seven previously reserved (RESV) bits in the per-neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC7176] is allocated to indicate that the RBridge sending the TRILL Hello volunteers to provide the OOMF forwarding service described in Section 2.4.2 to such frames originated by the TRILL switch whose SNPA (MAC address) appears in that Neighbor RECORD. The description of this bit is "Offering OOMF service". 3. Bit 0 is allocated from the capability bits in the PORT-TRILL-VER sub-TLV [RFC7176] to indicate support of the VLANs Appointed sub-TLV [RFC7176] and the VLAN inhibition setting mechanisms specified in [RFC6439bis]. The description of this bit is "Hello reduction support". 12.2. New IANA Actions (New) The following are new IANA actions for this document. 12.2.1. Reference Updated All references to [RFC7180] in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry have been replaced with references to this document, except that the Reference for bit 0 in the PORT-TRILL-VER Sub-TLV Capability Flags has been changed to [RFC6439bis]. 12.2.2. The "E" Capability Bit There is an existing TRILL version sub-TLV, sub-TLV #13, under both TLV #242 and TLV #144 [RFC7176]. This TRILL version sub-TLV contains a capability bits field for which assignments are documented in the "TRILL-VER Sub-TLV Capability Flags" registry on the TRILL Parameters IANA web page. IANA has allocated 4 from the previously reserved
bits in this "TRILL-VER Sub-TLV Capability Flags" registry to indicate support of the E-L1FS flooding scope as specified in Section 8.1. This capability bit is referred to as the "E" bit. The following is the addition to the "TRILL-VER Sub-TLV Capability Flags" registry: Bit Description References ---- --------------------- --------------- 4 E-L1FS FS-LSP support [RFC7356], RFC 7780 12.2.3. NickFlags APPsub-TLV Number and Registry IANA has assigned an APPsub-TLV number, as follows, under the TRILL GENINFO TLV from the range less than 255. Type Name References ---- --------- ----------- 6 NICKFLAGS RFC 7780 In addition, IANA has created a registry on its TRILL Parameters web page for NickFlags bit assignments, as follows: Name: NickFlags Bits Registration Procedure: IETF Review [RFC5226] Reference: RFC 7780 Bit Mnemonic Description Reference ----- -------- ----------- --------- 0 IN Used as ingress RFC 7780 1-15 - Unassigned RFC 7780 12.2.4. Updated TRILL Extended Header Flags The "TRILL Extended Header Flags" registry has been updated as follows: Bits Purpose Reference ----- ---------------------------------------- ------------ 14-16 Extended Hop Count RFC 7780 27-28 Extended Color RFC 7780 29-31 Available non-critical ingress-to-egress [RFC7179], RFC 7780 flags
12.2.5. TRILL-VER Sub-TLV Capability Flags The "TRILL-VER Sub-TLV Capability Flags" registry has been updated as follows: Bit Description Reference ----- -------------------------- ---------------- 14 Extended Hop Count support RFC 7780 15-16 Unassigned RFC 7780 27-28 Extended Color support RFC 7780 29-31 Extended header flag support [RFC7179], RFC 7780 12.2.6. Example Nicknames As shown in the table below, IANA has assigned a block of eight nicknames for use as examples in documentation. Appendix B shows a use of some of these nicknames. The "TRILL Nicknames" registry has been updated by changing the previous "0xFFC2-0xFFFE Unassigned" line to the following: Name Description Reference ------------- -------------- ----------- 0xFFC2-0xFFD7 Unassigned 0xFFD8-0xFFDF For use in documentation examples RFC 7780 0xFFE0-0xFFFE Unassigned 13. Security Considerations (Changed) See [RFC6325] for general TRILL security considerations. This memo improves the documentation of the TRILL protocol; corrects six errata in [RFC6325]; updates [RFC6325], [RFC7177], and [RFC7179]; and obsoletes [RFC7180]. It does not change the security considerations of those RFCs, except as follows: o E-L1FS FS-LSPs can be authenticated with IS-IS security [RFC5310], that is, through the inclusion of an IS-IS Authentication TLV in E-L1FS PDUs. o As discussed in Section 3.6, when using an allowed weaker RPF check under very rare topologies and transient conditions, multi-destination TRILL Data packets can be duplicated; this could have security consequences for some protocols.
14. References 14.1. Normative References [802.1Q-2014] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", DOI 10.1109/IEEESTD.2014.6991462, IEEE Std 802.1Q-2014. [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. [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>. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>. [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, DOI 10.17487/RFC5306, October 2008, <http://www.rfc-editor.org/info/rfc5306>. [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>. [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge Originator Identification TLV for IS-IS", RFC 6232, DOI 10.17487/RFC6232, May 2011, <http://www.rfc-editor.org/info/rfc6232>. [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>.
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, <http://www.rfc-editor.org/info/rfc6361>. [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>. [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <http://www.rfc-editor.org/info/rfc7177>. [RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 2014, <http://www.rfc-editor.org/info/rfc7179>. [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>. [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, <http://www.rfc-editor.org/info/rfc7455>.
14.2. Informative References  IEEE 802, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", DOI 10.1109/IEEESTD.2014.6847097, IEEE Std 802-2014. [Centralized-Replication] Hao, W., Li, Y., Durrani, M., Gupta, S., Qu, A., and T. Han, "Centralized Replication for BUM traffic in active-active edge connection", Work in Progress, draft-ietf-trill-centralized-replication-03, November 2015. [Err3002] RFC Errata, Erratum ID 3002, RFC 6325. [Err3003] RFC Errata, Erratum ID 3003, RFC 6325. [Err3004] RFC Errata, Erratum ID 3004, RFC 6325. [Err3052] RFC Errata, Erratum ID 3052, RFC 6325. [Err3053] RFC Errata, Erratum ID 3053, RFC 6325. [Err3508] RFC Errata, Erratum ID 3508, RFC 6325. [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>. [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, DOI 10.17487/RFC6327, July 2011, <http://www.rfc-editor.org/info/rfc6327>. [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>. [RFC6439bis] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and H. Fangwei, "TRILL: Appointed Forwarders", Work in Progress, draft-ietf-trill-rfc6439bis-01, January 2016. [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <http://www.rfc-editor.org/info/rfc7042>. [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, <http://www.rfc-editor.org/info/rfc7067>. [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>. [RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>. [RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, DOI 10.17487/RFC7180, May 2014, <http://www.rfc-editor.org/info/rfc7180>.
[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>. [TRILL-L3-GW] Hao, W., Li, Y., Qu, A., Durrani, M., Sivamurugan, P., and L. Xia, "TRILL Distributed Layer 3 Gateway", Work in Progress, draft-ietf-trill-irb-10, January 2016.
Appendix A. Life Cycle of a TRILL Switch Port (New) Text from <http://www.ietf.org/mail-archive/web/trill/ current/msg06355.html> is paraphrased in this informational appendix. Question: Suppose we are developing a TRILL implementation to run on different machines. Then what happens first? Is LSP flooding or ESADI started first? -> Link-state database creation -> Designated RBridge election (How to set priority? Any fixed process that depends on user settings?) -> etc. Answer: The first thing that happens on a port/link is any link setup that is needed. For example, on a PPP link [RFC6361], you need to negotiate that you will be using TRILL. However, if you have Ethernet links [RFC6325], which are probably the most common type, there isn't any link setup needed. As soon as the port is set up, it can ingress or egress native frames if end-station service is being offered on that port. Offering end-station service is the default. However, if the port trunk bit (end-station service disable) is set or the port is configured as an IS-IS point-to-point link port, then end-station service is not offered; therefore, native frames received are ignored, and native frames are not egressed. TRILL IS-IS Hellos then get sent out the port to be exchanged with any other TRILL switches on the link [RFC7177]. Only the Hellos are required; optionally, you might also exchange MTU-probe/ack PDUs [RFC7177], BFD PDUs [RFC7175], or other link test packets. TRILL doesn't send any TRILL Data or TRILL IS-IS packets out the port to the link, except for Hellos, until the link gets to the 2-Way or Report state [RFC7177]. If a link is configured as a point-to-point link, there is no Designated RBridge (DRB) election. By default, an Ethernet link is considered a LAN link, and the DRB election occurs when the link is in any state other than Down. You don't have to configure priorities for each TRILL switch (RBridge) to be the DRB. Things will work fine with all the RBridges on a link using default priority. But if the network manager wants to control this, there should be a way for them to configure the priority to be the DRB of the TRILL switch ports on the link.
(To avoid complexity, this appendix generally describes the life cycle for a link that only has two TRILL switches on it. But TRILL works fine as currently specified on a broadcast link with multiple TRILL switches on it -- actually, multiple TRILL switch ports -- since a TRILL switch can have multiple ports connected to the same link. The most likely way to get such a multi-access link with current technology and the existing TRILL standards is to have more than two TRILL switch Ethernet ports connected to a bridged LAN. The TRILL protocol operates above all bridging; in general, the bridged LAN looks like a transparent broadcast link to TRILL.) When a link gets to the 2-Way or Report state, LSPs, CSNPs, and PSNPs will start to flow on the link (as well as FS-LSPs, FS-CSNPs, and FS-PSNPs for E-L1FS (see Section 8.1)). When a link gets to the Report state, there is adjacency. The existence of that adjacency is flooded (reported) to the campus in LSPs. TRILL Data packets can then start to flow on the link as TRILL switches recalculate the least-cost paths and distribution trees to take the new adjacency into account. Until it gets to the Report state, there is no adjacency, and no TRILL Data packets can flow over that link (with the minor corner case exception that an RBridge Channel message can, for its first hop only, be sent on a port where there is no adjacency (Section 2.4 of [RFC7178]). (Although this paragraph seems to be talking about link state, it is actually port state. It is possible for different TRILL switch ports on the same link to temporarily be in different states. The adjacency state machinery runs independently on each port.) ESADI [RFC7357] is built on top of the regular TRILL Data routing. Since ESADI PDUs look, to transit TRILL switches, like regular TRILL Data packets, no ESADI PDUs can flow until adjacencies are established and TRILL Data is flowing. Of course, ESADI is optional and is not used unless configured.
Question: Does it require TRILL Full Headers at the time TRILL LSPs start being broadcast on a link? Because at that time it's not defined egress and ingress nicknames. Answer: TRILL Headers are only for TRILL Data packets. TRILL IS-IS packets, such as TRILL LSPs, are sent in a different way that does not use a TRILL Header and does not depend on nicknames. Probably, in most implementations, a TRILL switch will start up using the same nickname it had when it shut down or last got disconnected from a campus. If you want, you can implement TRILL to come up initially not reporting any nickname (by not including a Nickname sub-TLV in its LSPs) until you get the link-state database or most of the link-state database, and then choose a nickname no other TRILL switch in the campus is using. Of course, if a TRILL switch does not have a nickname, then it cannot ingress data, cannot egress known unicast data, and cannot be a tree root. TRILL IS-IS PDUs such as LSPs, and the link-state database, all work based on the 7-byte IS-IS System ID (sometimes called the LAN ID [IS-IS]). Since topology determination uses System IDs, which are always unique across the campus, it is not affected by the nickname assignment state. The nickname system is built on top of that.
Appendix B. Example TRILL PDUs (New) This appendix shows example TRILL IS-IS PDUs. The primary purpose of these examples is to clarify issues related to bit ordering. The examples in this appendix concentrate on the format of the packet header and trailer. There are frequently unspecified optional items or data in the packet that would affect header or trailer fields like the packet length or checksum. Thus, an "Xed out" placeholder is used for such fields, where each X represents one hex nibble. B.1. LAN Hello over Ethernet A TRILL Hello sent from a TRILL switch (RBridge) with 7-byte System ID 0x30033003300300 holding nickname 0xFFDE over Ethernet from a port with MAC address 0x00005E0053DE on VLAN 1 at priority 7. There is one neighbor that is the DRB. The neighbor's port MAC is 0x00005E0053E3, and the neighbor's System ID is 0x44444444444400. Ethernet Header Outer.MacDA, Outer.MacSA 0x0180C2000041 All-IS-IS-RBridges Destination MAC Address 0x00005E0053DE Source MAC Address Outer VLAN Tag (optional) 0x8100 C-VLAN Ethertype [802.1Q-2014] 0xE001 Priority 7, Outer.VLAN IS-IS 0x22F4 L2-IS-IS Ethertype IS-IS Payload Common Header 0x83 Intradomain Routeing Protocol Discriminator 0x08 Header Length 0x01 IS-IS Version Number 0x06 ID Length of 6 Bytes 0x0F PDU Type (Level 1 LAN Hello) 0x01 Version 0x00 Reserved 0x01 Maximum Area Addresses Hello PDU Specific Fields 0x01 Circuit Type (Level 1) 0x30033003300300 Source System ID 0x0009 Holding Time 0xXXXX PDU Length 0x40 Priority to be DRB 0x44444444444400 LAN ID TLVs (the following order of TLVs or of sub-TLVs in a TLV is not significant)
Area Addresses TLV 0x01 Area Addresses Type 0x02 Length of Value 0x01 Length of Address 0x00 The fixed TRILL Area Address MT Port Capabilities TLV 0x8F MT Port Capabilities Type 0x0011 Length of Value 0x0000 Topology Special VLANs and Flags Sub-TLV 0x01 Sub-TLV Type 0x08 Length 0x0123 Port ID 0xFFDE Sender Nickname 0x0001 Outer.VLAN 0x0001 Designated VLAN Enabled VLANs Sub-TLV (optional) 0x02 Sub-TLV Type 0x03 Length 0x0001 Start VLAN 1 0x80 VLAN 1 TRILL Neighbor TLV 0x91 Neighbor Type 0x0A Length of Value 0xC0 S Flag = 1, L Flag = 1, SIZE field 0 NEIGHBOR RECORD 0x00 Flags 0x2328 MTU = 9 KB 0x00005E0053E3 Neighbor MAC Address Scope Flooding Support TLV 0xF3 Scope Flooding Support Type 0x01 Length of Value 0x40 E-L1FS Flooding Scope More TLVs (optional) ... Ethernet Trailer 0xXXXXXXXX Ethernet Frame Check Sequence (FCS)
B.2. LSP over PPP Here is an example of a TRILL LSP sent over a PPP link by the same source TRILL switch as the example in Appendix B.1. PPP Header 0x405D PPP TRILL Link State Protocol IS-IS Payload Common Header 0x83 Intradomain Routeing Protocol Discriminator 0x08 Header Length 0x01 IS-IS Version Number 0x06 ID Length of 6 Bytes 0x12 PDU Type (Level 1 LSP) 0x01 Version 0x00 Reserved 0x01 Maximum Area Addresses LSP Specific Fields 0xXXXX PDU Length 0x0123 Remaining Lifetime 0x3003300330030009 LSP ID (fragment 9) 0x00001234 Sequence Number 0xXXXX Checksum 0x01 Flags = Level 1 TLVs (the following order of TLVs or of sub-TLVs in a TLV is not significant) Router Capability TLV 0xF2 Router Capability Type 0x0F Length of Value 0x00 Flags Nickname Sub-TLV 0x06 Sub-TLV Type 0x05 Length of Value NICKNAME RECORD 0x33 Nickname Priority 0x1234 Tree Root Priority 0xFFDE Nickname TRILL Version Sub-TLV 0x0D Sub-TLV Type 0x05 0x00 Max Version 0x40000000 Flags = FGL Support More TLVs (optional ... PPP Trailer 0xXXXXXX PPP Frame Check Sequence (FCS)
B.3. TRILL Data over Ethernet Below is an IPv4 ICMP Echo [RFC792] sent in a TRILL Data packet from the TRILL switch that sent the Hello in Appendix B.1 to the neighbor TRILL switch on the link used in Appendix B.1. Ethernet Header Outer.MacDA, Outer.MacSA 0x00005E0053E3 Destination MAC Address 0x00005E0053DE Source MAC Address Outer VLAN Tag (optional) 0x8100 C-VLAN Ethertype [802.1Q-2014] 0x0001 Priority 0, Outer.VLAN 1 TRILL 0x22F3 TRILL Ethertype TRILL Header 0X000E Flags, Hop Count 14 0xFFDF Egress Nickname 0xFFDC Ingress Nickname Inner Ethernet Header Inner.MacDA, Inner.MacSA 0x00005E005322 Destination MAC Address 0x00005E005344 Source MAC Address Inner VLAN Tag 0x8100 C-VLAN Ethertype 0x0022 Priority 0, Inner.VLAN 34 Ethertype 0x0800 IPv4 Ethertype IP Header 0x4500 Version 4, Header Length 5, ToS 0 0xXXXX Total Length 0x3579 Identification 0x0000 Flags, Fragment Offset 0x1101 TTL 17, ICMP = Protocol 1 0xXXXX Header Checksum 0xC0000207 Source IP 192.0.2.7 0xC000020D Destination IP 192.0.2.13 0x00000000 Options, Padding ICMP 0x0800 ICMP Echo 0xXXXX Checksum 0x87654321 Identifier, Sequence Number ... Echo Data Ethernet Trailer 0xXXXXXXXX Ethernet Frame Check Sequence (FCS)
B.4. TRILL Data over PPP Below is an ARP Request [RFC826] sent in a TRILL Data packet from the TRILL switch that sent the Hello in Appendix B.1 over a PPP link. PPP Header 0x005D PPP TRILL Network Protocol TRILL Header 0X080D Flags (M = 1), Hop Count 13 0xFFDD Distribution Tree Root Nickname 0xFFDC Ingress Nickname Inner Ethernet Header Inner.MacDA, Inner.MacSA 0xFFFFFFFFFFFF Destination MAC Address 0x00005E005344 Source MAC Address Inner VLAN Tag 0x8100 C-VLAN Ethertype 0x0022 Priority 0, Inner.VLAN 34 Ethertype 0x0806 ARP Ethertype ARP 0x0001 Hardware Address Space = Ethernet 0x0001 Protocol Address Space = IPv4 0x06 Size of Hardware Address 0x04 Size of Protocol Address 0x0001 OpCode = Request 0x00005E005344 Sender Hardware Address 0xC0000207 Sender Protocol Address 192.0.2.7 0x000000000000 Target Hardware Address 0xC000020D Target Protocol Address 192.0.2.13 PPP Trailer 0xXXXXXX PPP Frame Check Sequence (FCS)
Appendix C. Changes to Previous RFCs (New) C.1. Changes to Obsoleted RFC 7180 This section summarizes the changes, augmentations, and excisions this document specifies for [RFC7180], which it obsoletes and replaces. C.1.1. Changes For each section header in this document ending with "(Changed)", this section summarizes the changes that are made by this document: Section 1 ("Introduction"): Numerous changes to reflect the overall changes in contents. Section 1.1 ("Precedence"): Changed to add mention of [RFC7179]. Section 1.3 ("Terminology and Acronyms"): Numerous terms added. Section 3 ("Distribution Trees and RPF Check"): Changed by the addition of the new material in Section 3.6. See Appendix C.1.2, Item 1. Section 8 ("Other IS-IS Considerations"): Changed by the addition of Sections 8.1, 8.2, 8.3, and 8.4. See Appendix C.1.2 -- Items 2, 3, 4, and 5, respectively. Section 9 ("Updates to RFC 7177 (Adjacency)": Changes and additions to [RFC7177] to support E-L1FS. See Appendix C.1.2, Item 2. Section 12 ("IANA Considerations"): Changed by the addition of material in Section 12.2. See Appendix C.1.2, Item 7. Section 13 ("Security Considerations"): Minor changes in the RFCs listed. C.1.2. Additions This document contains the following material not present in [RFC7180]: 1. Support for an alternative Reverse Path Forwarding Check (RPFC), along with considerations for deciding between the original [RFC6325] RPFC and this alternative RPFC. This alternative RPFC was originally discussed on the TRILL WG mailing list in <http://www.ietf.org/mail-archive/web/trill/current/ msg01852.html> and subsequent messages (Section 3.6).
2. Mandatory E-L1FS [RFC7356] support (Sections 8.1 and 9). 3. Recommendations concerning control packet priorities (Section 8.2). 4. Implementation requirements concerning unknown IS-IS PDU types (Section 8.3). 5. Specification of an optional Nickname Flags APPsub-TLV and an ingress flag within that APPsub-TLV (Section 8.4). 6. Update to the TRILL Header to allocate a Color bit (Section 10.1), and update to the optional TRILL Header Extension flags word to allocate a 2-bit Extended Color field (Section 10.2). 7. Some new IANA Considerations in Section 12.2, including reservation of nicknames for use as examples in documentation. 8. A new "Appointed Forwarder Status Lost Counter" section (Section 11 of this document) that loosens the mandatory update requirements specified in [RFC6325]. 9. Informative Appendix A on the life cycle of a TRILL port. 10. A new Appendix B containing example TRILL PDUs. 11. Recommendation to use the Purge Originator Identification TLV (Section 8.6). C.1.3. Deletions This document omits the following material that was present in [RFC7180]: 1. All updates to [RFC6327] that occurred in [RFC7180]. These have been rolled into [RFC7177], which obsoletes [RFC6327]. However, new updates to [RFC7177] are included (see Appendix C.3). 2. All updates to [RFC6439]. These have been rolled into [RFC6439bis], which is intended to obsolete [RFC6439].
C.2. Changes to RFC 6325 This document contains many normative updates to [RFC6325], some of which were also in [RFC7180], which this document replaces. These changes include the following: 1. Changing nickname allocation to ignore conflicts with RBridges that are IS-IS unreachable. 2. Fixing errors: [Err3002], [Err3003], [Err3004], [Err3052], [Err3053], and [Err3508]. 3. Changing the requirement to use the RPF check described in [RFC6325] for multi-destination TRILL Data packets by providing an alternative stronger RPF check. 4. Adoption of the change of the CFI bit, which was required to be zero in the inner frame, to the DEI bit, which is obtained from inner frame ingress or creation. 5. Requiring that all RBridges support E-L1FS FS-LSP flooding. 6. Reducing the variable-length TRILL Header extensions area to one optional flags word. The Extension Length field (called "Op-Length" in [RFC6325]) is reduced to 1 bit that indicates whether the flags word is present. The rest of that Length field is now reserved. 7. Changing the mandatory Appointed Forwarder Status Lost Counter increment provisions, as specified in Section 11. C.3. Changes to RFC 7177 All of the updates to [RFC7177] herein are in Section 9. Basically, this document requires that a Scope Flooding Support TLV [RFC7356] appear in all Hellos and that TRILL switches retain in their adjacency state the information received in that TLV. C.4. Changes to RFC 7179 The updates to [RFC7179] herein are in Sections 10.2 and 10.3.
Acknowledgments The contributions of the following individuals to this document are gratefully acknowledged: Santosh Rajagopalan and Gayle Noble The contributions of the following (listed in alphabetical order) to the preceding version of this document, [RFC7180], are gratefully acknowledged: Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia Perlman, Varun Shah, Mike Shand, and Meral Shirazipour. Authors' Addresses Donald Eastlake 3rd Huawei Technology 155 Beaver Street Milford, MA 01757 United States Phone: +1-508-333-2270 Email: email@example.com Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China Email: firstname.lastname@example.org Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States Email: email@example.com Ayan Banerjee Cisco Email: firstname.lastname@example.org
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 United States Email: email@example.com Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangalore 560048 India Email: firstname.lastname@example.org