draft-ietf-isis-segment-routing-msd-19.txt | rfc8491.txt | |||
---|---|---|---|---|
IS-IS Working Group J. Tantsura | Internet Engineering Task Force (IETF) J. Tantsura | |||
Internet-Draft Apstra, Inc. | Request for Comments: 8491 Apstra, Inc. | |||
Intended status: Standards Track U. Chunduri | Category: Standards Track U. Chunduri | |||
Expires: April 12, 2019 Huawei Technologies | ISSN: 2070-1721 Huawei Technologies | |||
S. Aldrin | S. Aldrin | |||
Google, Inc | Google, Inc. | |||
L. Ginsberg | L. Ginsberg | |||
Cisco Systems | Cisco Systems | |||
October 9, 2018 | November 2018 | |||
Signaling MSD (Maximum SID Depth) using IS-IS | Signaling Maximum SID Depth (MSD) Using IS-IS | |||
draft-ietf-isis-segment-routing-msd-19 | ||||
Abstract | Abstract | |||
This document defines a way for an Intermediate System to | This document defines a way for an Intermediate System to | |||
Intermediate System (IS-IS) router to advertise multiple types of | Intermediate System (IS-IS) router to advertise multiple types of | |||
supported Maximum SID Depths (MSDs) at node and/or link granularity. | supported Maximum SID Depths (MSDs) at node and/or link granularity. | |||
Such advertisements allow entities (e.g., centralized controllers) to | Such advertisements allow entities (e.g., centralized controllers) to | |||
determine whether a particular SID (Segment ID) stack can be | determine whether a particular Segment ID (SID) stack can be | |||
supported in a given network. This document only defines one type of | supported in a given network. This document only defines one type of | |||
MSD (Base MPLS Imposition), but defines an encoding that can support | MSD: Base MPLS Imposition. However, it defines an encoding that can | |||
other MSD types. This document focuses on MSD use in a Segment | support other MSD types. This document focuses on MSD use in a | |||
Routing enabled network, but MSD may also be useful when Segment | network that is Segment Routing (SR) enabled, but MSD may also be | |||
Routing is not enabled. | useful when SR is not enabled. | |||
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 April 12, 2019. | 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/rfc8491. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 32 ¶ | skipping to change at page 2, line 32 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 | 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 | 2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 | |||
3. Link MSD Advertisement . . . . . . . . . . . . . . . . . . . 5 | 3. Link MSD Advertisement . . . . . . . . . . . . . . . . . . . 5 | |||
4. Procedures for Defining and Using Node and Link MSD | 4. Procedures for Defining and Using Node and Link MSD | |||
Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6 | Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6 | 5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 8.2. Informative References . . . . . . . . . . . . . . . . . 9 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 9 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
1. Introduction | 1. Introduction | |||
When Segment Routing (SR) paths are computed by a centralized | When Segment Routing (SR) paths are computed by a centralized | |||
controller, it is critical that the controller learns the Maximum SID | controller, it is critical that the controller learn the Maximum SID | |||
Depth (MSD) that can be imposed at each node/link of a given SR path | Depth (MSD) that can be imposed at each node/link of a given SR path. | |||
to ensure that the Segment Identifier (SID) stack depth of a computed | This ensures that the Segment Identifier (SID) stack depth of a | |||
path does not exceed the number of SIDs the node is capable of | computed path does not exceed the number of SIDs the node is capable | |||
imposing. | of imposing. | |||
[I-D.ietf-pce-segment-routing] defines how to signal MSD in the Path | [PCEP-EXT] defines how to signal MSD in the Path Computation Element | |||
Computation Element communication Protocol (PCEP). However, if PCEP | Communication Protocol (PCEP). However, if PCEP is not supported/ | |||
is not supported/configured on the head-end of an SR tunnel or a | configured on the head-end of an SR tunnel or a Binding-SID anchor | |||
Binding-SID anchor node and controller does not participate in IGP | node, and the controller does not participate in IGP routing, it has | |||
routing, it has no way to learn the MSD of nodes and links. BGP-LS | no way of learning the MSD of nodes and links. BGP-LS (Distribution | |||
(Distribution of Link-State and TE Information using Border Gateway | of Link-State and TE Information Using Border Gateway Protocol) | |||
Protocol) [RFC7752] defines a way to expose topology and associated | [RFC7752] defines a way to expose topology and associated attributes | |||
attributes and capabilities of the nodes in that topology to a | and capabilities of the nodes in that topology to a centralized | |||
centralized controller. MSD signaling by BGP-LS has been defined in | controller. MSD signaling by BGP-LS has been defined in [MSD-BGP]. | |||
[I-D.ietf-idr-bgp-ls-segment-routing-msd]. Typically, BGP-LS is | Typically, BGP-LS is configured on a small number of nodes that do | |||
configured on a small number of nodes that do not necessarily act as | not necessarily act as head-ends. In order for BGP-LS to signal MSD | |||
head-ends. In order for BGP-LS to signal MSD for all the nodes and | for all the nodes and links in the network for which MSD is relevant, | |||
links in the network MSD is relevant, MSD capabilities SHOULD be | MSD capabilities SHOULD be advertised by every Intermediate System to | |||
advertised by every Intermediate System to Intermediate System(IS-IS) | Intermediate System (IS-IS) router in the network. | |||
router in the network. | ||||
Other types of MSD are known to be useful. For example, | Other types of MSDs are known to be useful. For example, [ELC-ISIS] | |||
[I-D.ietf-isis-mpls-elc] defines Readable Label Depth Capability | defines Entropy Readable Label Depth (ERLD), which is used by a head- | |||
(RLDC) that is used by a head-end to insert an Entropy Label (EL) at | end to insert an Entropy Label (EL) at a depth where it can be read | |||
a depth, that could be read by transit nodes. | by transit nodes. | |||
This document defines an extension to IS-IS used to advertise one or | This document defines an extension to IS-IS used to advertise one or | |||
more types of MSD at node and/or link granularity. It also creates | more types of MSDs at node and/or link granularity. It also creates | |||
an IANA registry for assigning MSD-type identifiers. It also defines | an IANA registry for assigning MSD-Type identifiers and defines the | |||
the Base MPLS Imposition MSD-type. In the future it is expected that | Base MPLS Imposition MSD-Type. In the future, it is expected that | |||
new MSD-types will be defined to signal additional capabilities e.g., | new MSD-Types will be defined to signal additional capabilities, | |||
entropy labels, SIDs that can be imposed through recirculation, or | e.g., entropy labels, SIDs that can be imposed through recirculation, | |||
SIDs associated with another dataplane e.g., IPv6. | or SIDs associated with another data plane such as IPv6. | |||
MSD advertisements MAY be useful even if Segment Routing itself is | MSD advertisements MAY be useful even if Segment Routing itself is | |||
not enabled. For example, in a non-SR MPLS network, MSD defines the | not enabled. For example, in a non-SR MPLS network, MSD defines the | |||
maximum label depth. | maximum label depth. | |||
1.1. Terminology | 1.1. Terminology | |||
BMI: Base MPLS Imposition is the number of MPLS labels which can be | BMI: Base MPLS Imposition is the number of MPLS labels that can be | |||
imposed inclusive of all service/transport/special labels | imposed inclusive of all service/transport/special labels. | |||
MSD: Maximum SID Depth - the number of SIDs supported by a node or a | MSD: Maximum SID Depth is the number of SIDs supported by a node or | |||
link on a node | a link on a node. | |||
SID: Segment Identifier as defined in [RFC8402] | SID: Segment Identifier is defined in [RFC8402]. | |||
Label Imposition: Imposition is the act of modifying and/or adding | Label Imposition: Imposition is the act of modifying and/or adding | |||
labels to the outgoing label stack associated with a packet. This | labels to the outgoing label stack associated with a packet. | |||
includes: | This includes: | |||
o replacing the label at the top of the label stack with a new label | * replacing the label at the top of the label stack with a new | |||
label | ||||
* pushing one or more new labels onto the label stack | ||||
o pushing one or more new labels onto the label stack | ||||
The number of labels imposed is then the sum of the number of labels | The number of labels imposed is then the sum of the number of labels | |||
which are replaced and the number of labels which are pushed. See | that are replaced and the number of labels that are pushed. See | |||
[RFC3031] for further details. | [RFC3031] for further details. | |||
1.2. Requirements Language | 1.2. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here . | capitals, as shown here. | |||
2. Node MSD Advertisement | 2. Node MSD Advertisement | |||
The node MSD sub-TLV is defined within the body of the IS-IS Router | The Node MSD sub-TLV is defined within the body of the IS-IS Router | |||
Capability TLV [RFC7981], to carry the provisioned SID depth of the | CAPABILITY TLV [RFC7981] to carry the provisioned SID depth of the | |||
router originating the Router Capability TLV. Node MSD is the | router originating the IS-IS Router CAPABILITY TLV. Node MSD is the | |||
smallest MSD supported by the node on the set of interfaces | smallest MSD supported by the node on the set of interfaces | |||
configured for use by the advertising IGP instance. MSD values may | configured for use by the advertising IGP instance. MSD values may | |||
be learned via a hardware API or may be provisioned. | be learned via a hardware API or may be provisioned. | |||
0 1 | 0 1 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length | | | Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| MSD-Type | MSD-Value | | | MSD-Type | MSD-Value | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
// ................... // | // ................... // | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| MSD-Type | MSD-Value | | | MSD-Type | MSD-Value | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: Node MSD Sub-TLV | Figure 1: Node MSD Sub-TLV | |||
Type: 23 (allocated by IANA via the early assignment process) | Type: 23 | |||
Length: variable (multiple of 2 octets) and represents the total | ||||
length of value field. | ||||
Value: field consists of one or more pairs of a 1 octet MSD-Type and | Length: variable (multiple of 2 octets); represents the total length | |||
1 octet MSD-Value. | of the Value field | |||
MSD-Type is a value defined in the IGP MSD-Types registry created by | Value: field consists of one or more pairs of a 1-octet MSD-Type and | |||
the IANA Section of this document. | 1-octet MSD-Value | |||
MSD-Value is a number in the range of 0-255. For all MSD-Types, 0 | MSD-Type: value defined in the "IGP MSD-Types" registry created by | |||
represents lack of the ability to support SID stack of any depth; any | the IANA Considerations section of this document Section 6 | |||
other value represents that of the node. This value MUST represent | MSD-Value: number in the range of 0-255 (for all MSD-Types, 0 | |||
the lowest value supported by any link configured for use by the | represents the lack of ability to support a SID stack of any depth; | |||
advertising IS-IS instance. | any other value represents that of the node. This value MUST | |||
represent the lowest value supported by any link configured for use | ||||
by the advertising IS-IS instance.) | ||||
This sub-TLV is optional. The scope of the advertisement is specific | This sub-TLV is optional. The scope of the advertisement is specific | |||
to the deployment. | to the deployment. | |||
If there exist multiple Node MSD advertisements for the same MSD-Type | If there exist multiple Node MSD advertisements for the same MSD-Type | |||
originated by the same router, the procedures defined in [RFC7981] | originated by the same router, the procedures defined in [RFC7981] | |||
apply. These procedures may result in different MSD values being | apply. These procedures may result in different MSD values being | |||
used by (for example) different controllers - but this does not | used, for example, by different controllers. This does not, however, | |||
create any interoperability issue. | create any interoperability issue. | |||
3. Link MSD Advertisement | 3. Link MSD Advertisement | |||
The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and | The Link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and | |||
223 to carry the MSD of the interface associated with the link. MSD | 223 to carry the MSD of the interface associated with the link. MSD | |||
values may be signaled by the forwarding plane or may be provisioned. | values may be signaled by the forwarding plane or may be provisioned. | |||
0 1 | 0 1 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length | | | Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| MSD-Type | MSD-Value | | | MSD-Type | MSD-Value | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
// ................... // | // ................... // | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| MSD-Type | MSD-Value | | | MSD-Type | MSD-Value | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: Link MSD Sub-TLV | Figure 2: Link MSD Sub-TLV | |||
Type: 15 (allocated by IANA via the early assignment process) | Type: 15 | |||
Length: variable (multiple of 2 octets) and represents the total | ||||
length of value field. | ||||
Value: consists of one or more pairs of a 1 octet MSD-Type and 1 | Length: variable (multiple of 2 octets); represents the total length | |||
octet MSD-Value. | of the Value field | |||
MSD-Type is a value defined in the MSD-Types registry created by the | Value: field consists of one or more pairs of a 1-octet MSD-Type and | |||
IANA Section of this document. | 1-octet MSD-Value | |||
MSD-Value is a number in the range of 0-255. For all MSD-Types, 0 | MSD-Type: value defined in the "IGP MSD-Types" registry created by | |||
represents lack of the ability to support SID stack of any depth; any | the IANA Considerations section of this document Section 6 | |||
other value represents that of the particular link when used as an | MSD-Value: number in the range of 0-255 (for all MSD-Types, 0 | |||
outgoing interface. | represents the lack of ability to support a SID stack of any depth; | |||
any other value represents that of the particular link when used as | ||||
an outgoing interface.) | ||||
This sub-TLV is optional. | This sub-TLV is optional. | |||
If multiple Link MSD advertisements for the same MSD-Type and the | If multiple Link MSD advertisements for the same MSD-Type and the | |||
same link are received, the procedure used to select which copy is | same link are received, the procedure to select which copy to use is | |||
used is undefined. | undefined. | |||
If the advertising router performs label imposition in the context of | If the advertising router performs label imposition in the context of | |||
the ingress interface, it is not possible to meaningfully advertise | the ingress interface, it is not possible to meaningfully advertise | |||
per link values. In such a case only the Node MSD SHOULD be | per-link values. In such a case, only the Node MSD SHOULD be | |||
advertised. | advertised. | |||
4. Procedures for Defining and Using Node and Link MSD Advertisements | 4. Procedures for Defining and Using Node and Link MSD Advertisements | |||
When Link MSD is present for a given MSD-type, the value of the Link | When Link MSD is present for a given MSD-Type, the value of the Link | |||
MSD MUST take precedence over the Node MSD. When a Link MSD-type is | MSD MUST take precedence over the Node MSD. If a Link MSD-Type is | |||
not signaled but the Node MSD-type is, then the Node MSD-type value | not signaled, but the Node MSD-Type is, then the Node MSD-Type value | |||
MUST be considered as the MSD value for that link. | MUST be considered to be the MSD value for that link. | |||
In order to increase flooding efficiency, it is RECOMMENDED that | In order to increase flooding efficiency, it is RECOMMENDED that | |||
routers with homogenous link MSD values advertise just the Node MSD | routers with homogenous Link MSD values advertise just the Node MSD | |||
value. | value. | |||
The meaning of the absence of both Node and Link MSD advertisements | The meaning of the absence of both Node and Link MSD advertisements | |||
for a given MSD-type is specific to the MSD-type. Generally it can | for a given MSD-Type is specific to the MSD-Type. Generally, it can | |||
only be inferred that the advertising node does not support | only be inferred that the advertising node does not support | |||
advertisement of that MSD-type. However, in some cases the lack of | advertisement of that MSD-Type. In some cases, however, the lack of | |||
advertisement might imply that the functionality associated with the | advertisement might imply that the functionality associated with the | |||
MSD-type is not supported. The correct interpretation MUST be | MSD-Type is not supported. The correct interpretation MUST be | |||
specified when an MSD-type is defined. | specified when an MSD-Type is defined. | |||
5. Base MPLS Imposition MSD | 5. Base MPLS Imposition MSD | |||
Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS | Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS | |||
labels which can be imposed, including all service/transport/special | labels that can be imposed, including all service/transport/special | |||
labels. | labels. | |||
Absence of BMI-MSD advertisements indicates solely that the | The absence of BMI-MSD advertisements indicates only that the | |||
advertising node does not support advertisement of this capability. | advertising node does not support advertisement of this capability. | |||
6. IANA Considerations | 6. IANA Considerations | |||
This document requests IANA to allocate a sub-TLV type for the new | IANA has allocated a sub-TLV type for the new sub-TLV proposed in | |||
sub TLV proposed in Section 2 of this document from IS-IS Router | Section 2 of this document from the "Sub-TLVs for TLV 242 (IS-IS | |||
Capability TLV Registry as defined by [RFC7981]. | Router CAPABILITY TLV)" registry as defined by [RFC7981]. | |||
IANA has allocated the following value through the early assignment | IANA has allocated the following value: | |||
process: | ||||
Value Description Reference | Value Description Reference | |||
----- --------------- ------------- | ----- --------------- ------------- | |||
23 Node MSD This document | 23 Node MSD This document | |||
Figure 3: Node MSD | Figure 3: Node MSD | |||
This document requests IANA to allocate a sub-TLV type as defined in | IANA has allocated a sub-TLV type as defined in Section 3 from the | |||
Section 3 from Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 | "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS | |||
registry. | reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, | |||
inter-AS reachability information, MT-ISN, and MT IS Neighbor | ||||
Attribute TLVs)" registry. | ||||
IANA has allocated the following value through the early assignment | IANA has allocated the following value: | |||
process: | ||||
Value Description Reference | Value Description Reference | |||
----- --------------- ------------- | ----- --------------- ------------- | |||
15 Link MSD This document | 15 Link MSD This document | |||
Figure 4: Link MSD | Figure 4: Link MSD | |||
Per TLV information where Link MSD sub-TLV can be part of: | Per-TLV information where Link MSD sub-TLV can be part of: | |||
TLV 22 23 25 141 222 223 | TLV 22 23 25 141 222 223 | |||
--- -------------------- | --- -------------------- | |||
y y y y y y | y y y y y y | |||
Figure 5: TLVs where LINK MSD Sub-TLV can be present | Figure 5: TLVs Where LINK MSD Sub-TLV Can Be Present | |||
This document requests creation of an IANA managed registry under the | IANA has created an IANA-managed registry titled "IGP MSD-Types" | |||
category of "Interior Gateway Protocol (IGP) Parameters" IANA | under the "Interior Gateway Protocol (IGP) Parameters" registry to | |||
registries to identify MSD-types as proposed in Section 2 and | identify MSD-Types as proposed in Sections 2 and 3. The registration | |||
Section 3. The registration procedure is "Expert Review" as defined | procedure is "Expert Review" as defined in [RFC8126]. Types are an | |||
in [RFC8126]. Suggested registry name is "IGP MSD-Types". Types are | unsigned 8-bit number. The following values are defined by this | |||
an unsigned 8 bit number. The following values are defined by this | ||||
document: | document: | |||
Value Name Reference | Value Name Reference | |||
----- --------------------- ------------- | ----- --------------------- ------------- | |||
0 Reserved This document | 0 Reserved This document | |||
1 Base MPLS Imposition MSD This document | 1 Base MPLS Imposition MSD This document | |||
2-250 Unassigned This document | 2-250 Unassigned | |||
251-254 Experimental Use This document | 251-254 Experimental Use This document | |||
255 Reserved This document | 255 Reserved This document | |||
Figure 6: MSD-Types Codepoints Registry | Figure 6: MSD-Types Codepoints Registry | |||
General guidance for the Designated Experts is as defined in | General guidance for the designated experts is defined in [RFC7370]. | |||
[RFC7370] | ||||
7. Security Considerations | 7. Security Considerations | |||
Security considerations as specified by [RFC7981] are applicable to | Security considerations as specified by [RFC7981] are applicable to | |||
this document. | this document. | |||
Advertisement of an incorrect MSD value may have negative | The advertisement of an incorrect MSD value may have negative | |||
consequences. If the value is smaller than supported, path | consequences. If the value is smaller than supported, path | |||
computation may fail to compute a viable path. If the value is | computation may fail to compute a viable path. If the value is | |||
larger than supported, an attempt to instantiate a path that can't be | larger than supported, an attempt to instantiate a path that can't be | |||
supported by the head-end (the node performing the SID imposition) | supported by the head-end (the node performing the SID imposition) | |||
may occur. | may occur. | |||
The presence of this information also may inform an attacker of how | The presence of this information may also inform an attacker of how | |||
to induce any of the aforementioned conditions. | to induce any of the aforementioned conditions. | |||
8. Contributors | 8. References | |||
The following people contributed to this document: | ||||
Peter Psenak | ||||
Email: ppsenak@cisco.com | ||||
9. Acknowledgements | ||||
The authors would like to thank Acee Lindem, Ketan Talaulikar, | ||||
Stephane Litkowski and Bruno Decraene for their reviews and valuable | ||||
comments. | ||||
10. References | 8.1. Normative References | |||
10.1. Normative References | ||||
[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>. | |||
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | |||
Label Switching Architecture", RFC 3031, | Label Switching Architecture", RFC 3031, | |||
DOI 10.17487/RFC3031, January 2001, | DOI 10.17487/RFC3031, January 2001, | |||
<https://www.rfc-editor.org/info/rfc3031>. | <https://www.rfc-editor.org/info/rfc3031>. | |||
skipping to change at page 9, line 39 ¶ | skipping to change at page 9, line 28 ¶ | |||
[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>. | |||
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., | [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., | |||
Decraene, B., Litkowski, S., and R. Shakir, "Segment | Decraene, B., Litkowski, S., and R. Shakir, "Segment | |||
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, | Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, | |||
July 2018, <https://www.rfc-editor.org/info/rfc8402>. | July 2018, <https://www.rfc-editor.org/info/rfc8402>. | |||
10.2. Informative References | 8.2. Informative References | |||
[I-D.ietf-idr-bgp-ls-segment-routing-msd] | ||||
Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, | ||||
"Signaling MSD (Maximum SID Depth) using Border Gateway | ||||
Protocol Link-State", draft-ietf-idr-bgp-ls-segment- | ||||
routing-msd-02 (work in progress), August 2018. | ||||
[I-D.ietf-isis-mpls-elc] | [ELC-ISIS] Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. | |||
Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. | ||||
Litkowski, "Signaling Entropy Label Capability and Entropy | Litkowski, "Signaling Entropy Label Capability and Entropy | |||
Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- | Readable Label Depth Using IS-IS", Work in Progress, | |||
elc-06 (work in progress), September 2018. | draft-ietf-isis-mpls-elc-06, September 2018. | |||
[I-D.ietf-pce-segment-routing] | [MSD-BGP] Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, | |||
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., | "Signaling MSD (Maximum SID Depth) using Border Gateway | |||
Protocol Link-State", Work in Progress, draft-ietf-idr- | ||||
bgp-ls-segment-routing-msd-02, August 2018. | ||||
[PCEP-EXT] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., | ||||
and J. Hardwick, "PCEP Extensions for Segment Routing", | and J. Hardwick, "PCEP Extensions for Segment Routing", | |||
draft-ietf-pce-segment-routing-12 (work in progress), June | Work in Progress, draft-ietf-pce-segment-routing-13, | |||
2018. | October 2018. | |||
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and | [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and | |||
S. Ray, "North-Bound Distribution of Link-State and | S. Ray, "North-Bound Distribution of Link-State and | |||
Traffic Engineering (TE) Information Using BGP", RFC 7752, | Traffic Engineering (TE) Information Using BGP", RFC 7752, | |||
DOI 10.17487/RFC7752, March 2016, | DOI 10.17487/RFC7752, March 2016, | |||
<https://www.rfc-editor.org/info/rfc7752>. | <https://www.rfc-editor.org/info/rfc7752>. | |||
Acknowledgements | ||||
The authors would like to thank Acee Lindem, Ketan Talaulikar, | ||||
Stephane Litkowski, and Bruno Decraene for their reviews and valuable | ||||
comments. | ||||
Contributors | ||||
The following people contributed to this document: | ||||
Peter Psenak | ||||
Email: ppsenak@cisco.com | ||||
Authors' Addresses | Authors' Addresses | |||
Jeff Tantsura | Jeff Tantsura | |||
Apstra, Inc. | Apstra, Inc. | |||
Email: jefftant.ietf@gmail.com | Email: jefftant.ietf@gmail.com | |||
Uma Chunduri | Uma Chunduri | |||
Huawei Technologies | Huawei Technologies | |||
Email: uma.chunduri@huawei.com | Email: uma.chunduri@huawei.com | |||
Sam Aldrin | Sam Aldrin | |||
Google, Inc | Google, Inc. | |||
Email: aldrin.ietf@gmail.com | Email: aldrin.ietf@gmail.com | |||
Les Ginsberg | Les Ginsberg | |||
Cisco Systems | Cisco Systems | |||
Email: ginsberg@cisco.com | Email: ginsberg@cisco.com | |||
End of changes. 66 change blocks. | ||||
194 lines changed or deleted | 185 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/ |