rfc9884.original | rfc9884.txt | |||
---|---|---|---|---|
MPLS Working Group X. Min | Internet Engineering Task Force (IETF) X. Min | |||
Internet-Draft S. Peng | Request for Comments: 9884 S. Peng | |||
Intended status: Standards Track ZTE Corp. | Category: Standards Track ZTE Corp. | |||
Expires: 8 December 2025 L. Gong | ISSN: 2070-1721 L. Gong | |||
China Mobile | China Mobile | |||
R. Gandhi | R. Gandhi | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
C. Pignataro | C. Pignataro | |||
Blue Fern Consulting | Blue Fern Consulting | |||
6 June 2025 | October 2025 | |||
Label Switched Path Ping for Segment Routing Path Segment Identifier | A Label Switched Path Ping for the Segment Routing Path Segment | |||
with MPLS Data Plane | Identifier with an MPLS Data Plane | |||
draft-ietf-mpls-spring-lsp-ping-path-sid-13 | ||||
Abstract | Abstract | |||
Segment Routing (SR) leverages source routing to steer packets | Segment Routing (SR) leverages source routing to steer packets | |||
through an ordered list of instructions, called segments. SR can be | through an ordered list of instructions called "segments". SR can be | |||
instantiated over the MPLS data plane. Path Segment Identifiers | instantiated over the MPLS data plane. Path Segment Identifiers | |||
(PSIDs) are used to identify and correlate bidirectional or end-to- | (PSIDs) are used to identify and correlate bidirectional or end-to- | |||
end paths in Segment Routing networks. This document defines | end paths in Segment Routing networks. This document defines | |||
procedures (i.e. six new Target forwarding Equivalence Class (FEC) | procedures (i.e., six new Target Forwarding Equivalence Class (FEC) | |||
Stack sub-TLVs) for the use of LSP Ping to support connectivity | Stack sub-TLVs) for the use of LSP Ping to support connectivity | |||
verification and fault isolation for SR paths that include Path | verification and fault isolation for SR paths that include Path | |||
Segment Identifiers. The mechanisms described enable the validation | Segment Identifiers. The mechanisms described enable the validation | |||
and tracing of SR paths with Path SIDs in MPLS networks, | and tracing of SR paths with Path SIDs in MPLS networks, | |||
complementing existing SR-MPLS OAM capabilities. | complementing existing SR-MPLS Operations, Administration, and | |||
Maintenance (OAM) capabilities. | ||||
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 8 December 2025. | 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/rfc9884. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2025 IETF Trust and the persons identified as the | Copyright (c) 2025 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction | |||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Conventions | |||
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.1. Requirements Language | |||
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.2. Terminology | |||
3. Path Segment ID Sub-TLVs . . . . . . . . . . . . . . . . . . 4 | 3. Path Segment ID Sub-TLVs | |||
3.1. SR Policy Associated PSID - IPv4 Sub-TLV . . . . . . . . 5 | 3.1. SR Policy Associated PSID - IPv4 Sub-TLV | |||
3.2. SR Candidate Path Associated PSID - IPv4 Sub-TLV . . . . 6 | 3.2. SR Candidate Path Associated PSID - IPv4 Sub-TLV | |||
3.3. SR Segment List Associated PSID - IPv4 Sub-TLV . . . . . 8 | 3.3. SR Segment List Associated PSID - IPv4 Sub-TLV | |||
3.4. SR Policy Associated PSID - IPv6 Sub-TLV . . . . . . . . 10 | 3.4. SR Policy Associated PSID - IPv6 Sub-TLV | |||
3.5. SR Candidate Path Associated PSID - IPv6 Sub-TLV . . . . 11 | 3.5. SR Candidate Path Associated PSID - IPv6 Sub-TLV | |||
3.6. SR Segment List Associated PSID - IPv6 Sub-TLV . . . . . 13 | 3.6. SR Segment List Associated PSID - IPv6 Sub-TLV | |||
4. PSID FEC Validation . . . . . . . . . . . . . . . . . . . . . 15 | 4. PSID FEC Validation | |||
4.1. PSID FEC Validation Rules . . . . . . . . . . . . . . . . 15 | 4.1. PSID FEC Validation Rules | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 5. Security Considerations | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 6. IANA Considerations | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 | 7. References | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 7.1. Normative References | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 | 7.2. Informative References | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 21 | Acknowledgements | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
A Path Segment is a local segment [RFC9545] that uniquely identifies | A Path Segment is a local segment [RFC9545] that uniquely identifies | |||
an SR path on the egress node. A Path Segment Identifier (PSID) is a | an SR path on the egress node. A Path Segment Identifier (PSID) is a | |||
single label that is assigned from the Segment Routing Local Block | single label that is assigned from the Segment Routing Local Block | |||
(SRLB) [RFC8402] of the egress node of an SR path. | (SRLB) [RFC8402] of the egress node of an SR path. | |||
As specified in [RFC9545], PSID is a single label inserted by the | As specified in [RFC9545], PSID is a single label inserted by the | |||
ingress node of the SR path, and then processed by the egress node of | ingress node of the SR path and then processed by the egress node of | |||
the SR path. The PSID is placed within the MPLS label stack as a | the SR path. The PSID is placed within the MPLS label stack as a | |||
label immediately following the last label of the SR path. The | label immediately following the last label of the SR path. The | |||
egress node pops the PSID. | egress node pops the PSID. | |||
Procedure for LSP Ping [RFC8029] as defined in Section 7.4 of | The procedure for LSP Ping [RFC8029] as defined in Section 7.4 of | |||
[RFC8287] is also applicable to PSID, and this document appends | [RFC8287] is also applicable to PSID; this document appends the | |||
existing step 4a with a new step 4b specific to PSID. Concretely, | existing step 4a with a new step 4b specific to PSID. Concretely, | |||
LSP Ping can be used to check the correct operation of a PSID and | LSP Ping can be used to check the correct operation of a PSID and | |||
verify the PSID against the control plane. Checking correct | verify the PSID against the control plane. Checking correct | |||
operation means that an initiator can use LSP Ping to check whether a | operation means that an initiator can use LSP Ping to check whether a | |||
PSID reached the intended node and got processed by that node | PSID reached the intended node and got processed by that node | |||
correctly. Moreover, verifying a PSID against the control plane | correctly. Moreover, verifying a PSID against the control plane | |||
means that the initiator can use LSP Ping to verify the SR Path | means that the initiator can use LSP Ping to verify the SR Path | |||
context (segment-list, candidate path, or SR policy) associated with | context (segment-list, candidate path, or SR policy) associated with | |||
the PSID as signaled or provisioned at the egress node. To that end, | the PSID as signaled or provisioned at the egress node. To that end, | |||
this document specifies six new Target Forwarding Equivalence Class | this document specifies six new Target Forwarding Equivalence Class | |||
skipping to change at page 3, line 34 ¶ | skipping to change at line 119 ¶ | |||
LSP Traceroute [RFC8287] is left out of this document because transit | LSP Traceroute [RFC8287] is left out of this document because transit | |||
nodes are not involved in PSID processing. | nodes are not involved in PSID processing. | |||
2. Conventions | 2. Conventions | |||
2.1. Requirements Language | 2.1. 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.2. Terminology | 2.2. Terminology | |||
This document uses the terminology defined in [RFC3031], [RFC8402], | This document uses the terminology defined in [RFC3031], [RFC8402], | |||
[RFC8029], and [RFC9545], readers are expected to be familiar with | [RFC8029], and [RFC9545]; readers are expected to be familiar with | |||
those terms. | the terms in those documents. | |||
This document introduces the following additional term: | ||||
Segment-List-ID | Segment-List-ID | |||
The Segment-List-ID field is a 4-octet identifier that uniquely | The Segment-List-ID field is a 4-octet identifier that uniquely | |||
identifies a segment list within the context of the candidate path | identifies a segment list within the context of the candidate path | |||
of an SR Policy. Although not defined in [RFC9256], the Segment- | of an SR Policy. Although not defined in [RFC9256], the Segment- | |||
List-ID is the same identifier as the one that can be signalled | List-ID is the same identifier as the one that can be signaled | |||
through control plane procotols including BGP (Section 2.1 of | through control plane protocols including Border Gateway Protocol | |||
[I-D.ietf-idr-sr-policy-seglist-id], PCEP (Section 5.2 of | (BGP) (Section 2.1 of [SR-SEGLIST-ID], Path Computation Element | |||
[I-D.ietf-pce-multipath]), and BGP-LS (Section 5.7.4 of | Communication Protocol (PCEP) (Section 5.2 of [PCE-MULTIPATH]), | |||
[I-D.ietf-idr-bgp-ls-sr-policy]). | and Border Gateway Protocol - Link State (BGP-LS) (Section 5.7.4 | |||
of [RFC9857]). | ||||
3. Path Segment ID Sub-TLVs | 3. Path Segment ID Sub-TLVs | |||
Analogous to what's defined in Section 5 of [RFC8287] and Section 4 | Analogous to what's defined in Section 5 of [RFC8287] and Section 4 | |||
of [RFC9703], six new sub-TLVs are defined for the Target FEC Stack | of [RFC9703], six new sub-TLVs are defined for the Target FEC Stack | |||
TLV (Type 1), the Reverse-Path Target FEC Stack TLV (Type 16), and | TLV (Type 1), the Reverse-Path Target FEC Stack TLV (Type 16), and | |||
the Reply Path TLV (Type 21). Note that the structures of the six | the Reply Path TLV (Type 21). Note that the structures of the six | |||
new sub-TLVs follow the TLV's structure defined in Section 3 of | new sub-TLVs follow the TLV's structure defined in Section 3 of | |||
[RFC8029]. | [RFC8029]. | |||
+==========+==========================================+ | +==========+==========================================+ | |||
| Sub-Type | Sub-TLV Name | | | Sub-Type | Sub-TLV Name | | |||
+==========+==========================================+ | +==========+==========================================+ | |||
| TBD1 | SR Policy Associated PSID - IPv4 | | | 49 | SR Policy Associated PSID - IPv4 | | |||
+----------+------------------------------------------+ | +----------+------------------------------------------+ | |||
| TBD2 | SR Candidate Path Associated PSID - IPv4 | | | 50 | SR Candidate Path Associated PSID - IPv4 | | |||
+----------+------------------------------------------+ | +----------+------------------------------------------+ | |||
| TBD3 | SR Segment List Associated PSID - IPv4 | | | 51 | SR Segment List Associated PSID - IPv4 | | |||
+----------+------------------------------------------+ | +----------+------------------------------------------+ | |||
| TBD4 | SR Policy Associated PSID - IPv6 | | | 52 | SR Policy Associated PSID - IPv6 | | |||
+----------+------------------------------------------+ | +----------+------------------------------------------+ | |||
| TBD5 | SR Candidate Path Associated PSID - IPv6 | | | 53 | SR Candidate Path Associated PSID - IPv6 | | |||
+----------+------------------------------------------+ | +----------+------------------------------------------+ | |||
| TBD6 | SR Segment List Associated PSID - IPv6 | | | 54 | SR Segment List Associated PSID - IPv6 | | |||
+----------+------------------------------------------+ | +----------+------------------------------------------+ | |||
Table 1: Sub-TLVs for PSID Checks | Table 1: Sub-TLVs for PSID Checks | |||
As specified in Section 2 of [RFC9545], a PSID is used to identify a | As specified in Section 2 of [RFC9545], a PSID is used to identify a | |||
segment list, some or all segment lists in a Candidate path or an SR | segment list and/or some or all segment lists in a Candidate path or | |||
policy, so six different Target FEC Stack sub-TLVs need to be defined | an SR policy, so six different Target FEC Stack sub-TLVs need to be | |||
for PSID. The ordered list of selection rules for the six Target FEC | defined for PSID. The ordered list of selection rules for the six | |||
Stack sub-TLVs are defined as follows: | Target FEC Stack sub-TLVs are defined as follows: | |||
* When a PSID is used to identify all segment lists in an SR Policy, | * When a PSID is used to identify all segment lists in an SR Policy, | |||
the Target FEC Stack sub-TLV of the type "SR Policy Associated | the Target FEC Stack sub-TLV of the type "SR Policy Associated | |||
PSID" (for IPv4 or IPv6) MUST be used for PSID checks. | PSID" (for IPv4 or IPv6) MUST be used for PSID checks. | |||
* When a PSID is used to identify all segment lists in an SR | * When a PSID is used to identify all segment lists in an SR | |||
Candidate Path, the Target FEC Stack sub-TLV of the type "SR | Candidate Path, the Target FEC Stack sub-TLV of the type "SR | |||
Candidate Path Associated PSID" (for IPv4 or IPv6) MUST be used | Candidate Path Associated PSID" (for IPv4 or IPv6) MUST be used | |||
for PSID checks. | for PSID checks. | |||
skipping to change at page 5, line 24 ¶ | skipping to change at line 198 ¶ | |||
* When a PSID is used to identify some segment lists in a Candidate | * When a PSID is used to identify some segment lists in a Candidate | |||
path or an SR policy, the Target FEC Stack sub-TLV of the type "SR | path or an SR policy, the Target FEC Stack sub-TLV of the type "SR | |||
Segment List Associated PSID" (for IPv4 or IPv6) MUST be used for | Segment List Associated PSID" (for IPv4 or IPv6) MUST be used for | |||
PSID checks. In this case, multiple LSP Ping messages MUST be | PSID checks. In this case, multiple LSP Ping messages MUST be | |||
sent, and one Target FEC Stack sub-TLV of the type "SR Segment | sent, and one Target FEC Stack sub-TLV of the type "SR Segment | |||
List Associated PSID" (for IPv4 or IPv6) MUST be carried in each | List Associated PSID" (for IPv4 or IPv6) MUST be carried in each | |||
LSP Ping message. | LSP Ping message. | |||
These six new Target FEC Stack sub-TLVs are not expected to be | These six new Target FEC Stack sub-TLVs are not expected to be | |||
present in the same message. If more than one of these sub-TLVs are | present in the same message. If more than one of these sub-TLVs are | |||
present in a message, only the first sub-TLV will be processed per | present in a message, only the first sub-TLV will be processed, per | |||
the validation rules in Section 4. | the validation rules in Section 4. | |||
3.1. SR Policy Associated PSID - IPv4 Sub-TLV | 3.1. SR Policy Associated PSID - IPv4 Sub-TLV | |||
The SR Policy Associated PSID - IPv4 sub-TLV is defined as follows: | The SR Policy Associated PSID - IPv4 sub-TLV is defined as follows: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type = TBD1 | Length | | | Type = 49 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Headend (4 octets) | | | Headend (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Color (4 octets) | | | Color (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Endpoint (4 octets) | | | Endpoint (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: SR Policy Associated PSID - IPv4 sub-TLV Format | Figure 1: SR Policy Associated PSID - IPv4 Sub-TLV Format | |||
Type (length: 2 octets) | Type (length: 2 octets) | |||
The Type field identifies the sub-TLV as an SR Policy Associated | The Type field identifies the sub-TLV as an SR Policy Associated | |||
PSID - IPv4 Sub-TLV. The value is set to (TBD1) and is to be | PSID - IPv4 sub-TLV. The value is set to 49. | |||
assigned by IANA. | ||||
Length (length: 2 octets) | Length (length: 2 octets) | |||
The Length field indicates the length of the sub-TLV in octets, | The Length field indicates the length of the sub-TLV in octets, | |||
excluding the first 4 octets (Type and Length fields). The value | excluding the first 4 octets (Type and Length fields). The value | |||
MUST be set to 12. | MUST be set to 12. | |||
Headend (length: 4 octets) | Headend (length: 4 octets) | |||
The Headend field encodes the headend IPv4 address of the SR | The Headend field encodes the headend IPv4 address of the SR | |||
Policy. This field is defined in Section 2.1 of [RFC9256]. | Policy. This field is defined in Section 2.1 of [RFC9256]. | |||
Color (length: 4 octets) | Color (length: 4 octets) | |||
The Color field identifies the color (i.e., policy identifier) of | The Color field identifies the color (i.e., policy identifier) of | |||
the SR Policy and is encoded as defined in Section 2.1 of | the SR Policy and is encoded as defined in Section 2.1 of | |||
[RFC9256]. | [RFC9256]. | |||
Endpoint (length: 4 octets) | Endpoint (length: 4 octets) | |||
The Endpoint field encodes the endpoint IPv4 address of the SR | The Endpoint field encodes the endpoint IPv4 address of the SR | |||
Policy. This field is defined in Section 2.1 of [RFC9256]. | Policy. This field is defined in Section 2.1 of [RFC9256]. | |||
3.2. SR Candidate Path Associated PSID - IPv4 Sub-TLV | 3.2. SR Candidate Path Associated PSID - IPv4 Sub-TLV | |||
The SR Candidate Path Associated PSID - IPv4 sub-TLV is defined as | The SR Candidate Path Associated PSID - IPv4 sub-TLV is defined as | |||
follows: | follows: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type = TBD2 | Length | | | Type = 50 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Headend (4 octets) | | | Headend (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Color (4 octets) | | | Color (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Endpoint (4 octets) | | | Endpoint (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|Protocol-Origin| Reserved | | |Protocol-Origin| Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| | | | | | |||
| Originator (20 octets) | | | Originator (20 octets) | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Discriminator (4 octets) | | | Discriminator (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: SR Candidate Path Associated PSID - IPv4 sub-TLV Format | ||||
Type (length: 2 octets) | Figure 2: SR Candidate Path Associated PSID - IPv4 Sub-TLV Format | |||
Type (length: 2 octets) | ||||
The Type field identifies the sub-TLV as an SR Candidate Path | The Type field identifies the sub-TLV as an SR Candidate Path | |||
Associated PSID - IPv4 sub-TLV. The value is set to (TBD2) and is | Associated PSID - IPv4 sub-TLV. The value is set to 50. | |||
to be assigned by IANA. | ||||
Length (length: 2 octets) | Length (length: 2 octets) | |||
The Length field indicates the length of the sub-TLV in octets, | The Length field indicates the length of the sub-TLV in octets, | |||
excluding the first 4 octets (Type and Length fields). The value | excluding the first 4 octets (Type and Length fields). The value | |||
MUST be set to 40. | MUST be set to 40. | |||
Headend (length: 4 octets) | Headend (length: 4 octets) | |||
The Headend field encodes the headend IPv4 address of the SR | The Headend field encodes the headend IPv4 address of the SR | |||
Candidate Path. This field is defined in Section 2.1 of | Candidate Path. This field is defined in Section 2.1 of | |||
[RFC9256]. | [RFC9256]. | |||
Color (length: 4 octets) | Color (length: 4 octets) | |||
The Color field identifies the policy color and is defined in | The Color field identifies the policy color and is defined in | |||
Section 2.1 of [RFC9256]. | Section 2.1 of [RFC9256]. | |||
Endpoint (length: 4 octets) | Endpoint (length: 4 octets) | |||
The Endpoint field encodes the endpoint IPv4 address of the SR | The Endpoint field encodes the endpoint IPv4 address of the SR | |||
Candidate Path. This field is defined in Section 2.1 of | Candidate Path. This field is defined in Section 2.1 of | |||
[RFC9256]. | [RFC9256]. | |||
Protocol-Origin (length: 1 octet) | Protocol-Origin (length: 1 octet) | |||
The Protocol-Origin field indicates the protocol that originated | The Protocol-Origin field indicates the protocol that originated | |||
the SR Candidate Path. It is defined in Section 2.3 of [RFC9256] | the SR Candidate Path. It is defined in Section 2.3 of [RFC9256] | |||
and takes values from the IANA registry [PROTOCOL-ORIGIN]. If an | and takes values from the IANA registry [PROTOCOL-ORIGIN]. If an | |||
unsupported value is used, validation at the responder MUST fail. | unsupported value is used, validation at the responder MUST fail. | |||
Reserved (length: 3 octets) | Reserved (length: 3 octets) | |||
The Reserved field is reserved for future use. It MUST be set to | The Reserved field is reserved for future use. It MUST be set to | |||
zero when sent and MUST be ignored upon receipt. | zero when sent and MUST be ignored upon receipt. | |||
Originator (length: 20 octets) | Originator (length: 20 octets) | |||
The Originator field identifies the originator of the SR Candidate | The Originator field identifies the originator of the SR Candidate | |||
Path and is encoded as defined in Section 2.4 of [RFC9256]. | Path and is encoded as defined in Section 2.4 of [RFC9256]. | |||
Discriminator (length: 4 octets) | Discriminator (length: 4 octets) | |||
The Discriminator field uniquely identifies the SR Candidate Path | The Discriminator field uniquely identifies the SR Candidate Path | |||
within the context of the Headend, Color, and Endpoint. This | within the context of the Headend, Color, and Endpoint fields. | |||
field is defined in Section 2.5 of [RFC9256]. | This field is defined in Section 2.5 of [RFC9256]. | |||
3.3. SR Segment List Associated PSID - IPv4 Sub-TLV | 3.3. SR Segment List Associated PSID - IPv4 Sub-TLV | |||
The SR Segment List Associated PSID - IPv4 sub-TLV is used to | The SR Segment List Associated PSID - IPv4 sub-TLV is used to | |||
identify a specific segment list within the context of a candidate | identify a specific segment list within the context of a candidate | |||
path of an SR Policy. The format of this sub-TLV is shown in | path of an SR Policy. The format of this sub-TLV is shown in | |||
Figure 3. | Figure 3. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type = TBD3 | Length | | | Type = 51 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Headend (4 octets) | | | Headend (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Color (4 octets) | | | Color (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Endpoint (4 octets) | | | Endpoint (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|Protocol-Origin| Reserved | | |Protocol-Origin| Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| | | | | | |||
| Originator (20 octets) | | | Originator (20 octets) | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Discriminator (4 octets) | | | Discriminator (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Segment-List-ID (4 octets) | | | Segment-List-ID (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 3: SR Segment List Associated PSID - IPv4 sub-TLV Format | Figure 3: SR Segment List Associated PSID - IPv4 Sub-TLV Format | |||
Type (length: 2 octets) | Type (length: 2 octets) | |||
The Type field identifies the sub-TLV as an SR Segment List | The Type field identifies the sub-TLV as an SR Segment List | |||
Associated PSID - IPv4 sub-TLV. The value is set to (TBD3) and is | Associated PSID - IPv4 sub-TLV. The value is set to 51. | |||
to be assigned by IANA. | ||||
Length (length: 2 octets) | Length (length: 2 octets) | |||
The Length field indicates the length of the sub-TLV in octets, | The Length field indicates the length of the sub-TLV in octets, | |||
excluding the first 4 octets (Type and Length fields). The value | excluding the first 4 octets (Type and Length fields). The value | |||
MUST be set to 44. | MUST be set to 44. | |||
Headend (length: 4 octets) | Headend (length: 4 octets) | |||
The Headend field encodes the headend IPv4 address of the SR | The Headend field encodes the headend IPv4 address of the SR | |||
Policy. This field is defined in Section 2.1 of [RFC9256]. | Policy. This field is defined in Section 2.1 of [RFC9256]. | |||
Color (length: 4 octets) | Color (length: 4 octets) | |||
The Color field identifies the color of the SR Policy and is | The Color field identifies the color of the SR Policy and is | |||
encoded as specified in Section 2.1 of [RFC9256]. | encoded as specified in Section 2.1 of [RFC9256]. | |||
Endpoint (length: 4 octets) | Endpoint (length: 4 octets) | |||
The Endpoint field specifies the endpoint IPv4 address of the SR | The Endpoint field specifies the endpoint IPv4 address of the SR | |||
Policy, as defined in Section 2.1 of [RFC9256]. | Policy, as defined in Section 2.1 of [RFC9256]. | |||
Protocol-Origin (length: 1 octet) | Protocol-Origin (length: 1 octet) | |||
The Protocol-Origin field indicates the protocol that originated | The Protocol-Origin field indicates the protocol that originated | |||
the SR Candidate Path. It is defined in Section 2.3 of [RFC9256] | the SR Candidate Path. It is defined in Section 2.3 of [RFC9256] | |||
and takes values from the IANA registry [PROTOCOL-ORIGIN]. If an | and takes values from the IANA registry [PROTOCOL-ORIGIN]. If an | |||
unsupported value is used, validation at the responder MUST fail. | unsupported value is used, validation at the responder MUST fail. | |||
Reserved (length: 3 octets) | Reserved (length: 3 octets) | |||
The Reserved field is reserved for future use. It MUST be set to | The Reserved field is reserved for future use. It MUST be set to | |||
zero when transmitted and MUST be ignored upon receipt. | zero when transmitted and MUST be ignored upon receipt. | |||
Originator (length: 20 octets) | Originator (length: 20 octets) | |||
The Originator field identifies the originator of the SR Candidate | The Originator field identifies the originator of the SR Candidate | |||
Path and is defined in Section 2.4 of [RFC9256]. | Path and is defined in Section 2.4 of [RFC9256]. | |||
Discriminator (length: 4 octets) | Discriminator (length: 4 octets) | |||
The Discriminator field uniquely identifies the SR Candidate Path | The Discriminator field uniquely identifies the SR Candidate Path | |||
within the context of the Headend, Color, and Endpoint. This | within the context of the Headend, Color, and Endpoint fields. | |||
field is defined in Section 2.5 of [RFC9256]. | This field is defined in Section 2.5 of [RFC9256]. | |||
Segment-List-ID (length: 4 octets) | Segment-List-ID (length: 4 octets) | |||
The Segment-List-ID field is a 4-octet identifier that uniquely | The Segment-List-ID field is a 4-octet identifier that uniquely | |||
identifies a segment list within the context of the candidate path | identifies a segment list within the context of the candidate path | |||
of an SR Policy. This field is defined in terminology of | of an SR Policy. This field is defined in Section 2.2. | |||
Section 2.2. | ||||
3.4. SR Policy Associated PSID - IPv6 Sub-TLV | 3.4. SR Policy Associated PSID - IPv6 Sub-TLV | |||
The SR Policy Associated PSID - IPv6 sub-TLV is defined as follows: | The SR Policy Associated PSID - IPv6 sub-TLV is defined as follows: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type = TBD4 | Length | | | Type = 52 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| Headend (16 octets) | | | Headend (16 octets) | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Color (4 octets) | | | Color (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| Endpoint (16 octets) | | | Endpoint (16 octets) | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 4: SR Policy Associated PSID - IPv6 sub-TLV Format | Figure 4: SR Policy Associated PSID - IPv6 Sub-TLV Format | |||
Type (length: 2 octets) | Type (length: 2 octets) | |||
The Type field identifies the sub-TLV as an SR Policy Associated | The Type field identifies the sub-TLV as an SR Policy Associated | |||
PSID - IPv6 Sub-TLV. The value is set to (TBD4) and is to be | PSID - IPv6 Sub-TLV. The value is set to 52. | |||
assigned by IANA. | ||||
Length (length: 2 octets) | Length (length: 2 octets) | |||
The Length field indicates the length of the sub-TLV in octets, | The Length field indicates the length of the sub-TLV in octets, | |||
excluding the first 4 octets (Type and Length fields). The value | excluding the first 4 octets (Type and Length fields). The value | |||
MUST be set to 36. | MUST be set to 36. | |||
Headend (length: 16 octets) | Headend (length: 16 octets) | |||
The Headend field encodes the headend IPv6 address of the SR | The Headend field encodes the headend IPv6 address of the SR | |||
Policy. This field is defined in Section 2.1 of [RFC9256]. | Policy. This field is defined in Section 2.1 of [RFC9256]. | |||
Color (length: 4 octets) | Color (length: 4 octets) | |||
The Color field identifies the color (i.e., policy identifier) of | The Color field identifies the color (i.e., policy identifier) of | |||
the SR Policy and is encoded as defined in Section 2.1 of | the SR Policy and is encoded as defined in Section 2.1 of | |||
[RFC9256]. | [RFC9256]. | |||
Endpoint (length: 16 octets) | Endpoint (length: 16 octets) | |||
The Endpoint field encodes the endpoint IPv6 address of the SR | The Endpoint field encodes the endpoint IPv6 address of the SR | |||
Policy. This field is defined in Section 2.1 of [RFC9256]. | Policy. This field is defined in Section 2.1 of [RFC9256]. | |||
3.5. SR Candidate Path Associated PSID - IPv6 Sub-TLV | 3.5. SR Candidate Path Associated PSID - IPv6 Sub-TLV | |||
The SR Candidate Path Associated PSID - IPv6 sub-TLV is defined as | The SR Candidate Path Associated PSID - IPv6 sub-TLV is defined as | |||
follows: | follows: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type = TBD5 | Length | | | Type = 53 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| Headend (16 octets) | | | Headend (16 octets) | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Color (4 octets) | | | Color (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| Endpoint (16 octets) | | | Endpoint (16 octets) | | |||
skipping to change at page 11, line 43 ¶ | skipping to change at line 469 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| | | | | | |||
| Originator (20 octets) | | | Originator (20 octets) | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Discriminator (4 octets) | | | Discriminator (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 5: SR Candidate Path Associated PSID - IPv6 sub-TLV Format | Figure 5: SR Candidate Path Associated PSID - IPv6 Sub-TLV Format | |||
Type (length: 2 octets) | Type (length: 2 octets) | |||
The Type field identifies the sub-TLV as an SR Candidate Path | The Type field identifies the sub-TLV as an SR Candidate Path | |||
Associated PSID - IPv6 sub-TLV. The value is set to (TBD5) and is | Associated PSID - IPv6 sub-TLV. The value is set to 53. | |||
to be assigned by IANA. | ||||
Length (length: 2 octets) | Length (length: 2 octets) | |||
The Length field indicates the length of the sub-TLV in octets, | The Length field indicates the length of the sub-TLV in octets, | |||
excluding the first 4 octets (Type and Length fields). The value | excluding the first 4 octets (Type and Length fields). The value | |||
MUST be set to 64. | MUST be set to 64. | |||
Headend (length: 16 octets) | Headend (length: 16 octets) | |||
The Headend field encodes the headend IPv6 address of the SR | The Headend field encodes the headend IPv6 address of the SR | |||
Candidate Path. This field is defined in Section 2.1 of | Candidate Path. This field is defined in Section 2.1 of | |||
[RFC9256]. | [RFC9256]. | |||
Color (length: 4 octets) | Color (length: 4 octets) | |||
The Color field identifies the policy color and is defined in | The Color field identifies the policy color and is defined in | |||
Section 2.1 of [RFC9256]. | Section 2.1 of [RFC9256]. | |||
Endpoint (length: 16 octets) | Endpoint (length: 16 octets) | |||
The Endpoint field encodes the endpoint IPv6 address of the SR | The Endpoint field encodes the endpoint IPv6 address of the SR | |||
Candidate Path. This field is defined in Section 2.1 of | Candidate Path. This field is defined in Section 2.1 of | |||
[RFC9256]. | [RFC9256]. | |||
Protocol-Origin (length: 1 octet) | Protocol-Origin (length: 1 octet) | |||
The Protocol-Origin field indicates the protocol that originated | The Protocol-Origin field indicates the protocol that originated | |||
the SR Candidate Path. It is defined in Section 2.3 of [RFC9256] | the SR Candidate Path. It is defined in Section 2.3 of [RFC9256] | |||
and takes values from the IANA registry [PROTOCOL-ORIGIN]. If an | and takes values from the IANA registry [PROTOCOL-ORIGIN]. If an | |||
unsupported value is used, validation at the responder MUST fail. | unsupported value is used, validation at the responder MUST fail. | |||
Reserved (length: 3 octets) | Reserved (length: 3 octets) | |||
The Reserved field is reserved for future use. It MUST be set to | The Reserved field is reserved for future use. It MUST be set to | |||
zero when sent and MUST be ignored upon receipt. | zero when sent and MUST be ignored upon receipt. | |||
Originator (length: 20 octets) | Originator (length: 20 octets) | |||
The Originator field identifies the originator of the SR Candidate | The Originator field identifies the originator of the SR Candidate | |||
Path and is encoded as defined in Section 2.4 of [RFC9256]. | Path and is encoded as defined in Section 2.4 of [RFC9256]. | |||
Discriminator (length: 4 octets) | Discriminator (length: 4 octets) | |||
The Discriminator field uniquely identifies the SR Candidate Path | The Discriminator field uniquely identifies the SR Candidate Path | |||
within the context of the Headend, Color, and Endpoint. This | within the context of the Headend, Color, and Endpoint fields. | |||
field is defined in Section 2.5 of [RFC9256]. | This field is defined in Section 2.5 of [RFC9256]. | |||
3.6. SR Segment List Associated PSID - IPv6 Sub-TLV | 3.6. SR Segment List Associated PSID - IPv6 Sub-TLV | |||
The SR Segment List Associated PSID - IPv6 sub-TLV is used to | The SR Segment List Associated PSID - IPv6 sub-TLV is used to | |||
identify a specific segment list within the context of a candidate | identify a specific segment list within the context of a candidate | |||
path of an SR Policy. The format of this sub-TLV is shown in | path of an SR Policy. The format of this sub-TLV is shown in | |||
Figure 6. | Figure 6. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type = TBD6 | Length | | | Type = 54 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| Headend (16 octets) | | | Headend (16 octets) | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Color (4 octets) | | | Color (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| Endpoint (16 octets) | | | Endpoint (16 octets) | | |||
skipping to change at page 13, line 42 ¶ | skipping to change at line 550 ¶ | |||
| | | | | | |||
| Originator (20 octets) | | | Originator (20 octets) | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Discriminator (4 octets) | | | Discriminator (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Segment-List-ID (4 octets) | | | Segment-List-ID (4 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 6: SR Segment List Associated PSID - IPv6 sub-TLV Format | Figure 6: SR Segment List Associated PSID - IPv6 Sub-TLV Format | |||
Type (length: 2 octets) | Type (length: 2 octets) | |||
The Type field identifies the sub-TLV as an SR Segment List | The Type field identifies the sub-TLV as an SR Segment List | |||
Associated PSID - IPv6 sub-TLV. The value is set to (TBD6) and is | Associated PSID - IPv6 sub-TLV. The value is set to 54. | |||
to be assigned by IANA. | ||||
Length (length: 2 octets) | Length (length: 2 octets) | |||
The Length field indicates the length of the sub-TLV in octets, | The Length field indicates the length of the sub-TLV in octets, | |||
excluding the first 4 octets (Type and Length fields). The value | excluding the first 4 octets (Type and Length fields). The value | |||
MUST be set to 68. | MUST be set to 68. | |||
Headend (length: 16 octets) | Headend (length: 16 octets) | |||
The Headend field encodes the headend IPv6 address of the SR | The Headend field encodes the headend IPv6 address of the SR | |||
Policy. This field is defined in Section 2.1 of [RFC9256]. | Policy. This field is defined in Section 2.1 of [RFC9256]. | |||
Color (length: 4 octets) | Color (length: 4 octets) | |||
The Color field identifies the color of the SR Policy and is | The Color field identifies the color of the SR Policy and is | |||
encoded as specified in Section 2.1 of [RFC9256]. | encoded as specified in Section 2.1 of [RFC9256]. | |||
Endpoint (length: 16 octets) | Endpoint (length: 16 octets) | |||
The Endpoint field specifies the endpoint IPv6 address of the SR | The Endpoint field specifies the endpoint IPv6 address of the SR | |||
Policy, as defined in Section 2.1 of [RFC9256]. | Policy, as defined in Section 2.1 of [RFC9256]. | |||
Protocol-Origin (length: 1 octet) | Protocol-Origin (length: 1 octet) | |||
The Protocol-Origin field indicates the protocol that originated | The Protocol-Origin field indicates the protocol that originated | |||
the SR Candidate Path. It is defined in Section 2.3 of [RFC9256] | the SR Candidate Path. It is defined in Section 2.3 of [RFC9256] | |||
and takes values from the IANA registry [PROTOCOL-ORIGIN]. If an | and takes values from the IANA registry [PROTOCOL-ORIGIN]. If an | |||
unsupported value is used, validation at the responder MUST fail. | unsupported value is used, validation at the responder MUST fail. | |||
Reserved (length: 3 octets) | Reserved (length: 3 octets) | |||
The Reserved field is reserved for future use. It MUST be set to | The Reserved field is reserved for future use. It MUST be set to | |||
zero when transmitted and MUST be ignored upon receipt. | zero when transmitted and MUST be ignored upon receipt. | |||
Originator (length: 20 octets) | Originator (length: 20 octets) | |||
The Originator field identifies the originator of the SR Candidate | The Originator field identifies the originator of the SR Candidate | |||
Path and is defined in Section 2.4 of [RFC9256]. | Path and is defined in Section 2.4 of [RFC9256]. | |||
Discriminator (length: 4 octets) | Discriminator (length: 4 octets) | |||
The Discriminator field uniquely identifies the SR Candidate Path | The Discriminator field uniquely identifies the SR Candidate Path | |||
within the context of the Headend, Color, and Endpoint. This | within the context of the Headend, Color, and Endpoint fields. | |||
field is defined in Section 2.5 of [RFC9256]. | This field is defined in Section 2.5 of [RFC9256]. | |||
Segment-List-ID (length: 4 octets) | Segment-List-ID (length: 4 octets) | |||
The Segment-List-ID field is a 4-octet identifier that uniquely | The Segment-List-ID field is a 4-octet identifier that uniquely | |||
identifies a segment list within the context of the candidate path | identifies a segment list within the context of the candidate path | |||
of an SR Policy. This field is defined in terminology of | of an SR Policy. This field is defined in Section 2.2. | |||
Section 2.2. | ||||
4. PSID FEC Validation | 4. PSID FEC Validation | |||
The MPLS LSP Ping procedures may be initiated by the headend of the | The MPLS LSP Ping procedures may be initiated by the headend of the | |||
Segment Routing path or a centralized topology-aware data plane | Segment Routing path or a centralized topology-aware data plane | |||
monitoring system as described in [RFC8403]. For the PSID, the | monitoring system as described in [RFC8403]. For the PSID, the | |||
responder nodes that receive echo request and send echo reply MUST be | responder nodes that receive an echo request and sends an echo reply | |||
the endpoint of the SR path. | MUST be the endpoint of the SR path. | |||
When an endpoint receives the LSP echo request packet with top FEC | When an endpoint receives the LSP echo request packet with the top | |||
being the PSID, it MUST perform validity checks on the content of the | FEC being the PSID, it MUST perform validity checks on the content of | |||
PSID FEC Stack sub-TLV. | the PSID FEC Stack sub-TLV. | |||
If a malformed FEC Stack sub-TLV is received, then a return code of | If a malformed FEC Stack sub-TLV is received, then a return code of | |||
1, "Malformed echo request received" as defined in [RFC8029] MUST be | 1, "Malformed echo request received" as defined in [RFC8029] MUST be | |||
sent. The section below is appended to step 4a of Section 7.4 of | sent. The section below is appended to step 4a of Section 7.4 of | |||
[RFC8287]. | [RFC8287]. | |||
4.1. PSID FEC Validation Rules | 4.1. PSID FEC Validation Rules | |||
4b. Segment Routing PSID Validation: | 4b. Segment Routing PSID Validation: | |||
If the Label-stack-depth is 1 and the Target FEC Stack sub-TLV at | If the Label-stack-depth is 1 and the Target FEC Stack sub-TLV at | |||
FEC-stack-depth is TBD1 (SR Policy Associated PSID - IPv4 sub-TLV), { | FEC-stack-depth is 49 (SR Policy Associated PSID - IPv4 sub-TLV), { | |||
Set the Best-return-code to 10, "Mapping for this FEC is not the | Set the Best-return-code to 10 "Mapping for this FEC is not the | |||
given label at stack-depth <RSC>" if any below conditions fail | given label at stack-depth <RSC>" if any below conditions fail | |||
(the notation <RSC> refers to the Return Subcode): | (the notation <RSC> refers to the Return Subcode): | |||
- Validate that the PSID is signaled or provisioned for the SR | - Validate that the PSID is signaled or provisioned for the SR | |||
Policy { | Policy { | |||
o Validate that the signaled or provisioned headend, color, | * Validate that the signaled or provisioned headend, color, | |||
and endpoint, for the PSID, matches with the corresponding | and endpoint for the PSID match with the corresponding | |||
fields in the received SR Policy Associated PSID - IPv4 sub- | fields in the received SR Policy Associated PSID - IPv4 | |||
TLV. | sub-TLV. | |||
} | } | |||
} | } | |||
If all the above validations have passed, set the return code to 3 | If all the above validations have passed, set the return code to 3 | |||
"Replying router is an egress for the FEC at stack-depth <RSC>". | "Replying router is an egress for the FEC at stack-depth <RSC>". | |||
Set FEC-Status to 1 and return. | Set the FEC-Status to 1 and return. | |||
} | } | |||
Else, if the Label-stack-depth is 1 and the Target FEC Stack sub-TLV | Else, if the Label-stack-depth is 1 and the Target FEC Stack sub-TLV | |||
at FEC-stack-depth is TBD2 (SR Candidate Path Associated PSID - IPv4 | at FEC-stack-depth is 50 (SR Candidate Path Associated PSID - IPv4 | |||
sub-TLV), { | sub-TLV), { | |||
Set the Best-return-code to 10, "Mapping for this FEC is not the | Set the Best-return-code to 10 "Mapping for this FEC is not the | |||
given label at stack-depth <RSC>" if any below conditions fail: | given label at stack-depth <RSC>" if any below conditions fail: | |||
- Validate that the PSID is signaled or provisioned for the SR | - Validate that the PSID is signaled or provisioned for the SR | |||
Candidate Path { | Candidate Path { | |||
o Validate that the signaled or provisioned headend, color, | * Validate that the signaled or provisioned headend, color, | |||
endpoint, originator, and discriminator, for the PSID, | endpoint, originator, and discriminator for the PSID | |||
matches with the corresponding fields in the received SR | match with the corresponding fields in the received SR | |||
Candidate Path Associated PSID - IPv4 sub-TLV. | Candidate Path Associated PSID - IPv4 sub-TLV. | |||
} | } | |||
} | } | |||
If all the above validations have passed, set the return code to 3 | If all the above validations have passed, set the return code to 3 | |||
"Replying router is an egress for the FEC at stack-depth <RSC>". | "Replying router is an egress for the FEC at stack-depth <RSC>". | |||
Set FEC-Status to 1 and return. | Set the FEC-Status to 1 and return. | |||
} | } | |||
Else, if the Label-stack-depth is 1 and the Target FEC Stack sub-TLV | Else, if the Label-stack-depth is 1 and the Target FEC Stack sub-TLV | |||
at FEC-stack-depth is TBD3 (SR Segment List Associated PSID - IPv4 | at FEC-stack-depth is 51 (SR Segment List Associated PSID - IPv4 | |||
sub-TLV), { | sub-TLV), { | |||
Set the Best-return-code to 10, "Mapping for this FEC is not the | Set the Best-return-code to 10 "Mapping for this FEC is not the | |||
given label at stack-depth <RSC>" if any below conditions fail: | given label at stack-depth <RSC>" if any below conditions fail: | |||
- Validate that the PSID is signaled or provisioned for the SR | - Validate that the PSID is signaled or provisioned for the SR | |||
Segment List { | Segment List { | |||
o Validate that the signaled or provisioned headend, color, | * Validate that the signaled or provisioned headend, color, | |||
endpoint, originator, discriminator, and segment-list-id, | endpoint, originator, discriminator, and segment-list-id, | |||
for the PSID, matches with the corresponding fields in the | for the PSID match with the corresponding fields in the | |||
received SR Segment List Associated PSID - IPv4 sub-TLV. | received SR Segment List Associated PSID - IPv4 sub-TLV. | |||
} | } | |||
} | } | |||
If all the above validations have passed, set the return code to 3 | If all the above validations have passed, set the return code to 3, | |||
"Replying router is an egress for the FEC at stack-depth <RSC>". | "Replying router is an egress for the FEC at stack-depth <RSC>". | |||
Set FEC-Status to 1 and return. | Set the FEC-Status to 1 and return. | |||
} | } | |||
Else, if the Label-stack-depth is 1 and the Target FEC Stack sub-TLV | Else, if the Label-stack-depth is 1 and the Target FEC Stack sub-TLV | |||
at FEC-stack-depth is TBD4 (SR Policy Associated PSID - IPv6 sub- | at FEC-stack-depth is 52 (SR Policy Associated PSID - IPv6 | |||
TLV), { | sub-TLV), { | |||
Set the Best-return-code to 10, "Mapping for this FEC is not the | Set the Best-return-code to 10 "Mapping for this FEC is not the | |||
given label at stack-depth <RSC>" if any below conditions fail | given label at stack-depth <RSC>" if any below conditions fail | |||
(the notation <RSC> refers to the Return Subcode): | (the notation <RSC> refers to the Return Subcode): | |||
- Validate that the PSID is signaled or provisioned for the SR | - Validate that the PSID is signaled or provisioned for the SR | |||
Policy { | Policy { | |||
o Validate that the signaled or provisioned headend, color, | * Validate that the signaled or provisioned headend, color, | |||
and endpoint, for the PSID, matches with the corresponding | and endpoint for the PSID match with the corresponding | |||
fields in the received SR Policy Associated PSID - IPv6 sub- | fields in the received SR Policy Associated PSID - IPv6 sub- | |||
TLV. | TLV. | |||
} | } | |||
} | } | |||
If all the above validations have passed, set the return code to 3 | If all the above validations have passed, set the return code to 3 | |||
"Replying router is an egress for the FEC at stack-depth <RSC>". | "Replying router is an egress for the FEC at stack-depth <RSC>". | |||
Set FEC-Status to 1 and return. | Set the FEC-Status to 1 and return. | |||
} | } | |||
Else, if the Label-stack-depth is 1 and the Target FEC Stack sub-TLV | Else, if the Label-stack-depth is 1 and the Target FEC Stack sub-TLV | |||
at FEC-stack-depth is TBD5 (SR Candidate Path Associated PSID - IPv6 | at FEC-stack-depth is 53 (SR Candidate Path Associated PSID - IPv6 | |||
sub-TLV), { | sub-TLV), { | |||
Set the Best-return-code to 10, "Mapping for this FEC is not the | Set the Best-return-code to 10 "Mapping for this FEC is not the | |||
given label at stack-depth <RSC>" if any below conditions fail: | given label at stack-depth <RSC>" if any below conditions fail: | |||
- Validate that the PSID is signaled or provisioned for the SR | - Validate that the PSID is signaled or provisioned for the SR | |||
Candidate Path { | Candidate Path { | |||
o Validate that the signaled or provisioned headend, color, | * Validate that the signaled or provisioned headend, color, | |||
endpoint, originator, and discriminator, for the PSID, | endpoint, originator, and discriminator for the PSID | |||
matches with the corresponding fields in the received SR | match with the corresponding fields in the received SR | |||
Candidate Path Associated PSID - IPv6 sub-TLV. | Candidate Path Associated PSID - IPv6 sub-TLV. | |||
} | } | |||
} | } | |||
If all the above validations have passed, set the return code to 3 | If all the above validations have passed, set the return code to 3 | |||
"Replying router is an egress for the FEC at stack-depth <RSC>". | "Replying router is an egress for the FEC at stack-depth <RSC>". | |||
Set FEC-Status to 1 and return. | Set the FEC-Status to 1 and return. | |||
} | } | |||
Else, if the Label-stack-depth is 1 and the Target FEC Stack sub-TLV | Else, if the Label-stack-depth is 1 and the Target FEC Stack sub-TLV | |||
at FEC-stack-depth is TBD6 (SR Segment List Associated PSID - IPv6 | at FEC-stack-depth is 54 (SR Segment List Associated PSID - IPv6 | |||
sub-TLV), { | sub-TLV), { | |||
Set the Best-return-code to 10, "Mapping for this FEC is not the | Set the Best-return-code to 10 "Mapping for this FEC is not the | |||
given label at stack-depth <RSC>" if any below conditions fail: | given label at stack-depth <RSC>" if any below conditions fail: | |||
- Validate that the PSID is signaled or provisioned for the SR | - Validate that the PSID is signaled or provisioned for the SR | |||
Segment List { | Segment List { | |||
o Validate that the signaled or provisioned headend, color, | * Validate that the signaled or provisioned headend, color, | |||
endpoint, originator, discriminator, and segment-list-id, | endpoint, originator, discriminator, and segment-list-id | |||
for the PSID, matches with the corresponding fields in the | for the PSID match with the corresponding fields in the | |||
received SR Segment List Associated PSID - IPv6 sub-TLV. | received SR Segment List Associated PSID - IPv6 sub-TLV. | |||
} | } | |||
} | } | |||
If all the above validations have passed, set the return code to 3 | If all the above validations have passed, set the return code to 3 | |||
"Replying router is an egress for the FEC at stack-depth <RSC>". | "Replying router is an egress for the FEC at stack-depth <RSC>". | |||
Set FEC-Status to 1 and return. | Set the FEC-Status to 1 and return. | |||
} | } | |||
When an SR Policy Associated PSID - IPv4 sub-TLV, or an SR Candidate | When any of the following is carried in a Reverse-Path Target FEC | |||
Path Associated PSID - IPv4 sub-TLV, or an SR Segment List Associated | Stack TLV (Type 16) or Reply Path TLV (Type 21), it MUST be sent by | |||
PSID - IPv4 sub-TLV, or an SR Policy Associated PSID - IPv6 sub-TLV, | an endpoint in an echo reply. | |||
or an SR Candidate Path Associated PSID - IPv6 sub-TLV, or an SR | ||||
Segment List Associated PSID - IPv6 sub-TLV is carried in Reverse- | * SR Policy Associated PSID - IPv4 sub-TLV, | |||
Path Target FEC Stack TLV (Type 16) or Reply Path TLV (Type 21), it | ||||
MUST be sent by an endpoint in an echo reply. The headend MUST | * SR Candidate Path Associated PSID - IPv4 sub-TLV, | |||
perform validity checks as described above without setting the return | ||||
code. If any of the validations fail, then the headend MUST drop the | * SR Segment List Associated PSID - IPv4 sub-TLV, | |||
echo reply and SHOULD log and/or report an error. | ||||
* SR Policy Associated PSID - IPv6 sub-TLV, | ||||
* SR Candidate Path Associated PSID - IPv6 sub-TLV, or | ||||
* SR Segment List Associated PSID - IPv6 sub-TLV | ||||
The headend MUST perform validity checks as described above without | ||||
setting the return code. If any of the validations fail, then the | ||||
headend MUST drop the echo reply and SHOULD log and/or report an | ||||
error. | ||||
5. Security Considerations | 5. Security Considerations | |||
This document defines additional MPLS LSP Ping sub-TLVs and follows | This document defines additional MPLS LSP Ping sub-TLVs and follows | |||
the mechanisms defined in [RFC8029]. All the security considerations | the mechanisms defined in [RFC8029]. All the security considerations | |||
defined in Section 5 of [RFC8029] apply to this document. The MPLS | defined in Section 5 of [RFC8029] apply to this document. The MPLS | |||
LSP Ping sub-TLVs defined in this document do not impose any | LSP Ping sub-TLVs defined in this document do not impose any | |||
additional security challenges to be considered. | additional security challenges to be considered. | |||
6. IANA Considerations | 6. IANA Considerations | |||
IANA is requested to assign six new Target FEC Stack sub-TLVs from | IANA has assigned six Target FEC Stack sub-TLVs from the "Sub-TLVs | |||
the "Sub-TLVs for TLV Types 1, 16, and 21" registry [MPLS-LSP-PING] | for TLV Types 1, 16, and 21" registry [MPLS-LSP-PING] within the | |||
within the "TLVs" registry of the "Multiprotocol Label Switching | "TLVs" registry of the "Multiprotocol Label Switching (MPLS) Label | |||
(MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group. | Switched Paths (LSPs) Ping Parameters" registry group. The Standards | |||
The Standards Action range that requires an error message to be | Action [RFC8126] range that requires an error message to be returned | |||
returned if the sub-TLV is not recognized (range 0-16383) should be | if the sub-TLV is not recognized (range 0-16383) should be used. | |||
used. | ||||
+==========+==================================+================+ | ||||
| Sub-Type | Sub-TLV Name | Reference | | ||||
+==========+==================================+================+ | ||||
| TBD1 | SR Policy Associated PSID - IPv4 | Section 3.1 of | | ||||
| | | THIS_DOCUMENT | | ||||
+----------+----------------------------------+----------------+ | ||||
| TBD2 | SR Candidate Path Associated | Section 3.2 of | | ||||
| | PSID - IPv4 | THIS_DOCUMENT | | ||||
+----------+----------------------------------+----------------+ | ||||
| TBD3 | SR Segment List Associated PSID | Section 3.3 of | | ||||
| | - IPv4 | THIS_DOCUMENT | | ||||
+----------+----------------------------------+----------------+ | ||||
| TBD4 | SR Policy Associated PSID - IPv6 | Section 3.4 of | | ||||
| | | THIS_DOCUMENT | | ||||
+----------+----------------------------------+----------------+ | ||||
| TBD5 | SR Candidate Path Associated | Section 3.5 of | | ||||
| | PSID - IPv6 | THIS_DOCUMENT | | ||||
+----------+----------------------------------+----------------+ | ||||
| TBD6 | SR Segment List Associated PSID | Section 3.6 of | | ||||
| | - IPv6 | THIS_DOCUMENT | | ||||
+----------+----------------------------------+----------------+ | ||||
Table 2: Sub-TLVs for TLV Types 1, 16, and 21 Registry | ||||
7. Acknowledgements | ||||
The authors would like to acknowledge Loa Andersson, Detao Zhao, Ben | +==========+==================================+=============+ | |||
Niven-Jenkins, Greg Mirsky, Ketan Talaulikar, James Guichard, Jon | | Sub-Type | Sub-TLV Name | Reference | | |||
Geater, Gorry Fairhurst, Bing Liu, Mohamed Boucadair, Eric Vyncke, | +==========+==================================+=============+ | |||
Gunter Van de Velde, Mahesh Jethanandani, and Andy Smith for their | | 49 | SR Policy Associated PSID - IPv4 | Section 3.1 | | |||
thorough review and very helpful comments. | | | | of RFC 9884 | | |||
+----------+----------------------------------+-------------+ | ||||
| 50 | SR Candidate Path Associated | Section 3.2 | | ||||
| | PSID - IPv4 | of RFC 9884 | | ||||
+----------+----------------------------------+-------------+ | ||||
| 51 | SR Segment List Associated PSID | Section 3.3 | | ||||
| | - IPv4 | of RFC 9884 | | ||||
+----------+----------------------------------+-------------+ | ||||
| 52 | SR Policy Associated PSID - IPv6 | Section 3.4 | | ||||
| | | of RFC 9884 | | ||||
+----------+----------------------------------+-------------+ | ||||
| 53 | SR Candidate Path Associated | Section 3.5 | | ||||
| | PSID - IPv6 | of RFC 9884 | | ||||
+----------+----------------------------------+-------------+ | ||||
| 54 | SR Segment List Associated PSID | Section 3.6 | | ||||
| | - IPv6 | of RFC 9884 | | ||||
+----------+----------------------------------+-------------+ | ||||
The authors would like to acknowledge Yao Liu and Quan Xiong for the | Table 2: Sub-TLVs for TLV Types 1, 16, and 21 Registry | |||
very helpful face to face discussion. | ||||
8. References | 7. References | |||
8.1. Normative References | 7.1. Normative References | |||
[MPLS-LSP-PING] | [MPLS-LSP-PING] | |||
"Multi-Protocol Label Switching (MPLS) Label Switched | IANA, "Multiprotocol Label Switching (MPLS) Label Switched | |||
Paths (LSPs) Ping Parameters", | Paths (LSPs) Ping Parameters", | |||
<http://www.iana.org/assignments/mpls-lsp-ping- | <http://www.iana.org/assignments/mpls-lsp-ping- | |||
parameters>. | parameters>. | |||
[PROTOCOL-ORIGIN] | [PROTOCOL-ORIGIN] | |||
"SR Policy Protocol Origin", | IANA, "SR Policy Protocol Origin", | |||
<https://www.iana.org/assignments/segment-routing/segment- | <https://www.iana.org/assignments/segment-routing>. | |||
routing.xhtml#sr-policy-protocol-origin>. | ||||
[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>. | |||
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., | [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., | |||
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label | Aldrin, S., and M. Chen, "Detecting Multiprotocol Label | |||
Switched (MPLS) Data-Plane Failures", RFC 8029, | Switched (MPLS) Data-Plane Failures", RFC 8029, | |||
DOI 10.17487/RFC8029, March 2017, | DOI 10.17487/RFC8029, March 2017, | |||
skipping to change at page 21, line 15 ¶ | skipping to change at line 883 ¶ | |||
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, | [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, | |||
A., and P. Mattes, "Segment Routing Policy Architecture", | A., and P. Mattes, "Segment Routing Policy Architecture", | |||
RFC 9256, DOI 10.17487/RFC9256, July 2022, | RFC 9256, DOI 10.17487/RFC9256, July 2022, | |||
<https://www.rfc-editor.org/info/rfc9256>. | <https://www.rfc-editor.org/info/rfc9256>. | |||
[RFC9545] Cheng, W., Ed., Li, H., Li, C., Ed., Gandhi, R., and R. | [RFC9545] Cheng, W., Ed., Li, H., Li, C., Ed., Gandhi, R., and R. | |||
Zigler, "Path Segment Identifier in MPLS-Based Segment | Zigler, "Path Segment Identifier in MPLS-Based Segment | |||
Routing Networks", RFC 9545, DOI 10.17487/RFC9545, | Routing Networks", RFC 9545, DOI 10.17487/RFC9545, | |||
February 2024, <https://www.rfc-editor.org/info/rfc9545>. | February 2024, <https://www.rfc-editor.org/info/rfc9545>. | |||
8.2. Informative References | 7.2. Informative References | |||
[I-D.ietf-idr-bgp-ls-sr-policy] | ||||
Previdi, S., Talaulikar, K., Dong, J., Gredler, H., and J. | ||||
Tantsura, "Advertisement of Segment Routing Policies using | ||||
BGP Link-State", Work in Progress, Internet-Draft, draft- | ||||
ietf-idr-bgp-ls-sr-policy-17, 6 March 2025, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp- | ||||
ls-sr-policy-17>. | ||||
[I-D.ietf-idr-sr-policy-seglist-id] | ||||
Lin, C., Cheng, W., Liu, Y., Talaulikar, K., and M. Chen, | ||||
"BGP SR Policy Extensions for Segment List Identifier", | ||||
Work in Progress, Internet-Draft, draft-ietf-idr-sr- | ||||
policy-seglist-id-04, 27 March 2025, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr- | ||||
policy-seglist-id-04>. | ||||
[I-D.ietf-pce-multipath] | [PCE-MULTIPATH] | |||
Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., | Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., | |||
Bidgoli, H., Yadav, B., Peng, S., and G. S. Mishra, "PCEP | Bidgoli, H., Yadav, B., Peng, S., Mishra, G. S., and S. | |||
Extensions for Signaling Multipath Information", Work in | Sidor, "Path Computation Element Communication Protocol | |||
Progress, Internet-Draft, draft-ietf-pce-multipath-13, 9 | (PCEP) Extensions for Signaling Multipath Information", | |||
April 2025, <https://datatracker.ietf.org/doc/html/draft- | Work in Progress, Internet-Draft, draft-ietf-pce- | |||
ietf-pce-multipath-13>. | multipath-16, 17 October 2025, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-pce- | ||||
multipath-16>. | ||||
[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>. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | ||||
Writing an IANA Considerations Section in RFCs", BCP 26, | ||||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | ||||
<https://www.rfc-editor.org/info/rfc8126>. | ||||
[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>. | |||
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. | [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. | |||
Kumar, "A Scalable and Topology-Aware MPLS Data-Plane | Kumar, "A Scalable and Topology-Aware MPLS Data-Plane | |||
Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July | Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July | |||
2018, <https://www.rfc-editor.org/info/rfc8403>. | 2018, <https://www.rfc-editor.org/info/rfc8403>. | |||
[RFC9703] Hegde, S., Srivastava, M., Arora, K., Ninan, S., and X. | [RFC9703] Hegde, S., Srivastava, M., Arora, K., Ninan, S., and X. | |||
Xu, "Label Switched Path (LSP) Ping/Traceroute for Segment | Xu, "Label Switched Path (LSP) Ping/Traceroute for Segment | |||
Routing (SR) Egress Peer Engineering (EPE) Segment | Routing (SR) Egress Peer Engineering (EPE) Segment | |||
Identifiers (SIDs) with MPLS Data Plane", RFC 9703, | Identifiers (SIDs) with MPLS Data Plane", RFC 9703, | |||
DOI 10.17487/RFC9703, December 2024, | DOI 10.17487/RFC9703, December 2024, | |||
<https://www.rfc-editor.org/info/rfc9703>. | <https://www.rfc-editor.org/info/rfc9703>. | |||
[RFC9857] Previdi, S., Talaulikar, K., Ed., Dong, J., Gredler, H., | ||||
and J. Tantsura, "Advertisement of Segment Routing | ||||
Policies Using BGP Link State", RFC 9857, | ||||
DOI 10.17487/RFC9857, October 2025, | ||||
<https://www.rfc-editor.org/info/rfc9857>. | ||||
[SR-SEGLIST-ID] | ||||
Lin, C., Cheng, W., Liu, Y., Talaulikar, K., and M. Chen, | ||||
"BGP SR Policy Extensions for Segment List Identifier", | ||||
Work in Progress, Internet-Draft, draft-ietf-idr-sr- | ||||
policy-seglist-id-06, 24 September 2025, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr- | ||||
policy-seglist-id-06>. | ||||
Acknowledgements | ||||
The authors would like to acknowledge Loa Andersson, Detao Zhao, Ben | ||||
Niven-Jenkins, Greg Mirsky, Ketan Talaulikar, James Guichard, Jon | ||||
Geater, Gorry Fairhurst, Bing Liu, Mohamed Boucadair, Éric Vyncke, | ||||
Gunter Van de Velde, Mahesh Jethanandani, and Andy Smith for their | ||||
thorough review and very helpful comments. | ||||
The authors would like to acknowledge Yao Liu and Quan Xiong for the | ||||
very helpful face to face discussion. | ||||
Authors' Addresses | Authors' Addresses | |||
Xiao Min | Xiao Min | |||
ZTE Corp. | ZTE Corp. | |||
Nanjing | Nanjing | |||
China | China | |||
Phone: +86 18061680168 | Phone: +86 18061680168 | |||
Email: xiao.min2@zte.com.cn | Email: xiao.min2@zte.com.cn | |||
Shaofu Peng | Shaofu Peng | |||
End of changes. 136 change blocks. | ||||
276 lines changed or deleted | 240 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |