diff options
Diffstat (limited to 'doc/rfc/rfc8249.txt')
| -rw-r--r-- | doc/rfc/rfc8249.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc8249.txt b/doc/rfc/rfc8249.txt new file mode 100644 index 0000000..932c579 --- /dev/null +++ b/doc/rfc/rfc8249.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Zhang +Request for Comments: 8249 X. Zhang +Updates: 6325, 7177, 7780 D. Eastlake 3rd +Category: Standards Track Huawei +ISSN: 2070-1721 R. Perlman + Dell EMC + S. Chatterjee + Cisco + September 2017 + + + Transparent Interconnection of Lots of Links (TRILL): + MTU Negotiation + +Abstract + + The base IETF TRILL (Transparent Interconnection of Lots of Links) + protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325 + and 7177, that assures that link-state changes can be successfully + flooded throughout the campus while being able to take advantage of a + campus-wide capability to support jumbo packets. This document + specifies recommended updates to that MTU feature to take advantage, + for appropriate link-local packets, of link-local MTUs that exceed + the TRILL campus MTU. In addition, it specifies an efficient + algorithm for local MTU testing. This document updates RFCs 6325, + 7177, and 7780. + +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 + https://www.rfc-editor.org/info/rfc8249. + + + + + + + + + + + +Zhang, et al. Standards Track [Page 1] + +RFC 8249 MTU Negotiation September 2017 + + +Copyright Notice + + Copyright (c) 2017 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 + (https://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. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................3 + 2. Link-Wide TRILL MTU Size ........................................4 + 2.1. Operations .................................................5 + 3. Testing Link MTU Size ...........................................6 + 4. Refreshing Sz ...................................................8 + 5. Relationship between Port MTU, Lz, and Sz .......................9 + 6. LSP Synchronization ............................................10 + 7. Recommendations for Traffic Link Testing of MTU Size ...........10 + 8. Backward Compatibility .........................................11 + 9. Security Considerations ........................................11 + 10. Additions to Configuration ....................................12 + 10.1. Per-RBridge Configuration ................................12 + 10.2. Per-RBridge Port Configuration ...........................12 + 11. IANA Considerations ...........................................12 + 12. References ....................................................12 + 12.1. Normative References .....................................12 + 12.2. Informative References ...................................14 + Acknowledgements ..................................................14 + Authors' Addresses ................................................14 + + + + + + + + + + + + + + +Zhang, et al. Standards Track [Page 2] + +RFC 8249 MTU Negotiation September 2017 + + +1. Introduction + + [RFC6325] describes the way RBridges agree on the campus-wide minimum + acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called + "Sz") to ensure that link-state flooding operates properly and all + RBridges converge to the same link state. For the proper operation + of TRILL (Transparent Interconnection of Lots of Links) IS-IS, all + RBridges format their Link State Protocol Data Units (LSPs) to fit + in Sz. + + [RFC7177] diagrams the state transitions of an adjacency. If MTU + testing is enabled, "Link MTU size is successfully tested" is part of + an event (event A6) causing the transition from the "2-Way" state + [RFC7177] to the "Report" state for an adjacency. This means that + the link MTU testing of size x succeeds, and x is greater than or + equal to Sz [RFC6325]. If this link cannot support an MTU of Sz, it + will not be reported as part of the campus topology. + + In this document, a new RECOMMENDED link-wide minimum inter-RBridge + MTU size, "Lz", is specified. As further discussed in Section 2, by + calculating and using Lz as specified herein, link-scoped Protocol + Data Units (PDUs) can be formatted greater than Sz, up to the + link-wide minimum acceptable inter-RBridge MTU size, potentially + improving the efficiency of link utilization and speeding link-state + convergence. + + An optional TRILL MTU size-testing algorithm is specified in + Section 3 as an efficient method to update the old MTU testing method + described in Section 4.3.2 of [RFC6325] and in [RFC7177]. The new + MTU size-testing method specified in this document is backward + compatible with the old one. Multicasting the MTU-probes is + recommended when there are multiple RBridges on a link responding to + the probing with an MTU-ack [RFC7177]. The testing method and rules + of this document are devised in a way that minimizes the number of + MTU-probes for testing, therefore reducing the number of multicast + packets for MTU testing. + + This document updates RFCs 6325, 7177, and 7780. The update to + [RFC6325] and [RFC7177] is specified in Section 3. The update to + [RFC7780] is specified in Section 4. + +1.1. Conventions Used in This Document + + 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 + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + + +Zhang, et al. Standards Track [Page 3] + +RFC 8249 MTU Negotiation September 2017 + + +2. Link-Wide TRILL MTU Size + + This document specifies a new value "Lz" for the minimum acceptable + inter-RBridge link MTU size on a local link. Link-wide Lz is the + minimum Lz supported and agreed upon amongst all RBridges on a + specific link. If the link is usable, Lz will be greater than or + equal to Sz. + + Some TRILL IS-IS PDUs are exchanged only between neighbors instead of + throughout the whole campus. They are confined by the link-wide Lz + instead of Sz. Complete Sequence Number PDUs (CSNPs) and Partial + Sequence Number PDUs (PSNPs) are examples of such PDUs. These PDUs + are exchanged only on the local link. (While TRILL IS-IS Hellos are + also link local, they are always limited to 1470 bytes for + robustness.) + + [RFC7356] defines the PDUs that support flooding scopes in addition + to area-wide scopes and domain-wide scopes. As specified in + [RFC8139], RBridges support the Extended L1 Circuit Scope (E-L1CS) + Flooding Scope LSP (FS-LSP) [RFC7780]. The originatingSNPBufferSize + for a port is the minimum of the following two quantities but + not less than 1470 bytes: (1) the MTU of the port and (2) the maximum + LSP size that the TRILL IS-IS implementation can handle. They use + that flooding to exchange their maximum supported value of "Lz". The + smallest value of the Lz advertised by the RBridges on a link, but + not less than Sz, is the link-wide Lz. An RBridge on a local link + will be able to tell which other RBridges on that link support E-L1CS + FS-LSPs because, as required by [RFC7780], all RBridges include the + Scope Flooding Support TLV [RFC7356] in their TRILL Hellos. + + The maximum size for a level-1 link-local PDU (such as a PSNP or + CSNP) that may be generated by a system is controlled by the value of + the management parameter originatingL1SNPBufferSize. This value + determines Lz. The TRILL APPsub-TLV shown in Figure 1 SHOULD be + included in a TRILL GENINFO TLV [RFC7357] in an E-L1CS FS-LSP + fragment zero. If it is missing from an E-L1CS FS-LSP fragment zero + or there is no E-L1CS FS-LSP fragment zero, it is assumed that its + originating IS is implicitly advertising its originatingSNPBufferSize + value as Sz octets. + + E-L1CS FS-LSPs are link local and can also be sent up to a size of Lz + but, for robustness, E-L1CS FS-LSP fragment zero MUST NOT exceed + 1470 bytes. + + + + + + + + +Zhang, et al. Standards Track [Page 4] + +RFC 8249 MTU Negotiation September 2017 + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 21 | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length = 2 | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | originatingSNPBufferSize | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: The originatingSNPBufferSize APPsub-TLV + + Type: Set to the originatingSNPBufferSize APPsub-TLV (TRILL + APPsub-TLV type 21). Two bytes, because this APPsub-TLV appears + in an extended TLV [RFC7356]. + + Length: Set to 2. + + originatingSNPBufferSize: The local value of + originatingL1SNPBufferSize as an unsigned integer, limited to the + range from 1470 to 65,535 bytes. (A value less than 1470 will be + ignored.) + +2.1. Operations + + Lz MAY be reported using an originatingSNPBufferSize APPsub-TLV that + occurs in fragment zero of the RBridge's E-L1CS FS-LSP. An + originatingSNPBufferSize APPsub-TLV occurring in any other fragment + is ignored. If more than one originatingSNPBufferSize APPsub-TLV + occurs in fragment zero, the one advertising the smallest value for + originatingSNPBufferSize, but not less than 1470 bytes, is used. + + Even if all RBridges on a specific link have reached consensus on the + value of link-wide Lz based on advertised originatingSNPBufferSize, + it does not mean that these RBridges can safely exchange PDUs between + each other. Figure 2 shows such a corner case. RB1, RB2, and RB3 + are three RBridges on the same link and their Lz is 1800, so the + link-wide Lz of this link is 1800. There is an intermediate bridge + (say B1) between RB2 and RB3 whose port MTU size is 1700. If RB2 + sends PDUs formatted in chunks of size 1800, those PDUs will be + discarded by B1. + + + + + + + + + + + + +Zhang, et al. Standards Track [Page 5] + +RFC 8249 MTU Negotiation September 2017 + + + Lz:1800 Lz:1800 + +---+ | +---+ + |RB1|(2000)---|---(2000)|RB2| + +---+ | +---+ + | + Lz:1800 | + +---+ +--+ + |RB3|(2000)---(1700)|B1| + +---+ +--+ + | + + Figure 2: Link-Wide Lz = 1800 vs. Tested Link MTU Size = 1700 + + Therefore, the link MTU size SHOULD be tested. After the link MTU + size of an adjacency is successfully tested, those link-local PDUs, + such as CSNPs, PSNPs, and E-L1CS FS-LSPs, will be formatted + no greater than the tested link MTU size and will be safely + transmitted on this link. + + As for Sz, RBridges continue to propagate their + originatingL1LSPBufferSize across the campus through the + advertisement of LSPs as defined in Section 4.3.2 of [RFC6325]. The + smallest value of Sz advertised by any RBridge, but not less than + 1470, will be deemed as Sz. Each RBridge formats their "campus-wide" + PDUs -- for example, LSPs -- no greater than what they determine + as Sz. + +3. Testing Link MTU Size + + [RFC7177] defines event A6 as indicating that the MTU test was + successful if MTU testing is enabled. As described in Section 4.3.2 + of [RFC6325], this is a combination of the following event and + condition: + + o Event: The link MTU size has been tested. + + o Condition: The link can support Sz. + + This condition can be efficiently tested by the following "binary + search algorithm" and rules. This updates [RFC6325] and [RFC7177]. + + x, lowerBound, and upperBound are local integer variables. The + MTU-probe and MTU-ack PDUs are specified in Section 3 of [RFC7176]. + It is RECOMMENDED that one Round-Trip Time (RTT) between the two + adjacent RBridges be used as the minimum interval between two + successive probes. Note that RTT estimation is out of scope for this + document. If operators cannot estimate the RTT, the default value of + 5 milliseconds should be assumed. + + + +Zhang, et al. Standards Track [Page 6] + +RFC 8249 MTU Negotiation September 2017 + + + Step 0: RB1 sends an MTU-probe padded to the size of link-wide Lz. + + 1) If RB1 successfully receives the MTU-ack from RB2 to the probe + of the value of link-wide Lz within k tries (where k is a + configurable parameter whose default is 3), the link MTU size + is set to the size of link-wide Lz. Stop. + + 2) RB1 tries to send an MTU-probe padded to 1470 bytes. + + a) If RB1 fails to receive an MTU-ack from RB2 after k tries + (an MTU-ack should be considered to have failed two RTTs + after the probe is sent out), RB1 sets the "failed minimum + MTU test" flag for RB2 in RB1's Hello. Stop. + + b) The link MTU size is set to 1470; lowerBound is set to 1470; + upperBound is set to the link-wide Lz; x is set to + [(lowerBound + upperBound) / 2], rounded down to the nearest + integer. + + Step 1: RB1 tries to send an MTU-probe padded to the size x. + + 1) If RB1 fails to receive an MTU-ack from RB2 after k tries: + + upperBound is set to x - 1; x is set to + [(lowerBound + upperBound) / 2], rounded down to the nearest + integer. + + 2) If RB1 receives an MTU-ack to a probe of size x from RB2: + + The link MTU size is set to x; lowerBound is set to x; x is set + to [(lowerBound + upperBound) / 2], rounded down to the nearest + integer. If lowerBound equals upperBound - 1, then x is set to + upperBound. + + 3) If lowerBound >= upperBound or Step 1 has been repeated n times + (where n is a configurable parameter whose default value is 5), + stop. + + 4) Repeat Step 1. + + After the testing, the two connected RBridges agree on the value of + the link MTU size. MTU testing is only done in the Designated VLAN + [RFC7177]. Since the execution of the above algorithm can be + resource consuming, it is RECOMMENDED that the Designated RBridge + (DRB) [RFC7177] take the responsibility to do the testing. Multicast + MTU-probes are used instead of unicast when multiple RBridges are + + + + + +Zhang, et al. Standards Track [Page 7] + +RFC 8249 MTU Negotiation September 2017 + + + desired to respond with an MTU-ack on the link. The binary search + algorithm given here is a way to minimize the probing attempts; it + reduces the number of multicast packets for MTU-probing. + + The following rules are designed to determine whether the + aforementioned "Condition" holds. + + RBridges have figured out the upper bound and lower bound of the link + MTU size from the execution of the above algorithm. If Sz is smaller + than the lower bound or greater than the upper bound, RBridges can + directly judge whether the link supports Sz without MTU-probing. + + (a) If lowerBound >= Sz, this link can support Sz. + + (b) Else if upperBound <= Sz, this link cannot support Sz. + + Otherwise, RBridges SHOULD test whether the link can support Sz as in + item (c) below. If they do not, the only safe assumption will be + that the link cannot support Sz. This assumption, without testing, + might rule out the use of a link that can, in fact, handle packets up + to Sz. In the worst case, this might result in unnecessary network + partition. + + (c) lowerBound < Sz < upperBound. RBridges probe the link with + MTU-probe messages padded to Sz. If an MTU-ack is received + within k tries, this link can support Sz. Otherwise, this link + cannot support Sz. Through this test, the lower bound and upper + bound of the link MTU size can be updated accordingly. + +4. Refreshing Sz + + RBridges may join or leave the campus; this may change Sz. + + 1) Joining + + a) When a new RBridge joins the campus and its + originatingL1LSPBufferSize is smaller than the current Sz, + reporting its originatingL1LSPBufferSize in its LSPs will cause + other RBridges to decrease their Sz. Then, any LSP greater + than the reduced Sz MUST be split, and/or the LSP contents in + the campus MUST be otherwise redistributed so that no LSP is + greater than the new Sz. + + b) If the joining RBridge's originatingL1LSPBufferSize is greater + than or equal to the current Sz, reporting its + originatingL1LSPBufferSize will not change Sz. + + + + + +Zhang, et al. Standards Track [Page 8] + +RFC 8249 MTU Negotiation September 2017 + + + 2) Leaving + + a) From the specification of the Joining process, we know that if + an RBridge's originatingL1LSPBufferSize is smaller than Sz, + this RBridge will not join this campus. + + b) When an RBridge leaves the campus and its + originatingL1LSPBufferSize equals Sz, its LSPs are purged from + the remainder of the campus after reaching MaxAge [IS-IS]. Sz + MAY be recalculated and MAY increase. In other words, while in + most cases RB1 ignores link-state information for IS-IS + unreachable RBridge RB2 [RFC7780], originatingL1LSPBufferSize + is meaningful. Its value, even from IS-IS unreachable + RBridges, is used in determining Sz. This updates [RFC7780]. + + c) When an RBridge leaves the campus and its + originatingL1LSPBufferSize is greater than Sz, Sz will not be + updated, since Sz is determined by another RBridge with a + smaller originatingL1LSPBufferSize. + + Frequent LSP "resizing" is harmful to the stability of the TRILL + campus, so, to avoid this, upward resizing SHOULD be dampened. When + an upward resizing event is noticed by an RBridge, it is RECOMMENDED + that a timer be set at that RBridge via a configurable parameter -- + LSPresizeTime -- whose default value is 300 seconds. Before this + timer expires, all subsequent upward resizing will be dampened + (ignored). Of course, in a well-configured campus with all RBridges + configured to have the same originatingL1LSPBufferSize, no resizing + will be necessary. It does not matter if different RBridges have + different dampening timers or if some RBridges resize upward more + quickly than others. + + If the refreshed Sz is smaller than the lower bound or greater than + the upper bound of the tested link MTU size, the issue of resource + consumption from testing the link MTU size can be avoided according + to rule (a) or (b) as specified in Section 3. Otherwise, RBridges + test the link MTU size according to rule (c). + +5. Relationship between Port MTU, Lz, and Sz + + When the port MTU of an RBridge is smaller than the local + originatingL1SNPBufferSize of an RBridge (an inconsistent + configuration), that port SHOULD be disabled, since, in any case, an + adjacency cannot be formed through such a port. On the other hand, + when an RBridge receives an LSP or E-L1CS FS-LSP with size greater + than the link-wide Lz or Sz but not greater than its port MTU size, + this LSP is processed normally. If the size of an LSP is greater + + + + +Zhang, et al. Standards Track [Page 9] + +RFC 8249 MTU Negotiation September 2017 + + + than the MTU size of a port over which it is to be propagated, this + LSP MUST NOT be sent over the port and an LSPTooLargeToPropagate + alarm shall be generated [IS-IS]. + +6. LSP Synchronization + + An RBridge participates in LSP synchronization on a link as soon as + it has at least one adjacency on that link that has advanced to at + least the 2-Way state [RFC7177]. On a LAN link, CSNPs and PSNPs are + used for synchronization. On a point-to-point link, only PSNPs are + used. + + The CSNPs and PSNPs can be formatted in chunks of size (at most) + link-wide Lz but are processed normally if received having a larger + size. Since the link MTU size may not have been tested in the 2-Way + state, link-wide Lz may be greater than the supported link MTU size. + In that case, a CSNP or PSNP may be discarded. After the link MTU + size is successfully tested, RBridges will begin to format these PDUs + with a size no greater than that MTU; therefore, these PDUs will + eventually get through. + + Note that the link MTU size is frequently greater than Sz. + Link-local PDUs are limited in size by the link MTU size rather than + Sz, which, when Lz is greater than Sz, promises a reduction in the + number of PDUs and a faster LSP synchronization process. + +7. Recommendations for Traffic Link Testing of MTU Size + + Sz and link-wide Lz are used to limit the size of most TRILL IS-IS + PDUs. They are different from the MTU size restricting the size of + TRILL Data packets. The size of a TRILL Data packet is restricted by + the physical MTU of the ports and links the packet traverses. It is + possible that a TRILL Data packet successfully gets through the + campus but its size is greater than Sz or link-wide Lz values. + + The algorithm defined for testing the link MTU size can also be used + in TRILL traffic MTU size testing; in that case, the link-wide Lz + used in that algorithm is replaced by the port MTU of the RBridge + sending MTU-probes. The successfully tested size x MAY be advertised + as an attribute of this link, using the MTU sub-TLV defined in + [RFC7176]. + + Unlike RBridges, end stations do not participate in the exchange of + TRILL IS-IS PDUs; therefore, they cannot grasp the traffic link MTU + size from a TRILL campus automatically. An operator may collect + these values using network management tools such as TRILL ping or + TraceRoute. Then, the path MTU can be set as the smallest tested + + + + +Zhang, et al. Standards Track [Page 10] + +RFC 8249 MTU Negotiation September 2017 + + + link MTU on this path, and end stations should not generate frames + that -- when encapsulated as TRILL Data packets -- exceed this + path MTU. + +8. Backward Compatibility + + There can be a mixture of Lz-ignorant and Lz-aware RBridges on a + link. This configuration will behave properly, although it may + not be as efficient as it would be if all RBridges on the link are + Lz aware. + + For an Lz-ignorant RBridge, TRILL IS-IS PDUs are always formatted + no greater than Sz. Lz-aware RBridges as receivers can handle these + PDUs, since they cannot be greater than the link-wide Lz. + + For an Lz-aware RBridge, in the case that link-wide Lz is greater + than Sz, larger link-local TRILL IS-IS PDUs can be sent out to + increase efficiency. Lz-ignorant RBridges as receivers will have + no problem handling them, since the originatingL1LSPBufferSize value + of these RBridges had been tested and the link-wide Lz is not greater + than that value. + + An Lz-ignorant RBridge might not support the link MTU size-testing + algorithm defined in Section 3 but could be using some algorithm just + to test for the Sz MTU on the link. In any case, if an RBridge per + [RFC6325] receives an MTU-probe, it MUST respond with an MTU-ack + padded to the same size as the MTU-probe. + +9. Security Considerations + + This document raises no significant new security issues for TRILL. + In TRILL, RBridges are generally considered to be trusted devices. + Protection against forged TRILL IS-IS PDUs, including forged Hellos + containing originatingSNPBufferSize APPsub-TLVs, can be obtained + through IS-IS PDU cryptographic authentication [RFC5310]. The worst + that an RBridge can do by reporting an erroneous + originatingSNPBufferSize is reduce Lz to Sz and thus make unavailable + the optimization of being able to use link MTUs that exceed the + campus-wide MTU for link-local TRILL IS-IS PDUs. + + For general and adjacency-related TRILL security considerations, see + [RFC6325] and [RFC7177]. + + + + + + + + + +Zhang, et al. Standards Track [Page 11] + +RFC 8249 MTU Negotiation September 2017 + + +10. Additions to Configuration + + Implementation of the features specified in this document adds two + RBridge configuration parameters, as follows: + +10.1. Per-RBridge Configuration + + Each RBridge implementing the RECOMMENDED LSP resizing damping + strategy specified in Section 4 has an LSPresizeTime parameter that + is an integer in the range of 0-65,535 and that defaults to 300. It + is the number of seconds for which an RBridge determines that Sz has + increased before it will create any LSP or E-L1FS FS-LSP fragments. + +10.2. Per-RBridge Port Configuration + + Each RBridge port on which the calculation and use of Lz are + implemented has an originatingL1SNPBufferSize parameter that is an + integer in the range of 1470-65,535. This parameter defaults to the + minimum of the size that the port can accommodate and the link-local + IS-IS PDU size that the TRILL implementation can accommodate. + +11. IANA Considerations + + IANA has assigned a new APPsub-TLV type for the TRILL + originatingSNPBufferSize APPsub-TLV defined in Section 2 of this + document. This new type has been assigned from the range less than + 256 in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application + Identifier 1" registry. The entry is as follows: + + Type Name Reference + ---- ------------------------ --------- + 21 originatingSNPBufferSize RFC 8249 + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://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, <https://www.rfc-editor.org/info/rfc5310>. + + + + + +Zhang, et al. Standards Track [Page 12] + +RFC 8249 MTU Negotiation September 2017 + + + [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, + <https://www.rfc-editor.org/info/rfc6325>. + + [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, + <https://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, <https://www.rfc-editor.org/info/rfc7177>. + + [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding + Scope Link State PDUs (LSPs)", RFC 7356, + DOI 10.17487/RFC7356, September 2014, + <https://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, <https://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, + <https://www.rfc-editor.org/info/rfc7780>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in + RFC 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + <https://www.rfc-editor.org/info/rfc8174>. + + + + + + + + + + + + + + +Zhang, et al. Standards Track [Page 13] + +RFC 8249 MTU Negotiation September 2017 + + +12.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. + + [RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. + Hu, "Transparent Interconnection of Lots of Links (TRILL): + Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139, + June 2017, <https://www.rfc-editor.org/info/rfc8139>. + +Acknowledgements + + The authors would like to thank Vishwas Manral for his comments and + suggestions. + +Authors' Addresses + + Mingui Zhang + Huawei Technologies + No. 156 Beiqing Rd. Haidian District + Beijing 100095 + China + + Phone: +86-13810702575 + Email: zhangmingui@huawei.com + + + Xudong Zhang + Huawei Technologies + No. 156 Beiqing Rd. Haidian District + Beijing 100095 + China + + Email: zhangxudong@huawei.com + + + + + + + + + + + +Zhang, et al. Standards Track [Page 14] + +RFC 8249 MTU Negotiation September 2017 + + + Donald Eastlake 3rd + Huawei Technologies + 155 Beaver Street + Milford, MA 01757 + United States of America + + Phone: +1-508-333-2270 + Email: d3e3e3@gmail.com + + + Radia Perlman + Dell EMC + 505 1st Ave South + Seattle, WA 98104 + United States of America + + Email: radia@alum.mit.edu + + + Somnath Chatterjee + Cisco Systems + SEZ Unit, Cessna Business Park + Outer Ring Road + Bangalore 560087 + India + + Email: somnath.chatterjee01@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + +Zhang, et al. Standards Track [Page 15] + |