draft-ietf-isis-te-app-11.txt   draft-ietf-isis-te-app-12.txt 
Networking Working Group L. Ginsberg Networking Working Group L. Ginsberg
Internet-Draft P. Psenak Internet-Draft P. Psenak
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: August 30, 2020 S. Previdi Expires: September 22, 2020 S. Previdi
Huawei Huawei
W. Henderickx W. Henderickx
Nokia Nokia
J. Drake J. Drake
Juniper Networks Juniper Networks
February 27, 2020 March 21, 2020
IS-IS TE Attributes per application IS-IS TE Attributes per application
draft-ietf-isis-te-app-11 draft-ietf-isis-te-app-12
Abstract Abstract
Existing traffic engineering related link attribute advertisements Existing traffic engineering related link attribute advertisements
have been defined and are used in RSVP-TE deployments. Since the have been defined and are used in RSVP-TE deployments. Since the
original RSVP-TE use case was defined, additional applications (e.g., original RSVP-TE use case was defined, additional applications (e.g.,
Segment Routing Traffic Engineering, Loop Free Alternate) have been Segment Routing Traffic Engineering, Loop Free Alternate) have been
defined which also make use of the link attribute advertisements. In defined which also make use of the link attribute advertisements. In
cases where multiple applications wish to make use of these link cases where multiple applications wish to make use of these link
attributes the current advertisements do not support application attributes the current advertisements do not support application
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 30, 2020. This Internet-Draft will expire on September 22, 2020.
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
skipping to change at page 2, line 52 skipping to change at page 2, line 52
5. Attribute Advertisements and Enablement . . . . . . . . . . . 11 5. Attribute Advertisements and Enablement . . . . . . . . . . . 11
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 12
6.1. Use of Legacy Advertisements . . . . . . . . . . . . . . 12 6.1. Use of Legacy Advertisements . . . . . . . . . . . . . . 12
6.2. Use of Zero Length Application Identifier Bit Masks . . . 13 6.2. Use of Zero Length Application Identifier Bit Masks . . . 13
6.3. Interoperability, Backwards Compatibility and Migration 6.3. Interoperability, Backwards Compatibility and Migration
Concerns . . . . . . . . . . . . . . . . . . . . . . . . 14 Concerns . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3.1. Multiple Applications: Common Attributes with RSVP- 6.3.1. Multiple Applications: Common Attributes with RSVP-
TE . . . . . . . . . . . . . . . . . . . . . . . . . 14 TE . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3.2. Multiple Applications: All Attributes Not Shared with 6.3.2. Multiple Applications: All Attributes Not Shared with
RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 14 RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 14
6.3.3. Interoperability with Legacy Routers . . . . . . . . 15 6.3.3. Interoperability with Legacy Routers . . . . . . . . 14
6.3.4. Use of Application Specific Advertisements for RSVP- 6.3.4. Use of Application Specific Advertisements for RSVP-
TE . . . . . . . . . . . . . . . . . . . . . . . . . 15 TE . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. Application Specific Link Attributes sub-TLV . . . . . . 15 7.1. Application Specific Link Attributes sub-TLV . . . . . . 16
7.2. Application Specific SRLG TLV . . . . . . . . . . . . . . 16 7.2. Application Specific SRLG TLV . . . . . . . . . . . . . . 16
7.3. Application Specific Link Attributes sub-sub-TLV Registry 16 7.3. Application Specific Link Attributes sub-sub-TLV Registry 16
7.4. Link Attribute Application Identifier Registry . . . . . 17 7.4. Link Attribute Application Identifier Registry . . . . . 17
7.5. SRLG sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 17 7.5. SRLG sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Advertisement of link attributes by the Intermediate-System-to- Advertisement of link attributes by the Intermediate-System-to-
Intermediate-System (IS-IS) protocol in support of traffic Intermediate-System (IS-IS) protocol in support of traffic
engineering (TE) was introduced by [RFC5305] and extended by engineering (TE) was introduced by [RFC5305] and extended by
[RFC5307], [RFC6119], and [RFC8570]. Use of these extensions has [RFC5307], [RFC6119], [RFC7308], and [RFC8570]. Use of these
been associated with deployments supporting Traffic Engineering over extensions has been associated with deployments supporting Traffic
Multiprotocol Label Switching (MPLS) in the presence of the Resource Engineering over Multiprotocol Label Switching (MPLS) in the presence
Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE of the Resource Reservation Protocol (RSVP) - more succinctly
[RFC3209]. referred to as RSVP-TE [RFC3209].
For the purposes of this document an application is a technology For the purposes of this document an application is a technology
which makes use of link attribute advertisements - examples of which which makes use of link attribute advertisements - examples of which
are listed in Section 3. are listed in Section 3.
In recent years new applications have been introduced which have use In recent years new applications have been introduced which have use
cases for many of the link attributes historically used by RSVP-TE. cases for many of the link attributes historically used by RSVP-TE.
Such applications include Segment Routing Traffic Engineering (SRTE) Such applications include Segment Routing Traffic Engineering (SRTE)
[I-D.ietf-spring-segment-routing-policy] and Loop Free Alternates [I-D.ietf-spring-segment-routing-policy] and Loop Free Alternates
(LFA) [RFC5286]. This has introduced ambiguity in that if a (LFA) [RFC5286]. This has introduced ambiguity in that if a
skipping to change at page 6, line 48 skipping to change at page 6, line 48
The encoding defined below is used by both the Application Specific The encoding defined below is used by both the Application Specific
Link Attributes sub-TLV and the Application Specific SRLG TLV. Link Attributes sub-TLV and the Application Specific SRLG TLV.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
| SABM Length + Flag | 1 octet | SABM Length + Flag | 1 octet
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
| UDABM Length + Flag | 1 octet | UDABM Length + Flag | 1 octet
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
| SABM ... 0 - 127 octets | SABM ... 0 - 8 octets
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
| UDABM ... 0 - 127 octets | UDABM ... 0 - 8 octets
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
SABM Length + Flag (1 octet) SABM Length + Flag (1 octet)
Standard Application Identifier Bit Mask Standard Application Identifier Bit Mask
Length + Flag Length + Flag
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|L| SABM Length | |L| SABM Length |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
L-flag: Legacy Flag. L-flag: Legacy Flag.
See the following section for a description of how See the following section for a description of how
this flag is used. this flag is used.
SABM Length: Indicates the length in octets (0-127) of the SABM Length: Indicates the length in octets (0-8) of the
Standard Application Identifier Bit Mask. The length SHOULD Standard Application Identifier Bit Mask. The length SHOULD
be the minimum required to send all bits which are set. be the minimum required to send all bits which are set.
UDABM Length + Flag (1 octet) UDABM Length + Flag (1 octet)
User Defined Application Identifier Bit Mask User Defined Application Identifier Bit Mask
Length + Flag Length + Flag
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|R| UDABM Length| |R| UDABM Length|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
R: Reserved. SHOULD be transmitted as 0 and R: Reserved. SHOULD be transmitted as 0 and
MUST be ignored on receipt MUST be ignored on receipt
UDABM Length: Indicates the length in octets (0-127) of the UDABM Length: Indicates the length in octets (0-8) of the
User Defined Application Identifier Bit Mask. The length SHOULD User Defined Application Identifier Bit Mask. The length SHOULD
be the minimum required to send all bits which are set. be the minimum required to send all bits which are set.
SABM (variable length) SABM (variable length)
Standard Application Identifier Bit Mask Standard Application Identifier Bit Mask
(SABM Length * 8) bits (SABM Length * 8) bits
This field is omitted if SABM Length is 0. This field is omitted if SABM Length is 0.
skipping to change at page 8, line 25 skipping to change at page 8, line 25
(UDABM Length * 8) bits (UDABM Length * 8) bits
0 1 2 3 4 5 6 7 ... 0 1 2 3 4 5 6 7 ...
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
| ... | ...
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
This field is omitted if UDABM Length is 0. This field is omitted if UDABM Length is 0.
NOTE: SABM/UDABM Length is arbitrarily limited to 8 octets in order
to insure that sufficient space is left to advertise link attributes
without overrunning the maximum length of a sub-TLV.
Standard Application Identifier Bits are defined/sent starting with Standard Application Identifier Bits are defined/sent starting with
Bit 0. Undefined bits MUST be transmitted as 0 and MUST be ignored Bit 0. Undefined bits MUST be transmitted as 0 and MUST be ignored
on receipt. Bits that are NOT transmitted MUST be treated as if they on receipt. Bits that are NOT transmitted MUST be treated as if they
are set to 0 on receipt. Bits that are not supported by an are set to 0 on receipt. Bits that are not supported by an
implementation MUST be ignored on receipt. implementation MUST be ignored on receipt.
User Defined Application Identifier Bits have no relationship to User Defined Application Identifier Bits have no relationship to
Standard Application Identifier Bits and are NOT managed by IANA or Standard Application Identifier Bits and are NOT managed by IANA or
any other standards body. It is recommended that bits are used any other standards body. It is recommended that bits are used
starting with Bit 0 so as to minimize the number of octets required starting with Bit 0 so as to minimize the number of octets required
skipping to change at page 8, line 51 skipping to change at page 9, line 13
attribute values. attribute values.
Type: 16 (temporarily assigned by IANA) Type: 16 (temporarily assigned by IANA)
Length: Variable (1 octet) Length: Variable (1 octet)
Value: Value:
Application Identifier Bit Mask Application Identifier Bit Mask
(as defined in Section 4.1) (as defined in Section 4.1)
Link Attribute sub-sub-TLVs - format matches the Link Attribute sub-sub-TLVs - format matches the
existing formats defined in [RFC5305] and [RFC8570] existing formats defined in [RFC5305], [RFC7308],
and [RFC8570]
When the L-flag is set in the Application Identifier Bit Mask, all of When the L-flag is set in the Application Identifier Bit Mask, all of
the applications specified in the bit mask MUST use the legacy the applications specified in the bit mask MUST use the legacy
advertisements for the corresponding link found in TLVs 22, 23, 25, advertisements for the corresponding link found in TLVs 22, 23, 25,
141, 222, and 223 or TLV 138 or TLV 139 as appropriate. Link 141, 222, and 223 or TLV 138 or TLV 139 as appropriate. Link
attribute sub-sub-TLVs for the corresponding link attributes MUST NOT attribute sub-sub-TLVs for the corresponding link attributes MUST NOT
be advertised for the set of applications specified in the Standard/ be advertised for the set of applications specified in the Standard/
User Application Identifier Bit Masks and all such advertisements User Application Identifier Bit Masks and all such advertisements
MUST be ignored on receipt. MUST be ignored on receipt.
skipping to change at page 14, line 20 skipping to change at page 14, line 20
advertisements and are likely to infer that RSVP-TE is enabled on the advertisements and are likely to infer that RSVP-TE is enabled on the
links for which legacy advertisements exist. It is expected that links for which legacy advertisements exist. It is expected that
deployments using the legacy advertisements will persist for a deployments using the legacy advertisements will persist for a
significant period of time. Therefore deployments using the significant period of time. Therefore deployments using the
extensions defined in this document must be able to co-exist with use extensions defined in this document must be able to co-exist with use
of the legacy advertisements by routers which do not support the of the legacy advertisements by routers which do not support the
extensions defined in this document. The following sub-sections extensions defined in this document. The following sub-sections
discuss interoperability and backwards compatibility concerns for a discuss interoperability and backwards compatibility concerns for a
number of deployment scenarios. number of deployment scenarios.
Note that in all cases the defined strategy can be employed on a per
link basis.
6.3.1. Multiple Applications: Common Attributes with RSVP-TE 6.3.1. Multiple Applications: Common Attributes with RSVP-TE
In cases where multiple applications are utilizing a given link, one In cases where multiple applications are utilizing a given link, one
of the applications is RSVP-TE, and all link attributes for a given of the applications is RSVP-TE, and all link attributes for a given
link are common to the set of applications utilizing that link, link are common to the set of applications utilizing that link,
interoperability is achieved by using legacy advertisements and interoperability is achieved by using legacy advertisements and
sending application specific advertisements with L-flag set and no sending application specific advertisements with L-flag set and no
link attribute values. This avoids duplication of link attribute link attribute values. This avoids duplication of link attribute
advertisements. advertisements.
skipping to change at page 15, line 12 skipping to change at page 15, line 4
is using some link attribute advertisements on the link but some link is using some link attribute advertisements on the link but some link
attributes cannot be shared with RSVP-TE. attributes cannot be shared with RSVP-TE.
6.3.3. Interoperability with Legacy Routers 6.3.3. Interoperability with Legacy Routers
For the applications defined in this document, routers which do not For the applications defined in this document, routers which do not
support the extensions defined in this document will send and receive support the extensions defined in this document will send and receive
only legacy link attribute advertisements. So long as there is any only legacy link attribute advertisements. So long as there is any
legacy router in the network which has any of the applications legacy router in the network which has any of the applications
enabled, all routers MUST continue to advertise link attributes using enabled, all routers MUST continue to advertise link attributes using
legacy advertisements. Once all legacy routers have been upgraded, legacy advertisements. In addition, the link attribute values
migration from legacy advertisements to application specific associated with the set of applications supported by legacy routers
advertisements can be achieved via the following steps: (RSVP-TE, SRTE, and/or LFA) are always shared since legacy routers
have no way of advertising or processing application specific values.
Once all legacy routers have been upgraded, migration from legacy
advertisements to application specific advertisements can be achieved
via the following steps:
1)Send application specific advertisements while continuing to 1)Send application specific advertisements while continuing to
advertise using legacy (all advertisements are then duplicated). advertise using legacy (all advertisements are then duplicated).
Receiving routers continue to use legacy advertisements. Receiving routers continue to use legacy advertisements.
2)Enable the use of the application specific advertisements on all 2)Enable the use of the application specific advertisements on all
routers routers
3)Remove legacy advertisements 3)Remove legacy advertisements
When the migration is complete, it then becomes possible to advertise
incongruent values per application on a given link.
Note that the use of the L-flag is of no value in the migration.
Documents defining new applications which make use of the application
specific advertisements defined in this document MUST discuss
interoperability and backwards compatibility issues that could occur
in the presence of routers which do not support the new application.
6.3.4. Use of Application Specific Advertisements for RSVP-TE 6.3.4. Use of Application Specific Advertisements for RSVP-TE
The extensions defined in this document support RSVP-TE as one of the The extensions defined in this document support RSVP-TE as one of the
supported applications. This allows that RSVP-TE could eventually supported applications. This allows that RSVP-TE could eventually
utilize the application specific advertisements. This can be done in utilize the application specific advertisements. This can be done in
the following step-wise manner: the following step-wise manner:
1)Upgrade all routers to support the extensions in this document 1)Upgrade all routers to support the extensions in this document
2)Advertise all legacy link attributes using application specific 2)Advertise all legacy link attributes using application specific
skipping to change at page 16, line 30 skipping to change at page 17, line 5
7.3. Application Specific Link Attributes sub-sub-TLV Registry 7.3. Application Specific Link Attributes sub-sub-TLV Registry
This document requests a new IANA registry under the IS-IS TLV This document requests a new IANA registry under the IS-IS TLV
Codepoints Registry be created to control the assignment of sub-sub- Codepoints Registry be created to control the assignment of sub-sub-
TLV codepoints for the Application Specific Link Attributes sub-TLV TLV codepoints for the Application Specific Link Attributes sub-TLV
defined in Section 7.1. The suggested name of the new registry is defined in Section 7.1. The suggested name of the new registry is
"sub-sub-TLV code points for application specific link attributes". "sub-sub-TLV code points for application specific link attributes".
The registration procedure is "Expert Review" as defined in The registration procedure is "Expert Review" as defined in
[RFC8126]. The following assignments are made by this document: [RFC8126]. The following assignments are made by this document:
Type Description Type Description Encoding
Reference
--------------------------------------------------------- ---------------------------------------------------------
0-2 Unassigned 0-2 Unassigned
3 Administrative group (color) 3 Administrative group (color) RFC5305
4-8 Unassigned 4-8 Unassigned
9 Maximum link bandwidth 9 Maximum link bandwidth RFC5305
10 Maximum reservable link bandwidth 10 Maximum reservable link bandwidth RFC5305
11 Unreserved bandwidth 11 Unreserved bandwidth RFC5305
12-13 Unassigned 12-13 Unassigned
14 Extended Administrative Group 14 Extended Administrative Group RFC7308
15-17 Unassigned 15-17 Unassigned
18 TE Default Metric 18 TE Default Metric RFC5305
19-32 Unassigned 19-32 Unassigned
33 Unidirectional Link Delay 33 Unidirectional Link Delay RFC8570
34 Min/Max Unidirectional Link Delay 34 Min/Max Unidirectional Link Delay RFC8570
35 Unidirectional Delay Variation 35 Unidirectional Delay Variation RFC8570
36 Unidirectional Link Loss 36 Unidirectional Link Loss RFC8570
37 Unidirectional Residual Bandwidth 37 Unidirectional Residual Bandwidth RFC8570
38 Unidirectional Available Bandwidth 38 Unidirectional Available Bandwidth RFC8570
39 Unidirectional Utilized Bandwidth 39 Unidirectional Utilized Bandwidth RFC8570
40-255 Unassigned 40-255 Unassigned
Note to IANA: For future codepoints, in cases where the document
which defines the encoding is different from the document which
assigns the codepoint, the encoding reference MUST be to the document
which defines the encoding.
Note to designated experts: If a link attribute can be advertised Note to designated experts: If a link attribute can be advertised
both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a sub- both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a sub-
sub-TLV of the Application Specific Link Attributes sub-TLV defined sub-TLV of the Application Specific Link Attributes sub-TLV defined
in this document, then the same numerical code should be assigned to in this document, then the same numerical code should be assigned to
the link attribute whenever possible. the link attribute whenever possible.
7.4. Link Attribute Application Identifier Registry 7.4. Link Attribute Application Identifier Registry
This document requests a new IANA registry be created, under the This document requests a new IANA registry be created, under the
category of "Interior Gateway Protocol (IGP) Parameters", to control category of "Interior Gateway Protocol (IGP) Parameters", to control
the assignment of Application Identifier Bits. The suggested name of the assignment of Application Identifier Bits. The suggested name of
the new registry is "Link Attribute Applications". The registration the new registry is "Link Attribute Applications". The registration
policy for this registry is "Standards Action" ([RFC8126] and policy for this registry is "Standards Action" [RFC8126]. Bit
[RFC7120]). Bit definitions SHOULD be assigned in ascending bit definitions SHOULD be assigned in ascending bit order beginning with
order beginning with Bit 0 so as to minimize the number of octets Bit 0 so as to minimize the number of octets that will need to be
that will need to be transmitted. The following assignments are made transmitted. The following assignments are made by this document:
by this document:
Bit # Name Bit # Name
--------------------------------------------------------- ---------------------------------------------------------
0 RSVP-TE (R-bit) 0 RSVP-TE (R-bit)
1 Segment Routing Traffic Engineering (S-bit) 1 Segment Routing Traffic Engineering (S-bit)
2 Loop Free Alternate (F-bit) 2 Loop Free Alternate (F-bit)
Additional bits are undefined 3-63 Unassigned
7.5. SRLG sub-TLVs 7.5. SRLG sub-TLVs
This document requests a new IANA registry be created to control the This document requests a new IANA registry be created under the IS-IS
assignment of sub-TLV types for the application specific SRLG TLV. TLV Codepoints Registry to control the assignment of sub-TLV types
The suggested name of the new registry is "Sub-TLVs for TLV 238". for the application specific SRLG TLV. The suggested name of the new
The registration procedure is "Expert Review" as defined in registry is "Sub-TLVs for TLV 238". The registration procedure is
[RFC8126]. The following assignments are made by this document: "Expert Review" as defined in [RFC8126]. The following assignments
are made by this document:
Value Description Encoding Value Description Encoding
Reference Reference
--------------------------------------------------------- ---------------------------------------------------------
0-3 Unassigned 0-3 Unassigned
4 Link Local/Remote Identifiers [RFC5307] 4 Link Local/Remote Identifiers [RFC5307]
5 Unassigned 5 Unassigned
6 IPv4 interface address [RFC5305] 6 IPv4 interface address [RFC5305]
7 Unassigned 7 Unassigned
8 IPv4 neighbor address [RFC5305] 8 IPv4 neighbor address [RFC5305]
9-11 Unassigned 9-11 Unassigned
12 IPv6 Interface Address [RFC6119] 12 IPv6 Interface Address [RFC6119]
13 IPv6 Neighbor Address [RFC6119] 13 IPv6 Neighbor Address [RFC6119]
14-255 Unassigned 14-255 Unassigned
Note to IANA: For future codepoints, in cases where the document
which defines the encoding is different from the document which
assigns the codepoint, the encoding reference MUST be to the document
which defines the encoding.
8. Security Considerations 8. Security Considerations
Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], Security concerns for IS-IS are addressed in [ISO10589], [RFC5304],
and [RFC5310]. and [RFC5310].
This document defines a new way to advertise link attributes. This document defines a new way to advertise link attributes.
Tampering with the information defined in this document may have an Tampering with the information defined in this document may have an
effect on applications using it, including impacting Traffic effect on applications using it, including impacting Traffic
Engineering. This is similar in nature to the impacts associated Engineering. This is similar in nature to the impacts associated
with (for example) [RFC5305]. with (for example) [RFC5305]. As the advertisements defined in this
document limit the scope to specific applications, the impact of
tampering is similarly limited in scope.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Eric Rosen and Acee Lindem for their The authors would like to thank Eric Rosen and Acee Lindem for their
careful review and content suggestions. careful review and content suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 19, line 14 skipping to change at page 19, line 49
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>. 2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <https://www.rfc-editor.org/info/rfc6119>. February 2011, <https://www.rfc-editor.org/info/rfc6119>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January Traffic Engineering (MPLS-TE)", RFC 7308,
2014, <https://www.rfc-editor.org/info/rfc7120>. DOI 10.17487/RFC7308, July 2014,
<https://www.rfc-editor.org/info/rfc7308>.
[RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints [RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints
Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014,
<https://www.rfc-editor.org/info/rfc7370>. <https://www.rfc-editor.org/info/rfc7370>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
 End of changes. 31 change blocks. 
56 lines changed or deleted 87 lines changed or added

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