draft-ietf-lsr-isis-invalid-tlv-03.txt   rfc8918.txt 
LSR Working Group L. Ginsberg Internet Engineering Task Force (IETF) L. Ginsberg
Internet-Draft P. Wells Request for Comments: 8918 P. Wells
Updates: 5305 6232 (if approved) Cisco Systems Updates: 5305, 6232 Cisco Systems
Intended status: Standards Track T. Li Category: Standards Track T. Li
Expires: January 27, 2021 Arista Networks ISSN: 2070-1721 Arista Networks
T. Przygienda T. Przygienda
S. Hegde S. Hegde
Juniper Networks, Inc. Juniper Networks, Inc.
July 26, 2020 September 2020
Invalid TLV Handling in IS-IS Invalid TLV Handling in IS-IS
draft-ietf-lsr-isis-invalid-tlv-03
Abstract Abstract
Key to the extensibility of the Intermediate System to Intermediate The key to the extensibility of the Intermediate System to
System (IS-IS) protocol has been the handling of unsupported and/or Intermediate System (IS-IS) protocol has been the handling of
invalid Type/Length/Value (TLV) tuples. Although there are explicit unsupported and/or invalid Type-Length-Value (TLV) tuples. Although
statements in existing specifications, deployment experience has there are explicit statements in existing specifications, deployment
shown that there are inconsistencies in the behavior when a TLV which experience has shown that there are inconsistencies in the behavior
is disallowed in a particular Protocol Data Unit (PDU) is received. when a TLV that is disallowed in a particular Protocol Data Unit
(PDU) is received.
This document discusses such cases and makes the correct behavior This document discusses such cases and makes the correct behavior
explicit in order to ensure that interoperability is maximized. explicit in order to ensure that interoperability is maximized.
This document updates RFC5305 and RFC6232. This document updates RFCs 5305 and 6232.
Requirements Language
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on January 27, 2021. 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/rfc8918.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. TLV Codepoints Registry . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
3. TLV Acceptance in PDUs . . . . . . . . . . . . . . . . . . . 4 2. TLV Codepoints Registry
3.1. Handling of Disallowed TLVs in Received PDUs other than 3. TLV Acceptance in PDUs
LSP Purges . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Handling of Disallowed TLVs in Received PDUs Other Than LSP
3.2. Special Handling of Disallowed TLVs in Received LSP Purges
Purges . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Special Handling of Disallowed TLVs in Received LSP Purges
3.3. Applicability to sub-TLVs . . . . . . . . . . . . . . . . 5 3.3. Applicability to Sub-TLVs
3.4. Correction to POI TLV Registry Entry . . . . . . . . . . 5 3.4. Correction to POI "TLV Codepoints Registry" Entry
4. TLV Validation and LSP Acceptance . . . . . . . . . . . . . . 6 4. TLV Validation and LSP Acceptance
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses
1. Introduction 1. Introduction
The Intermediate System to Intermediate System (IS-IS) protocol The Intermediate System to Intermediate System (IS-IS) protocol
[ISO10589] utilizes Type/Length/Value (TLV) encoding for all content [ISO10589] utilizes Type-Length-Value (TLV) encoding for all content
in the body of Protocol Data Units (PDUs). New extensions to the in the body of Protocol Data Units (PDUs). New extensions to the
protocol are supported by defining new TLVs. In order to allow protocol are supported by defining new TLVs. In order to allow
protocol extensions to be deployed in a backwards compatible way an protocol extensions to be deployed in a backwards compatible way, an
implementation is required to ignore TLVs that it does not implementation is required to ignore TLVs that it does not
understand. This behavior is also applied to sub-TLVs [RFC5305], understand. This behavior is also applied to sub-TLVs [RFC5305],
which are contained within TLVs. which are contained within TLVs.
Also essential to the correct operation of the protocol is having the Also essential to the correct operation of the protocol is having the
validation of PDUs be independent from the validation of the TLVs validation of PDUs be independent from the validation of the TLVs
contained in the PDU. PDUs which are valid must be accepted contained in the PDU. PDUs that are valid must be accepted
[ISO10589] even if an individual TLV contained within that PDU is not [ISO10589] even if an individual TLV contained within that PDU is not
understood or is invalid in some way (e.g., incorrect syntax, data understood or is invalid in some way (e.g., incorrect syntax, data
value out of range, etc.). value out of range, etc.).
The set of TLVs (and sub-TLVs) which are allowed in each PDU type is The set of TLVs (and sub-TLVs) that are allowed in each PDU type is
documented in the TLV Codepoints Registry established by [RFC3563] documented in the "TLV Codepoints Registry" established by [RFC3563]
and updated by [RFC6233] and [RFC7356]. and updated by [RFC6233] and [RFC7356].
This document is intended to clarify some aspects of existing This document is intended to clarify some aspects of existing
specifications and thereby reduce the occurrence of non-conformant specifications and, thereby, reduce the occurrence of non-conformant
behavior seen in real world deployments. Although behaviors behavior seen in real-world deployments. Although behaviors
specified in existing protocol specifications are not changed, the specified in existing protocol specifications are not changed, the
clarifications contained in this document serve as updates to RFC clarifications contained in this document serve as updates to
5305 (see Section 3.3) and RFC 6232 (see Section 3.4). [RFC5305] (see Section 3.3) and [RFC6232] (see Section 3.4).
1.1. Requirements Language
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.
2. TLV Codepoints Registry 2. TLV Codepoints Registry
[RFC3563] established the IANA-managed IS-IS TLV Codepoints Registry [RFC3563] established the IANA-managed "IS-IS TLV Codepoints
for recording assigned TLV code points [TLV_CODEPOINTS]. The initial Registry" for recording assigned TLV codepoints [TLV_CODEPOINTS].
contents of this registry were based on [RFC3359]. The initial contents of this registry were based on [RFC3359].
The registry includes a set of columns indicating in which PDU types The registry includes a set of columns indicating in which PDU types
a given TLV is allowed: a given TLV is allowed:
IIH - TLV is allowed in Intermediate System to Intermediate System IIH TLV is allowed in Intermediate System to Intermediate System
Hello (IIH) PDUs (Point-to-point and LAN) Hello (IIH) PDUs (Point-to-point and LAN)
LSP - TLV is allowed in Link State PDUs (LSP) LSP TLV is allowed in Link State PDUs (LSPs)
SNP - TLV is allowed in Sequence Number PDUs (SNP) (Partial Sequence SNP TLV is allowed in Sequence Number PDUs (SNPs) (Partial
Number PDUs (PSNP) and Complete Sequence Number PDUS (CSNP)) Sequence Number PDUs (PSNPs) and Complete Sequence Number
PDUs (CSNPs))
Purge - TLV is allowed in LSP Purges [RFC6233] Purge TLV is allowed in LSP Purges [RFC6233]
If "Y" is entered in a column it means the TLV is allowed in the If "Y" is entered in a column, it means the TLV is allowed in the
corresponding PDU type. corresponding PDU type.
If "N" is entered in a column it means the TLV is not allowed in the If "N" is entered in a column, it means the TLV is not allowed in the
corresponding PDU type. corresponding PDU type.
3. TLV Acceptance in PDUs 3. TLV Acceptance in PDUs
This section describes the correct behavior when a PDU is received This section describes the correct behavior when a PDU that contains
which contains a TLV which is specified as disallowed in the TLV a TLV that is specified as disallowed in the "TLV Codepoints
Codepoints Registry. Registry" is received.
3.1. Handling of Disallowed TLVs in Received PDUs other than LSP Purges 3.1. Handling of Disallowed TLVs in Received PDUs Other Than LSP Purges
[ISO10589] defines the behavior required when a PDU is received [ISO10589] defines the behavior required when a PDU is received
containing a TLV which is "not recognised". It states (see Sections containing a TLV that is "not recognised". It states (see Sections
9.5 - 9.13): 9.5 - 9.13):
"Any codes in a received PDU that are not | Any codes in a received PDU that are not recognised shall be
recognised shall be ignored." | ignored.
This is the model to be followed when a TLV is received which is This is the model to be followed when a TLV that is disallowed is
disallowed. Therefore TLVs in a PDU (other than LSP purges) which received. Therefore, TLVs in a PDU (other than LSP purges) that are
are disallowed MUST be ignored and MUST NOT cause the PDU itself to disallowed MUST be ignored and MUST NOT cause the PDU itself to be
be rejected by the receiving IS. rejected by the receiving IS.
3.2. Special Handling of Disallowed TLVs in Received LSP Purges 3.2. Special Handling of Disallowed TLVs in Received LSP Purges
When purging LSPs, [ISO10589] recommends (but does not require) the When purging LSPs, [ISO10589] recommends (but does not require) the
body of the LSP (i.e., all TLVs) be removed before generating the body of the LSP (i.e., all TLVs) be removed before generating the
purge. LSP purges which have TLVs in the body are accepted though purge. LSP purges that have TLVs in the body are accepted, though
any TLVs which are present are ignored. any TLVs that are present are ignored.
When cryptographic authentication [RFC5304] was introduced, this When cryptographic authentication [RFC5304] was introduced, this
looseness when processing received purges had to be addressed in looseness when processing received purges had to be addressed in
order to prevent attackers from being able to initiate a purge order to prevent attackers from being able to initiate a purge
without having access to the authentication key. [RFC5304] therefore without having access to the authentication key. Therefore,
imposed strict requirements on what TLVs were allowed in a purge [RFC5304] imposed strict requirements on what TLVs were allowed in a
(authentication only) and specified that: purge (authentication only) and specified that:
"ISes MUST NOT accept purges that contain TLVs | ISes MUST NOT accept purges that contain TLVs other than the
other than the authentication TLV". | authentication TLV.
This behavior was extended by [RFC6232] which introduced the Purge This behavior was extended by [RFC6232], which introduced the Purge
Originator Identification (POI) TLV and [RFC6233] which added the Originator Identification (POI) TLV, and [RFC6233], which added the
"Purge" column to the TLV Codepoints registry to identify all the "Purge" column to the "TLV Codepoints Registry" to identify all the
TLVs which are allowed in purges. TLVs that are allowed in purges.
The behavior specified in [RFC5304] is not backwards compatible with The behavior specified in [RFC5304] is not backwards compatible with
the behavior defined by [ISO10589] and therefore can only be safely the behavior defined by [ISO10589]; therefore, it can only be safely
enabled when all nodes support cryptographic authentication. enabled when all nodes support cryptographic authentication.
Similarly, the extensions defined by [RFC6232] are not compatible Similarly, the extensions defined by [RFC6232] are not compatible
with the behavior defined in [RFC5304], therefore can only be safely with the behavior defined in [RFC5304]; therefore, they can only be
enabled when all nodes support the extensions. safely enabled when all nodes support the extensions.
When new protocol behaviors are specified that are not backwards When new protocol behaviors are specified that are not backwards
compatible, it is RECOMMENDED that implementations provide controls compatible, it is RECOMMENDED that implementations provide controls
for their enablement. This serves to prevent interoperability issues for their enablement. This serves to prevent interoperability issues
and allow for non-disruptive introduction of the new functionality and allow for non-disruptive introduction of the new functionality
into an existing network. into an existing network.
3.3. Applicability to sub-TLVs 3.3. Applicability to Sub-TLVs
[RFC5305] introduced sub-TLVs, which are TLV tuples advertised within [RFC5305] introduced sub-TLVs, which are TLV tuples advertised within
the body of a parent TLV. Registries associated with sub-TLVs are the body of a parent TLV. Registries associated with sub-TLVs are
associated with the TLV Codepoints Registry and specify in which TLVs associated with the "TLV Codepoints Registry" and specify in which
a given sub-TLV is allowed. Section 2 of [RFC5305] is updated by the TLVs a given sub-TLV is allowed. Section 2 of [RFC5305] is updated
following sentence: by the following sentence:
"As with TLVs, it is required that sub-TLVs which | As with TLVs, it is required that sub-TLVs that are disallowed
are disallowed MUST be ignored on receipt.". | MUST be ignored on receipt.
The existing sentence in Section 2 of [RFC5305] : The existing sentence in Section 2 of [RFC5305]:
"Unknown sub-TLVs are to be ignored and skipped upon | Unknown sub-TLVs are to be ignored and skipped upon receipt.
receipt."
is replaced by: is replaced by:
"Unknown sub-TLVs MUST be ignored and skipped upon | Unknown sub-TLVs MUST be ignored and skipped upon receipt.
receipt."
3.4. Correction to POI TLV Registry Entry 3.4. Correction to POI "TLV Codepoints Registry" Entry
An error was introduced by [RFC6232] when specifying in which PDUs An error was introduced by [RFC6232] when specifying in which PDUs
the POI TLV is allowed. Section 3 of [RFC6232] stated: the POI TLV is allowed. Section 3 of [RFC6232] states:
"The POI TLV SHOULD be found in all purges and | The POI TLV SHOULD be found in all purges and MUST NOT be found in
MUST NOT be found in LSPs with a non-zero | LSPs with a non-zero Remaining Lifetime.
Remaining Lifetime."
However, the IANA section of the same document stated: However, the IANA section of the same document states:
"The additional values for this TLV should be | The additional values for this TLV should be IIH:n, LSP:y, SNP:n,
IIH:n, LSP:y, SNP:n, and Purge:y." | and Purge:y.
The correct setting for "LSP" is "n". This document updates The correct setting for "LSP" is "n". This document updates
[RFC6232] by correcting that error. [RFC6232] by correcting that error.
This document also updates the previously quoted text from Section 3 This document also updates the previously quoted text from Section 3
of [RFC6232] to be: of [RFC6232] to be:
"The POI TLV SHOULD be sent in all purges and | The POI TLV SHOULD be sent in all purges and MUST NOT be sent in
MUST NOT be sent in LSPs with a non-zero | LSPs with a non-zero Remaining Lifetime.
Remaining Lifetime."
4. TLV Validation and LSP Acceptance 4. TLV Validation and LSP Acceptance
The correct format of a TLV and its associated sub-TLVs, if The correct format of a TLV and its associated sub-TLVs, if
applicable, are defined in the document(s) which introduce each applicable, is defined in the document(s) that introduces each
codepoint. The definition MUST include what action to take when the codepoint. The definition MUST include what action to take when the
format/content of the TLV does not conform to the specification format/content of the TLV does not conform to the specification
(e.g., "MUST be ignored on receipt"). When making use of the (e.g., "MUST be ignored on receipt"). When making use of the
information encoded in a given TLV (or sub-TLV) receiving nodes MUST information encoded in a given TLV (or sub-TLV), receiving nodes MUST
verify that the TLV conforms to the standard definition. This verify that the TLV conforms to the standard definition. This
includes cases where the length of a TLV/sub-TLV is incorrect and/or includes cases where the length of a TLV/sub-TLV is incorrect and/or
cases where the value field does not conform to the defined cases where the value field does not conform to the defined
restrictions. restrictions.
However, the unit of flooding for the IS-IS Update process is an LSP. However, the unit of flooding for the IS-IS Update process is an LSP.
The presence of a TLV (or sub-TLV) with content which does not The presence of a TLV (or sub-TLV) with content that does not conform
conform to the relevant specification MUST NOT cause the LSP itself to the relevant specification MUST NOT cause the LSP itself to be
to be rejected. Failure to follow this requirement will result in rejected. Failure to follow this requirement will result in
inconsistent LSP Databases on different nodes in the network which inconsistent LSP Databases on different nodes in the network that
will compromise the correct operation of the protocol. will compromise the correct operation of the protocol.
LSP Acceptance rules are specified in [ISO10589] . Acceptance rules LSP Acceptance rules are specified in [ISO10589]. Acceptance rules
for LSP purges are extended by [RFC5304] and [RFC5310] and are for LSP purges are extended by [RFC5304] and [RFC5310] and are
further extended by [RFC6233]. further extended by [RFC6233].
[ISO10589] also specifies the behavior when an LSP is not accepted. [ISO10589] also specifies the behavior when an LSP is not accepted.
This behavior is NOT altered by extensions to the LSP Acceptance This behavior is _not_ altered by extensions to the LSP Acceptance
rules i.e., regardless of the reason for the rejection of an LSP the rules, i.e., regardless of the reason for the rejection of an LSP,
Update process on the receiving router takes the same action. the Update process on the receiving router takes the same action.
5. IANA Considerations 5. IANA Considerations
IANA is requested to add this document as a reference for the TLV IANA has added this document as a reference for the "TLV Codepoints
Codepoints Registry. Registry".
IANA is also requested to modify the entry for the Purge Originator
Identification TLV in the TLV Codepoints Registry to be:
IIH:n, LSP:n, SNP:n, and Purge:y. IANA has also modified the entry for the Purge Originator
Identification TLV in the "TLV Codepoints Registry" to be IIH:n,
LSP:n, SNP:n, and Purge:y.
The reference field should be updated to point to this document. The reference field of the Purge Originator Identification TLV has
been updated to point to this document.
6. Security Considerations 6. Security Considerations
As this document makes no changes to the protocol there are no new As this document makes no changes to the protocol, there are no new
security issues introduced. security issues introduced.
The clarifications discussed in this document are intended to make it The clarifications discussed in this document are intended to make it
less likely that implementations will incorrectly process received less likely that implementations will incorrectly process received
LSPs, thereby also making it less likely that a bad actor could LSPs, thereby also making it less likely that a bad actor could
exploit a faulty implementation. exploit a faulty implementation.
Security concerns for IS-IS are discussed in [ISO10589], [RFC5304], Security concerns for IS-IS are discussed in [ISO10589], [RFC5304],
and [RFC5310]. and [RFC5310].
7. Acknowledgements 7. References
The authors would like to thank Alvaro Retana.
8. References
8.1. Normative References 7.1. Normative References
[ISO10589] [ISO10589] International Organization for Standardization,
International Organization for Standardization, "Information technology -- Telecommunications and
"Intermediate system to Intermediate system intra-domain information exchange between systems -- Intermediate
routeing information exchange protocol for use in System to Intermediate System intra-domain routeing
conjunction with the protocol for providing the information exchange protocol for use in conjunction with
connectionless-mode Network Service (ISO 8473)", ISO/ the protocol for providing the connectionless-mode network
IEC 10589:2002, Second Edition, Nov 2002. service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
November 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF
and ISO/IEC Joint Technical Committee 1/Sub Committee 6 and ISO/IEC Joint Technical Committee 1/Sub Committee 6
(JTC1/SC6) on IS-IS Routing Protocol Development", (JTC1/SC6) on IS-IS Routing Protocol Development",
RFC 3563, DOI 10.17487/RFC3563, July 2003, RFC 3563, DOI 10.17487/RFC3563, July 2003,
skipping to change at page 8, line 24 skipping to change at line 342
[RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for
Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011, Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011,
<https://www.rfc-editor.org/info/rfc6233>. <https://www.rfc-editor.org/info/rfc6233>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TLV_CODEPOINTS] [TLV_CODEPOINTS]
IANA, "IS-IS TLV Codepoints web page IANA, "IS-IS TLV Codepoints",
(https://www.iana.org/assignments/isis-tlv-codepoints/ <https://www.iana.org/assignments/isis-tlv-codepoints/>.
isis-tlv-codepoints.xhtml)".
8.2. Informative References 7.2. Informative References
[RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) [RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV)
Codepoints in Intermediate System to Intermediate System", Codepoints in Intermediate System to Intermediate System",
RFC 3359, DOI 10.17487/RFC3359, August 2002, RFC 3359, DOI 10.17487/RFC3359, August 2002,
<https://www.rfc-editor.org/info/rfc3359>. <https://www.rfc-editor.org/info/rfc3359>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356, Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014, DOI 10.17487/RFC7356, September 2014,
<https://www.rfc-editor.org/info/rfc7356>. <https://www.rfc-editor.org/info/rfc7356>.
Acknowledgements
The authors would like to thank Alvaro Retana.
Authors' Addresses Authors' Addresses
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
Paul Wells Paul Wells
Cisco Systems Cisco Systems
skipping to change at page 9, line 4 skipping to change at line 372
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
Paul Wells Paul Wells
Cisco Systems Cisco Systems
Email: pauwells@cisco.com Email: pauwells@cisco.com
Tony Li Tony Li
Arista Networks Arista Networks
5453 Great America Parkway 5453 Great America Parkway
Santa Clara, California 95054 Santa Clara, CA 95054
USA United States of America
Email: tony.li@tony.li Email: tony.li@tony.li
Tony Przygienda Tony Przygienda
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Matilda Ave 1194 N. Matilda Ave
Sunnyvale, California 94089 Sunnyvale, CA 94089
USA United States of America
Email: prz@juniper.net Email: prz@juniper.net
Shraddha Hegde Shraddha Hegde
Juniper Networks, Inc. Juniper Networks, Inc.
Embassy Business Park Embassy Business Park
Bangalore, KA 560093 Bangalore 560093
KA
India India
Email: shraddha@juniper.net Email: shraddha@juniper.net
 End of changes. 64 change blocks. 
158 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/