draft-ietf-isis-te-app-06.txt | draft-ietf-isis-te-app-07.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: October 10, 2019 S. Previdi | Expires: April 6, 2020 S. Previdi | |||
Huawei | Huawei | |||
W. Henderickx | W. Henderickx | |||
Nokia | Nokia | |||
J. Drake | J. Drake | |||
Juniper Networks | Juniper Networks | |||
April 8, 2019 | October 4, 2019 | |||
IS-IS TE Attributes per application | IS-IS TE Attributes per application | |||
draft-ietf-isis-te-app-06.txt | draft-ietf-isis-te-app-07 | |||
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. In cases | have been defined and are used in RSVP-TE deployments. Since the | |||
where multiple applications wish to make use of these link attributes | original RSVP-TE use case was defined, additional applications (e.g., | |||
the current advertisements do not support application specific values | SRTE, LFA) have been defined which also make use of the link | |||
for a given attribute nor do they support indication of which | attribute advertisements. In cases where multiple applications wish | |||
applications are using the advertised value for a given link. | to make use of these link attributes the current advertisements do | |||
not support application specific values for a given attribute nor do | ||||
they support indication of which applications are using the | ||||
advertised value for a given link. | ||||
This draft introduces new link attribute advertisements which address | This draft introduces new link attribute advertisements which address | |||
both of these shortcomings. It also discusses backwards | both of these shortcomings. It also discusses backwards | |||
compatibility issues and how to minimize duplicate advertisements in | compatibility issues and how to minimize duplicate advertisements in | |||
the presence of routers which do not support the extensions defined | the presence of routers which do not support the extensions defined | |||
in this document. | in this document. | |||
Requirements Language | Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
skipping to change at page 2, line 10 ¶ | skipping to change at page 2, line 12 ¶ | |||
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 October 10, 2019. | This Internet-Draft will expire on April 6, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 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 48 ¶ | skipping to change at page 2, line 50 ¶ | |||
4.2.2. Special Considerations for Unreserved Bandwidth . . . 9 | 4.2.2. Special Considerations for Unreserved Bandwidth . . . 9 | |||
4.3. Application Specific SRLG TLV . . . . . . . . . . . . . . 9 | 4.3. Application Specific SRLG TLV . . . . . . . . . . . . . . 9 | |||
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 | 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 | |||
6. Attribute Advertisements and Enablement . . . . . . . . . . . 11 | 6. Attribute Advertisements and Enablement . . . . . . . . . . . 11 | |||
7. Interoperability, Backwards Compatibility and Migration | 7. Interoperability, Backwards Compatibility and Migration | |||
Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
7.1. RSVP-TE only deployments . . . . . . . . . . . . . . . . 12 | 7.1. RSVP-TE only deployments . . . . . . . . . . . . . . . . 12 | |||
7.2. Multiple Applications: Common Attributes with RSVP-TE . 12 | 7.2. Multiple Applications: Common Attributes with RSVP-TE . 12 | |||
7.3. Multiple Applications: All Attributes Not Shared w RSVP- | 7.3. Multiple Applications: All Attributes Not Shared w RSVP- | |||
TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
7.4. Deprecating legacy advertisements . . . . . . . . . . . . 13 | 7.4. Use of Application Specific Advertisements for RSVP-TE . 13 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 16 | 11.2. Informative References . . . . . . . . . . . . . . . . . 16 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
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], and [RFC8570]. Use of these extensions has | |||
been associated with deployments supporting Traffic Engineering over | been associated with deployments supporting Traffic Engineering over | |||
Multiprotocol Label Switching (MPLS) in the presence of Resource | Multiprotocol Label Switching (MPLS) in the presence of Resource | |||
Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE. | Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE. | |||
skipping to change at page 4, line 35 ¶ | skipping to change at page 4, line 37 ¶ | |||
advertisements or introducing new backwards compatibility issues. | advertisements or introducing new backwards compatibility issues. | |||
Finally, there may still be many cases where a single attribute value | Finally, there may still be many cases where a single attribute value | |||
can be shared among multiple applications, so the solution must | can be shared among multiple applications, so the solution must | |||
minimize advertising duplicate link/attribute pairs whenever | minimize advertising duplicate link/attribute pairs whenever | |||
possible. | possible. | |||
3. Legacy Advertisements | 3. Legacy Advertisements | |||
There are existing advertisements used in support of RSVP-TE. These | There are existing advertisements used in support of RSVP-TE. These | |||
advertisements include sub-TLVs for TLVs 22, 23, 141, 222, and 223 | advertisements include sub-TLVs for TLVs 22, 23, 25, 141, 222, and | |||
and TLVs for SRLG advertisement. | 223 and TLVs for SRLG advertisement. | |||
3.1. Legacy sub-TLVs | 3.1. Legacy sub-TLVs | |||
Sub-TLVs for TLVs 22, 23, 141, 222, and 223 | Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 | |||
Code Point/Attribute Name | Code Point/Attribute Name | |||
-------------------------- | -------------------------- | |||
3 Administrative group (color) | 3 Administrative group (color) | |||
9 Maximum link bandwidth | 9 Maximum link bandwidth | |||
10 Maximum reservable link bandwidth | 10 Maximum reservable link bandwidth | |||
11 Unreserved bandwidth | 11 Unreserved bandwidth | |||
14 Extended Administrative Group | 14 Extended Administrative Group | |||
18 TE Default Metric | 18 TE Default Metric | |||
33 Unidirectional Link Delay | 33 Unidirectional Link Delay | |||
skipping to change at page 5, line 39 ¶ | skipping to change at page 5, line 39 ¶ | |||
Supports links identified by IPv6 addresses | Supports links identified by IPv6 addresses | |||
Note that [RFC6119] prohibits the use of TLV 139 when it is possible | Note that [RFC6119] prohibits the use of TLV 139 when it is possible | |||
to use TLV 138. | to use TLV 138. | |||
4. Advertising Application Specific Link Attributes | 4. Advertising Application Specific Link Attributes | |||
Two new code points are defined in support of Application Specific | Two new code points are defined in support of Application Specific | |||
Link Attribute Advertisements: | Link Attribute Advertisements: | |||
1) Application Specific Link Attributes sub-TLV for TLVs 22, 23, 141, | 1) Application Specific Link Attributes sub-TLV for TLVs 22, 23, 25, | |||
222, and 223 | 141, 222, and 223 (defined in Section 4.2 ). | |||
2)Application Specific Shared Risk Link Group (SRLG) TLV | 2)Application Specific Shared Risk Link Group (SRLG) TLV (defined in | |||
Section 4.3). | ||||
In support of these new advertisements, an application bit mask is | In support of these new advertisements, an application identifier bit | |||
defined which identifies the application(s) associated with a given | mask is defined which identifies the application(s) associated with a | |||
advertisement. | given advertisement (defined in Section 4.1). | |||
The following sections define the format of these new advertisements. | The following sections define the format of these new advertisements. | |||
4.1. Application Identifier Bit Mask | 4.1. Application Identifier Bit Mask | |||
Identification of the set of applications associated with link | Identification of the set of applications associated with link | |||
attribute advertisements utilizes two bit masks. One bit mask is for | attribute advertisements utilizes two bit masks. One bit mask is for | |||
standard applications where the definition of each bit is defined in | standard applications where the definition of each bit is defined in | |||
a new IANA controlled registry. A second bit mask is for non- | a new IANA controlled registry. A second bit mask is for non- | |||
standard User Defined Applications(UDAs). | standard User Defined Applications(UDAs). | |||
skipping to change at page 6, line 28 ¶ | skipping to change at page 6, line 28 ¶ | |||
| SABML+F | 1 octet | | SABML+F | 1 octet | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| UDABML+F | 1 octet | | UDABML+F | 1 octet | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| SABM ... 0 - 127 octets | | SABM ... 0 - 127 octets | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| UDABM ... 0 - 127 octets | | UDABM ... 0 - 127 octets | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
SABML+F (1 octet) | SABML+F (1 octet) | |||
Standard Application Bit Mask Length/Flags | Standard Application Identifier Bit Mask | |||
Length/Flags | ||||
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
|L| SA-Length | | |L| SA-Length | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
L-flag: Applications listed (both Standard and | L-flag: When set, applications listed (both Standard | |||
User Defined) MUST use the legacy advertisements | and User Defined) MUST use the legacy advertisements | |||
for the corresponding link found in TLVs 22, 23, | for the corresponding link found in TLVs 22, 23, | |||
141, 222, and 223 or TLV 138 or TLV 139 as appropriate. | 25, 141, 222, and 223 or TLV 138 or TLV 139 as | |||
appropriate. | ||||
SA-Length: Indicates the length in octets (0-127) of the Bit Mask | SA-Length: Indicates the length in octets (0-127) of the Bit Mask | |||
for Standard Applications. | for Standard Applications. | |||
UDABML+F (1 octet) | UDABML+F (1 octet) | |||
User Defined Application Bit Mask Length/Flags | User Defined Application Identifier Bit Mask | |||
Length/Flags | ||||
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
|R| UDA-Length | | |R| UDA-Length | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
R: Reserved. Transmitted as 0 and ignored on receipt | R: Reserved. SHOULD be transmitted as 0 and | |||
MUST be ignored on receipt | ||||
UDA-Length: Indicates the length in octets (0-127) of the Bit Mask | UDA-Length: Indicates the length in octets (0-127) of the Bit Mask | |||
for User Defined Applications. | for User Defined Applications. | |||
SABM (variable length) | SABM (variable length) | |||
Standard Application Bit Mask | Standard Application Identifier Bit Mask | |||
(SA-Length * 8) bits | (SA-Length * 8) bits | |||
This is omitted if SA-Length is 0. | This is omitted if SA-Length is 0. | |||
0 1 2 3 4 5 6 7 ... | 0 1 2 3 4 5 6 7 ... | |||
+-+-+-+-+-+-+-+-+... | +-+-+-+-+-+-+-+-+... | |||
|R|S|F|X| ... | |R|S|F| ... | |||
+-+-+-+-+-+-+-+-+... | +-+-+-+-+-+-+-+-+... | |||
R-bit: RSVP-TE | R-bit: Set to specify RSVP-TE | |||
S-bit: Segment Routing Traffic Engineering | ||||
F-bit: Loop Free Alternate | S-bit: Set to specify Segment Routing | |||
Traffic Engineering | ||||
X-bit: Flex-Algo | F-bit: Set to specify Loop Free Alternate | |||
(includes all LFA types) | ||||
UDABM (variable length) | UDABM (variable length) | |||
User Defined Application Bit Mask | User Defined Application Identifier Bit Mask | |||
(UDA Length * 8) bits | (UDA-Length * 8) bits | |||
0 1 2 3 4 5 6 7 ... | 0 1 2 3 4 5 6 7 ... | |||
+-+-+-+-+-+-+-+-+... | +-+-+-+-+-+-+-+-+... | |||
| ... | | ... | |||
+-+-+-+-+-+-+-+-+... | +-+-+-+-+-+-+-+-+... | |||
This is omitted if UDA-Length is 0. | This is omitted if UDA-Length is 0. | |||
NOTE: If both SA-length and UDA-Length are zero, then the | NOTE: If both SA-length and UDA-Length are zero, then the | |||
attributes associated with this attribute identifier bit mask | attributes associated with this Attribute Identifier Bit Mask | |||
MAY be used by any Standard Application and any User Defined | MAY be used by any Standard Application and any User Defined | |||
Application. | Application. | |||
Standard Application Bits are defined/sent starting with Bit 0. | Standard Application Identifier Bits are defined/sent starting with | |||
Additional bit definitions that may be defined in the future SHOULD | Bit 0. Additional bit definitions that may be defined in the future | |||
be assigned in ascending bit order so as to minimize the number of | SHOULD be assigned in ascending bit order so as to minimize the | |||
octets that will need to be transmitted. Undefined bits MUST be | number of octets that will need to be transmitted. Undefined bits | |||
transmitted as 0 and MUST be ignored on receipt. Bits that are NOT | MUST be transmitted as 0 and MUST be ignored on receipt. Bits that | |||
transmitted MUST be treated as if they are set to 0 on receipt. | are NOT transmitted MUST be treated as if they are set to 0 on | |||
receipt. | ||||
User Defined Application bits have no relationship to Standard | User Defined Application Identifier Bits have no relationship to | |||
Application bits and are NOT managed by IANA or any other standards | Standard Application Identifier Bits and are NOT managed by IANA or | |||
body. It is recommended that bits are used starting with Bit 0 so as | any other standards body. It is recommended that bits are used | |||
to minimize the number of octets required to advertise all UDAs. | starting with Bit 0 so as to minimize the number of octets required | |||
to advertise all UDAs. | ||||
4.2. Application Specific Link Attributes sub-TLV | 4.2. Application Specific Link Attributes sub-TLV | |||
A new sub-TLV for TLVs 22, 23, 141, 222, and 223 is defined which | A new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 is defined which | |||
supports specification of the applications and application specific | supports specification of the applications and application specific | |||
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 Bit Mask (as defined in Section 3.1) | Application Identifier Bit Mask | |||
(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] and [RFC8570] | |||
When the L-flag is set in the Application Identifiers, all of the | When the L-flag is set in the Application Identifier Bit Mask, all of | |||
applications specified in the bit mask MUST use the link attribute | the applications specified in the bit mask MUST use the link | |||
sub-TLV advertisements listed in Section 3.1 for the corresponding | attribute sub-TLV advertisements listed in Section 3.1 for the | |||
link. Application specific link attribute sub-sub-TLVs for the | corresponding link. Link attribute sub-sub-TLVs for the | |||
corresponding link attributes MUST NOT be advertised for the set of | corresponding link attributes MUST NOT be advertised for the set of | |||
applications specified in the Standard/User Application Bit Masks and | applications specified in the Standard/User Application Identifier | |||
all such advertisements MUST be ignored on receipt. | Bit Masks and all such advertisements MUST be ignored on receipt. | |||
Multiple sub-TLVs for the same link MAY be advertised. When multiple | Multiple Application Specific Link Attribute sub-TLVs for the same | |||
sub-TLVs for the same link are advertised, they SHOULD advertise non- | link MAY be advertised. When multiple sub-TLVs for the same link are | |||
conflicting application/attribute pairs. A conflict exists when the | advertised, they SHOULD advertise non-conflicting application/ | |||
same application is associated with two different values of the same | attribute pairs. A conflict exists when the same application is | |||
link attribute for a given link. In cases where conflicting values | associated with two different values of the same link attribute for a | |||
for the same application/attribute/link are advertised all the | given link. In cases where conflicting values for the same | |||
conflicting values MUST be ignored. | application/attribute/link are advertised all the conflicting values | |||
MUST be ignored. | ||||
For a given application, the setting of the L-flag MUST be the same | For a given application, the setting of the L-flag MUST be the same | |||
in all sub-TLVs for a given link. In cases where this constraint is | in all sub-TLVs for a given link. In cases where this constraint is | |||
violated, the L-flag MUST be considered set for this application. | violated, the L-flag MUST be considered set for this application. | |||
A new registry of sub-sub-TLVs is to be created by IANA which defines | A new registry of sub-sub-TLVs is to be created by IANA which defines | |||
the link attribute sub-sub-TLV code points. A sub-sub-TLV is defined | the link attribute sub-sub-TLV code points. This document defines a | |||
for each of the existing sub-TLVs listed in Section 3.1 except as | sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1 | |||
noted below. The format of the sub-sub-TLVs matches the format of | except as noted below. The format of the sub-sub-TLVs matches the | |||
the corresponding legacy sub-TLV and IANA is requested to assign the | format of the corresponding legacy sub-TLV and IANA is requested to | |||
legacy sub-TLV identifer to the corresponding sub-sub-TLV. | assign the legacy sub-TLV identifer to the corresponding sub-sub-TLV. | |||
4.2.1. Special Considerations for Maximum Link Bandwidth | 4.2.1. Special Considerations for Maximum Link Bandwidth | |||
Maximum link bandwidth is an application independent attribute of the | Maximum link bandwidth is an application independent attribute of the | |||
link. When advertised using the Application Specific Link Attributes | link. When advertised using the Application Specific Link Attributes | |||
sub-TLV, multiple values for the same link MUST NOT be advertised. | sub-TLV, multiple values for the same link MUST NOT be advertised. | |||
This can be accomplished most efficiently by having a single | This can be accomplished most efficiently by having a single | |||
advertisement for a given link where the Application Bit Mask | advertisement for a given link where the Application Identifier Bit | |||
identifies all the applications which are making use of the value for | Mask identifies all the applications which are making use of the | |||
that link. | value for that link. | |||
It is also possible to advertise the same value for a given link | It is also possible to advertise the same value for a given link | |||
multiple times with disjoint sets of applications specified in the | multiple times with disjoint sets of applications specified in the | |||
Application Bit Mask. This is less efficient but still valid. | Application Identifier Bit Mask. This is less efficient but still | |||
valid. | ||||
If different values for Maximum Link Bandwidth for a given link are | If different values for Maximum Link Bandwidth for a given link are | |||
advertised, all values MUST be ignored. | advertised, all values MUST be ignored. | |||
4.2.2. Special Considerations for Unreserved Bandwidth | 4.2.2. Special Considerations for Unreserved Bandwidth | |||
Unreserved bandwidth is an attribute specific to RSVP. When | Unreserved bandwidth is an attribute specific to RSVP. When | |||
advertised using the Application Specific Link Attributes sub-TLV, | advertised using the Application Specific Link Attributes sub-TLV, | |||
bits other than the RSVP-TE(R-bit) MUST NOT be set in the Application | bits other than the RSVP-TE(R-bit) MUST NOT be set in the Application | |||
Bit Mask. If an advertisement of Unreserved Bandwidth is received | Identifier Bit Mask. If an advertisement of Unreserved Bandwidth is | |||
with bits other than the RSVP-TE bit set, the advertisement MUST be | received with bits other than the RSVP-TE bit set, the advertisement | |||
ignored. | MUST be ignored. | |||
4.3. Application Specific SRLG TLV | 4.3. Application Specific SRLG TLV | |||
A new TLV is defined to advertise application specific SRLGs for a | A new TLV is defined to advertise application specific SRLGs for a | |||
given link. Although similar in functionality to TLV 138 (defined by | given link. Although similar in functionality to TLV 138 (defined by | |||
[RFC5307]) and TLV 139 (defined by [RFC6119], a single TLV provides | [RFC5307]) and TLV 139 (defined by [RFC6119], a single TLV provides | |||
support for IPv4, IPv6, and unnumbered identifiers for a link. | support for IPv4, IPv6, and unnumbered identifiers for a link. | |||
Unlike TLVs 138/139, it utilizes sub-TLVs to encode the link | Unlike TLVs 138/139, it utilizes sub-TLVs to encode the link | |||
identifiers in order to provide the flexible formatting required to | identifiers in order to provide the flexible formatting required to | |||
support multiple link identifier types. | support multiple link identifier types. | |||
Type: 238 (Temporarily assigned by IANA) | Type: 238 (Temporarily assigned by IANA) | |||
Length: Number of octets in the value field (1 octet) | Length: Number of octets in the value field (1 octet) | |||
Value: | Value: | |||
Neighbor System-ID + pseudo-node ID (7 octets) | Neighbor System-ID + pseudo-node ID (7 octets) | |||
Application Bit Mask (as defined in Section 3.1) | Application Identifier Bit Mask | |||
(as defined in Section 4.1) | ||||
Length of sub-TLVs (1 octet) | Length of sub-TLVs (1 octet) | |||
Link Identifier sub-TLVs (variable) | Link Identifier sub-TLVs (variable) | |||
0 or more SRLG Values (Each value is 4 octets) | 0 or more SRLG Values (Each value is 4 octets) | |||
The following Link Identifier sub-TLVs are defined. The type | The following Link Identifier sub-TLVs are defined. The type | |||
values are suggested and will be assigned by IANA - but as | values are suggested and will be assigned by IANA - but as | |||
the formats are identical to existing sub-TLVs defined for | the formats are identical to existing sub-TLVs defined for | |||
TLVs 22, 23, 141, 222, and 223 the use of the suggested sub-TLV | TLVs 22, 23, 25, 141, 222, and 223 the use of the suggested | |||
types is strongly encouraged. | sub-TLV types is strongly encouraged. | |||
Type Description | Type Description | |||
4 Link Local/Remote Identifiers (see [RFC5307]) | 4 Link Local/Remote Identifiers (see [RFC5307]) | |||
6 IPv4 interface address (see [RFC5305]) | 6 IPv4 interface address (see [RFC5305]) | |||
8 IPv4 neighbor address (see [RFC5305]) | 8 IPv4 neighbor address (see [RFC5305]) | |||
12 IPv6 Interface Address (see [RFC6119]) | 12 IPv6 Interface Address (see [RFC6119]) | |||
13 IPv6 Neighbor Address (see [RFC6119]) | 13 IPv6 Neighbor Address (see [RFC6119]) | |||
At least one set of link identifiers (IPv4, IPv6, or unnumbered) MUST | At least one set of link identifiers (IPv4, IPv6, or unnumbered) MUST | |||
be present. TLVs which do not meet this requirement MUST be ignored. | be present. TLVs which do not meet this requirement MUST be ignored. | |||
Multiple TLVs for the same link MAY be advertised. | Multiple TLVs for the same link MAY be advertised. | |||
When the L-flag is set in the Application Identifiers, SRLG values | When the L-flag is set in the Application Identifier Bit Mask, SRLG | |||
MUST NOT be included in the TLV. Any SRLG values which are | values MUST NOT be included in the TLV. Any SRLG values which are | |||
advertised MUST be ignored. Based on the link identifiers advertised | advertised MUST be ignored. Based on the link identifiers advertised | |||
the corresponding legacy TLV (see Section 3.2) can be identified and | the corresponding legacy TLV (see Section 3.2) can be identified and | |||
the SRLG values advertised in the legacy TLV MUST be used by the set | the SRLG values advertised in the legacy TLV MUST be used by the set | |||
of applications specified in the Application Bit Mask. | of applications specified in the Application Identifier Bit Mask. | |||
For a given application, the setting of the L-flag MUST be the same | For a given application, the setting of the L-flag MUST be the same | |||
in all TLVs for a given link. In cases where this constraint is | in all TLVs for a given link. In cases where this constraint is | |||
violated, the L-flag MUST be considered set for this application. | violated, the L-flag MUST be considered set for this application. | |||
5. Deployment Considerations | 5. Deployment Considerations | |||
If link attributes are advertised associated with zero length | If link attributes are advertised associated with zero length | |||
application bit masks for both standard applications and user defined | Application Identifier Bit Masks for both standard applications and | |||
applications, then that set of link attributes MAY be used by any | user defined applications, then that set of link attributes MAY be | |||
application. If support for a new application is introduced on any | used by any application. If support for a new application is | |||
node in a network in the presence of such advertisements, these | introduced on any node in a network in the presence of such | |||
advertisements MAY be used by the new application. If this is not | advertisements, these advertisements MAY be used by the new | |||
what is intended, then existing advertisements MUST be readvertised | application. If this is not what is intended, then existing | |||
with an explicit set of applications specified before a new | advertisements MUST be readvertised with an explicit set of | |||
application is introduced. | applications specified before a new application is introduced. | |||
6. Attribute Advertisements and Enablement | 6. Attribute Advertisements and Enablement | |||
This document defines extensions to support the advertisement of | This document defines extensions to support the advertisement of | |||
application specific link attributes. | application specific link attributes. | |||
Whether the presence of link attribute advertisements for a given | Whether the presence of link attribute advertisements for a given | |||
application indicates that the application is enabled on that link | application indicates that the application is enabled on that link | |||
depends upon the application. Similarly, whether the absence of link | depends upon the application. Similarly, whether the absence of link | |||
attribute advertisements indicates that the application is not | attribute advertisements indicates that the application is not | |||
skipping to change at page 11, line 32 ¶ | skipping to change at page 11, line 32 ¶ | |||
attributes does NOT indicate enablement of SRTE. The advertisements | attributes does NOT indicate enablement of SRTE. The advertisements | |||
are only used to support constraints which may be applied when | are only used to support constraints which may be applied when | |||
specifying an explicit path. SRTE is implicitly enabled on all links | specifying an explicit path. SRTE is implicitly enabled on all links | |||
which are part of the Segment Routing enabled topology independent of | which are part of the Segment Routing enabled topology independent of | |||
the existence of link attribute advertisements | the existence of link attribute advertisements | |||
In the case of LFA, advertisement of application specific link | In the case of LFA, advertisement of application specific link | |||
attributes does NOT indicate enablement of LFA on that link. | attributes does NOT indicate enablement of LFA on that link. | |||
Enablement is controlled by local configuration. | Enablement is controlled by local configuration. | |||
In the case of Flex-Algo, advertisement of application specific link | ||||
attributes does NOT indicate enablement of Flex-Algo. Rather the | ||||
attributes are used to determine what links are included/excluded in | ||||
the algorithm specific constrained SPF. This is fully specified in | ||||
[I-D.ietf-lsr-flex-algo]. | ||||
If, in the future, additional standard applications are defined to | If, in the future, additional standard applications are defined to | |||
use this mechanism, the specification defining this use MUST define | use this mechanism, the specification defining this use MUST define | |||
the relationship between application specific link attribute | the relationship between application specific link attribute | |||
advertisements and enablement for that application. | advertisements and enablement for that application. | |||
This document allows the advertisement of application specific link | This document allows the advertisement of application specific link | |||
attributes with no application identifiers i.e., both the Standard | attributes with no application identifiers i.e., both the Standard | |||
Application Bit Mask and the User Defined Application Bit Mask are | Application Identifier Bit Mask and the User Defined Application | |||
not present (See Section 4.1). This supports the use of the link | Identifier Bit Mask are not present (See Section 4.1). This supports | |||
attribute by any application. In the presence of an application | the use of the link attribute by any application. In the presence of | |||
where the advertisement of link attribute advertisements is used to | an application where the advertisement of link attribute | |||
infer the enablement of an application on that link (e.g., RSVP-TE), | advertisements is used to infer the enablement of an application on | |||
the absence of the application identifier leaves ambiguous whether | that link (e.g., RSVP-TE), the absence of the application identifier | |||
that application is enabled on such a link. This needs to be | leaves ambiguous whether that application is enabled on such a link. | |||
considered when making use of the "any application" encoding. | This needs to be considered when making use of the "any application" | |||
encoding. | ||||
7. Interoperability, Backwards Compatibility and Migration Concerns | 7. Interoperability, Backwards Compatibility and Migration Concerns | |||
Existing deployments of RSVP-TE utilize the legacy advertisements | Existing deployments of RSVP-TE utilize the legacy advertisements | |||
listed in Section 3. Routers which do not support the extensions | listed in Section 3. Routers which do not support the extensions | |||
defined in this document will only process legacy advertisements and | defined in this document will only process legacy advertisements and | |||
are likely to infer that RSVP-TE is enabled on the links for which | are likely to infer that RSVP-TE is enabled on the links for which | |||
legacy advertisements exist. It is expected that deployments using | legacy advertisements exist. It is expected that deployments using | |||
the legacy advertisements will persist for a significant period of | the legacy advertisements will persist for a significant period of | |||
time - therefore deployments using the extensions defined in this | time - therefore deployments using the extensions defined in this | |||
skipping to change at page 13, line 10 ¶ | skipping to change at page 13, line 7 ¶ | |||
applications other than RSVP-TE MUST be advertised using application | applications other than RSVP-TE MUST be advertised using application | |||
specific advertisements which have the L-bit clear. In cases where | specific advertisements which have the L-bit clear. In cases where | |||
some link attributes are shared with RSVP-TE, this requires duplicate | some link attributes are shared with RSVP-TE, this requires duplicate | |||
advertisements for those attributes. | advertisements for those attributes. | |||
The discussion in this section applies to cases where RSVP-TE is NOT | The discussion in this section applies to cases where RSVP-TE is NOT | |||
using any advertised attributes on a link and to cases where RSVP-TE | using any advertised attributes on a link and to cases where RSVP-TE | |||
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. | |||
7.4. Deprecating legacy advertisements | 7.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 - so a long term goal for deployments would be | supported applications. This allows that RSVP-TE could eventually | |||
to deprecate use of the legacy advertisements in support of RSVP-TE. | utilize the application specific advertisements. This can be done in | |||
This can be done in the following step-wise manner: | the following step-wise manner: | |||
1)Upgrade all routers to support extensions in this document | 1)Upgrade all routers to support extensions in this document | |||
2)Readvertise all legacy link attributes using application specific | 2)Readvertise all legacy link attributes using application specific | |||
advertisements with L-bit clear and R-bit set. | advertisements with L-bit clear and R-bit set. | |||
3)Remove legacy advertisements | 3)Remove legacy advertisements | |||
Migrating RSVP-TE away from legacy advertisements could result in | ||||
some implementation simplification as it allows the removal of code | ||||
which encodes/decodes the legacy advertisements. Whether this is | ||||
seen as desirable is something for the marketplace to determine. | ||||
8. IANA Considerations | 8. IANA Considerations | |||
This document defines a new sub-TLV for TLVs 22, 23, 141, 222, and | This document defines a new sub-TLV for TLVs 22, 23, 25, 141, 222, | |||
223. | and 223. | |||
Type Description 22 23 25 141 222 223 | Type Description 22 23 25 141 222 223 | |||
---- --------------------- ---- ---- ---- ---- ---- ---- | ---- --------------------- ---- ---- ---- ---- ---- ---- | |||
16 Application Specific y y y(s) y y y | 16 Application Specific y y y(s) y y y | |||
Link Attributes | Link Attributes | |||
This document defines one new TLV: | This document defines one new TLV: | |||
Type Description IIH LSP SNP Purge | Type Description IIH LSP SNP Purge | |||
---- --------------------- --- --- --- ----- | ---- --------------------- --- --- --- ----- | |||
238 Application Specific n y n n | 238 Application Specific n y n n | |||
SRLG | SRLG | |||
This document requests a new IANA registry be created to control the | This document requests a new IANA registry be created to control the | |||
assignment of sub-sub-TLV codepoints for the Application Specific | assignment of sub-sub-TLV codepoints for the Application Specific | |||
Link Attributes sub-TLV. The suggested name of the new registry is | Link Attributes sub-TLV. 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 | |||
skipping to change at page 14, line 29 ¶ | skipping to change at page 14, line 29 ¶ | |||
34 Min/Max Unidirectional Link Delay | 34 Min/Max Unidirectional Link Delay | |||
35 Unidirectional Delay Variation | 35 Unidirectional Delay Variation | |||
36 Unidirectional Link Loss | 36 Unidirectional Link Loss | |||
37 Unidirectional Residual Bandwidth | 37 Unidirectional Residual Bandwidth | |||
38 Unidirectional Available Bandwidth | 38 Unidirectional Available Bandwidth | |||
39 Unidirectional Utilized Bandwidth | 39 Unidirectional Utilized Bandwidth | |||
40-255 Unassigned | 40-255 Unassigned | |||
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 bit identifiers. 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] and | |||
[RFC7120]). The following assignments are made by this document: | [RFC7120]). The following assignments are made 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) | |||
3 Flex Algorithm (X-bit) | ||||
This document requests a new IANA registry be created to control the | This document requests a new IANA registry be created to control the | |||
assignment of sub-TLV types for the application specific SRLG TLV. | assignment of sub-TLV types for the application specific SRLG TLV. | |||
The suggested name of the new registry is "Sub-TLVs for TLV 238". | The suggested name of the new registry is "Sub-TLVs for TLV 238". | |||
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: | |||
Value Description | Value Description | |||
--------------------------------------------------------- | --------------------------------------------------------- | |||
0-3 Unassigned | 0-3 Unassigned | |||
skipping to change at page 16, line 34 ¶ | skipping to change at page 16, line 34 ¶ | |||
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>. | |||
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, | [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, | |||
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) | D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) | |||
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March | Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March | |||
2019, <https://www.rfc-editor.org/info/rfc8570>. | 2019, <https://www.rfc-editor.org/info/rfc8570>. | |||
11.2. Informative References | 11.2. Informative References | |||
[I-D.ietf-lsr-flex-algo] | ||||
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and | ||||
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- | ||||
algo-01 (work in progress), November 2018. | ||||
[I-D.ietf-spring-segment-routing-policy] | [I-D.ietf-spring-segment-routing-policy] | |||
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., | Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., | |||
bogdanov@google.com, b., and P. Mattes, "Segment Routing | bogdanov@google.com, b., and P. Mattes, "Segment Routing | |||
Policy Architecture", draft-ietf-spring-segment-routing- | Policy Architecture", draft-ietf-spring-segment-routing- | |||
policy-02 (work in progress), October 2018. | policy-03 (work in progress), May 2019. | |||
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., | [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., | |||
Litkowski, S., Horneffer, M., and R. Shakir, "Source | Litkowski, S., Horneffer, M., and R. Shakir, "Source | |||
Packet Routing in Networking (SPRING) Problem Statement | Packet Routing in Networking (SPRING) Problem Statement | |||
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May | and Requirements", RFC 7855, DOI 10.17487/RFC7855, May | |||
2016, <https://www.rfc-editor.org/info/rfc7855>. | 2016, <https://www.rfc-editor.org/info/rfc7855>. | |||
Authors' Addresses | Authors' Addresses | |||
Les Ginsberg | Les Ginsberg | |||
Cisco Systems | Cisco Systems | |||
821 Alder Drive | 821 Alder Drive | |||
Milpitas, CA 95035 | Milpitas, CA 95035 | |||
USA | USA | |||
Email: ginsberg@cisco.com | Email: ginsberg@cisco.com | |||
Peter Psenak | Peter Psenak | |||
Cisco Systems | Cisco Systems | |||
End of changes. 53 change blocks. | ||||
120 lines changed or deleted | 128 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/ |