RFC 7780
Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
Pages: 57
Proposed Standard
Obsoletes: 7180
Updates: 6325 7177 7179
Updated by: 8249
Proposed Standard
Obsoletes: 7180
Updates: 6325 7177 7179
Updated by: 8249
Part 3 of 3 – Pages 37 to 57
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 778012.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 778012.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 778012.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 Unassigned13. 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
[802] 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: d3e3e3@gmail.com Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China Email: zhangmingui@huawei.com Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States Email: radia@alum.mit.edu Ayan Banerjee Cisco Email: ayabaner@cisco.com
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 United States Email: anoop@alumni.duke.edu Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangalore 560048 India Email: sujay.gupta@ipinfusion.com