| Internet-Draft | PCEP Extensions for Multipath | July 2023 |
| Koldychev, et al. | Expires 25 January 2024 | [Page] |
Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths, that together form a solution. Returning just one single traffic path does not provide a valid solution. This document defines a mechanism to encode multiple paths for a single set of objectives and constraints. This is a generic PCEP mechanism, not specific to any path setup type or dataplane. The mechanism is applicable to both stateless and stateful PCEP.¶
This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 January 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Segment Routing Policy for Traffic Engineering [RFC9256] details the concepts of SR Policy and approaches to steering traffic into an SR Policy. In particular, it describes the SR candidate-path as a collection of one or more Segment-Lists. The current PCEP standards only allow for signaling of one Segment-List per Candidate-Path. PCEP extension to support Segment Routing Policy Candidate Paths [I-D.ietf-pce-segment-routing-policy-cp] specifically avoids defining how to signal multiple Segment-Lists.¶
This document defines the required extensions that allow the signaling of multipath information via PCEP. Although these extensions are motivated by the SR Policy use case, they are also applicable to other data plane types.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are used in this document:¶
ECMP:¶
Equal Cost Multi Path, equally distributing traffic among multiple paths/links, where each path/link gets the same share of traffic as others.¶
W-ECMP:¶
Weighted ECMP, un-equally distributing traffic among multiple paths/links, where some paths/links get more traffic than others.¶
This extension is motivated by the use-cases described below.¶
The Candidate-Path of an SR Policy is the unit of signaling in PCEP, see [I-D.ietf-pce-segment-routing-policy-cp]. Each Candidate-Path can contain multiple Segment-Lists and each Segment-List is encoded by one ERO. However, each PCEP LSP can contain only a single ERO, which prevents us from encoding multiple Segment-Lists within the same SR Candidate-Path.¶
A PCC may request a path with 80 Gbps of bandwidth, but all links in the network have only 60 Gbps capacity. The PCE can return two paths, that can together carry 80 Gbps. The PCC can then equally or unequally split the incoming 80 Gbps of traffic among the two paths. Section 4.2 introduces a new TLV that carries the path weight that facilitates control of load-balancing of traffic among the multiple paths.¶
Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs) [RFC9059] defines a mechanism in PCEP to associate two opposite direction SR Policy Candidate Paths. However, within each Candidate Path there can be multiple Segment-Lists, and [RFC9059] does not define a mechanism to specify Segment-List to Segment-List mapping between the forward and reverse Candidate Paths. Certain applications such as Circuit Style SR Policy [I-D.schmutzer-pce-cs-sr-policy], require the knowledge of reverse path(s) per Segment-List, not just per Candidate path. For example, when the headend knows the reverse Segment-List for each forward Segment-List, then PM/BFD can run a separate session on every Segment-List, by imposing a double stack (forward stack followed by reverse stack) on the packet. If the reverse Segment-List is co-routed with the forward Segment-List, then the PM/BFD session would traverse the same links in the forward and reverse directions, thus allowing to detect link/node failures in both directions.¶
We define the PATH-ATTRIB object that is used to carry per-path information and to act as a separator between several ERO/RRO objects in the <intended-path>/<actual-path> RBNF element. The PATH-ATTRIB object always precedes the ERO/RRO that it applies to. If multiple ERO/RRO objects are present, then each ERO/RRO object MUST be preceded by an PATH-ATTRIB object that describes it.¶
The PATH-ATTRIB Object-Class value is (45).¶
The PATH-ATTRIB Object-Type value is 1.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |R| O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O (Operational - 3 bits): operational state of the path, same values as the identically named field in the LSP object [RFC8231].¶
R (Reverse): Indicates this path is reverse, i.e., it originates on the LSP destination and terminates on the LSP source (usually the PCC headend itself). Paths with this flag set serve only informational purpose to the PCC.¶
Path ID: 4-octet identifier that identifies a path (encoded in the ERO/RRO) within the set of multiple paths under the PCEP LSP. See Section 5.2 for details.¶
New MULTIPATH-WEIGHT TLV is optional in the PATH-ATTRIB object.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: (61) for "MULTIPATH-WEIGHT" TLV.¶
Length: 4.¶
Weight: weight of this path within the multipath, if W-ECMP is desired. The fraction of flows a specific ERO/RRO carries is derived from the ratio of its weight to the sum of all other multipath ERO/RRO weights.¶
When the MULTIPATH-WEIGHT TLV is absent from the PATH-ATTRIB object, or the PATH-ATTRIB object is absent from the <intended-path>/<actual-path>, then the Weight of the corresponding path is taken to be "1".¶
New MULTIPATH-BACKUP TLV is optional in the PATH-ATTRIB object.¶
This TLV is used to specify protecting path(s), similar to FRR or TI-LFA. This functionality is not part of the SR Policy Architecture [RFC9256], but is something optional that MAY be implemented for certain specialized use cases.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path Count | Flags |B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path ID n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: (62) for "MULTIPATH-BACKUP" TLV¶
Length: 4 + (N * 4) (where N is the Backup Path Count)¶
Backup Path Count: Number of backup path(s).¶
B: If set, indicates a pure backup path. This is a path that only carries rerouted traffic after the protected path fails. If this flag is not set, or if the MULTIPATH-BACKUP TLV is absent, then the path is assumed to be primary that carries normal traffic.¶
Backup Path ID(s): a series of 4-octet identifier(s) that identify the backup path(s) in the set that protect this primary path.¶
New MULTIPATH-OPPDIR-PATH TLV is optional in the PATH-ATTRIB object. Multiple instances of the TLV are allowed in the same PATH-ATTRIB object. This TLV encodes a many-to-many mapping between forward and reverse paths.¶
Many-to-many mapping means that a single forward path MAY map to multiple reverse paths and conversely that a single reverse path MAY map to multiple forward paths. Many-to-many mapping can happen for an SR Policy, when a Segment-List contains Node Segment(s) which traverse parallel links at the midpoint. The reverse of this Segment-List may not be able to be expressed as a single Reverse Segment-List, but need to return multiple Reverse Segment-Lists to cover all the parallel links at the midpoint.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (MBZ) | Flags |L|N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opposite Direction Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: (63) for "MULTIPATH-OPPDIR-PATH" TLV¶
Length: 16.¶
N (Node co-routed): If set, indicates this path is node co-routed with its opposite direction path, specified in this TLV. Two opposite direction paths are node co-routed if they traverse the same nodes, but MAY traverse different links.¶
L (Link co-routed): If set, indicates this path is link co-routed with its opposite directions path, specified in this TLV. Two opposite direction paths are link co-routed if they traverse the same links (but in the opposite directions).¶
Opposite Direction Path ID: Identifies a path that goes in the opposite direction to this path. If no such path exists, then this field MUST be set to 0x0, which is reserved to indicate the absense of a Path ID.¶
Multiple instances of this TLV present in the same PATH-ATTRIB object indicate that there are multiple opposite-direction paths corresponding to the given path. This allows for many-to-many relationship among the paths of two opposite direction LSPs.¶
Whenever path A references another path B as being the opposite-direction path, then path B SHOULD also reference path A as its own opposite-direction path. Furthermore, their values of the R-flag (Reverse) in the PATH-ATTRIB object MUST have opposite values.¶
See Section 7.4 for an example of usage.¶
SR Policy Architecture [RFC9256] defines the concept of a Composite Candidate Path. A regular SR Policy Candidate Path outputs traffic to a set of Segment-Lists, while an SR Policy Composite Candidate Path outputs traffic recursively to a set of SR Policies on the same headend. In PCEP, the Composite Candidate Path still consists of PATH-ATTRIB objects, but ERO is replaced by Color of the recursively used SR Policy.¶
To signal the Composite Candidate Path, we make use of the COLOR TLV, defined in [I-D.draft-ietf-pce-pcep-color]. For a Composite Candidate Path, the COLOR TLV is included in the PATH-ATTRIB Object, thus allowing each Composite Candidate Path to do ECMP/W-ECMP among SR Policies identified by its constituent Colors. Only one COLOR TLV SHOULD be included into the PATH-ATTRIB object. If multiple COLOR TLVs are contained in the PATH-ATTRIB object, only the first one MUST be processed and the others SHOULD be ignored.¶
An ERO object MUST be included as per the existing RBNF, this ERO SHOULD contain no sub-objects. If the head-end receives a non-empty ERO, the contents SHOULD be ignored.¶
See Section 7.3 for an example of the encoding.¶
Per-Flow Candidate Path builds on top of the concept of the Composite Candidate Path. Each Path in a Per-Flow Candidate Path is assigned a 3-bit forward class value, which allows QoS classified traffic to be steered depending on the forward class.¶
New MULTIPATH-FORWARD-CLASS TLV is optional in the PATH-ATTRIB object.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ | FC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: (TBD1) for "MULTIPATH-FORWARD-CLASS" TLV.¶
Length: 4.¶
FC: Forward class value that is given by the QoS classifier to traffic entering the given Candidate Path. Different classes of traffic that enter the given Candidate Path can be differentially steered into different Colors.¶
New MULTIPATH-CAP TLV is defined. This TLV MAY be present in the OPEN object during PCEP session establishment.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Multipaths | Flags |C|F|O|B|W| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: (60) for "MULTIPATH-CAP" TLV.¶
Length: 4.¶
Number of Multipaths: From PCC, it tells how many multipaths the PCC can install in forwarding. From PCE, it tells how many multipaths the PCE can compute. The value 255 indicates unlimited number. The value 0 is reserved.¶
W-flag: whether MULTIPATH-WEIGHT TLV is supported.¶
B-flag: whether MULTIPATH-BACKUP TLV is supported.¶
O-flag: whether MULTIPATH-OPPDIR-PATH TLV is supported and requested. If this flag is set, the PCE SHOULD tell the PCC the reverse path information, if it is able to.¶
F-flag: whether MULTIPATH-FORWARD-CLASS TLV is supported.¶
C-flag: whether Composite Candidate Path (Section 4.5) is supported. Note that F-flag and C-flag can be set independently, i.e., F-flag can be set, but C-flag not set, etc.¶
When PCE computes the LSP path, it MUST NOT return more forward multipaths than the corresponding value of "Number of Multipaths" from the MULTIPATH-CAP TLV. If this TLV is absent (from both OPEN and LSP objects), then the "Number of Multipaths" is assumed to be 1.¶
From the PCC, the MULTIPATH-CAP TLV MAY also be present in the LSP object for each individual LSP, to specify per-LSP values. The PCC MUST NOT include this TLV in the LSP object if the TLV was not present in the OPEN objects of both PCEP peers. TLV values in the LSP object override the session default values in the OPEN object.¶
For example, the PCC includes this TLV in the OPEN object at session establishment, setting "Number of Multipaths" to 4 and "O-flag" to 0. The PCC also includes this TLV in the LSP object for a particular LSP, setting "Number of Multipaths" to 16 and "O-flag" to 1. This indicates that the PCC only wants to receive the reverse path information for that particular LSP and that this LSP can have up to 16 multipaths, while other LSPs can only have up to 4 multipaths.¶
The Path ID uniquely identifies a Path within the context of an LSP. Note that when the LSP is an SR Policy Candidate Path, the Paths within that LSP are the Segment-Lists.¶
Value 0x0 indicates unallocated Path ID. The value of 0x0 MAY be used when this Path is not being referenced and the allocation of a Path ID is not necessary.¶
Path IDs are allocated by the PCEP peer that owns the LSP. If the LSP is delegated to the PCE, then the PCE allocates the Path IDs and sends them in the PCReply/PCUpd/PCInit messages. If the LSP is locally computed on the PCC, then the PCC allocates the Path IDs and sends them in the PCReq/PCRpt messages.¶
If a PCEP speaker detects that there are two Paths with the same Path ID, then the PCEP speaker SHOULD send PCError message with Error-Type = 1 ("Reception of an invalid object") and Error-Value = 38 ("Conflicting Path ID").¶
The PATH-ATTRIB object can be used to signal multiple path(s) and indicate (un)equal loadbalancing amongst the set of multipaths. In this case, the PATH-ATTRIB is populated for each ERO as follows:¶
The PATH-ATTRIB object can be used to describe a set of backup path(s) protecting a primary path within a PCEP LSP. In this case, the PATH-ATTRIB is populated for each ERO as follows:¶
Note that primary paths which do not include the MULTIPATH-BACKUP TLV are assumed to be protected by all the backup paths. I.e., omitting the TLV is equivalent to including the TLV with all the backup path IDs filled in.¶
Note that a given PCC may not support certain backup combinations, such as a backup path that is itself protected by another backup path, etc. If a PCC is not able to implement a requested backup scenario, the PCC SHOULD send a PCError message with Error-Type = 19 ("Invalid Operation") and Error-Value = 20 ("Not supported path backup").¶
The RBNF of PCReq, PCRep, PCRpt, PCUpd and PCInit messages currently use a combination of <intended-path> and/or <actual-path>. As specified in Section 6.1 of [RFC8231], <intended-path> is represented by the ERO object and <actual-path> is represented by the RRO object:¶
<intended-path> ::= <ERO> <actual-path> ::= <RRO>¶
In this standard, we extend these two elements to allow multiple ERO/RRO objects to be present in the <intended-path>/<actual-path>:¶
<intended-path> ::= (<ERO>|
(<PATH-ATTRIB><ERO>)
[<intended-path>])
<actual-path> ::= (<RRO>|
(<PATH-ATTRIB><RRO>)
[<actual-path>])
¶
Consider the following sample SR Policy, taken from
[RFC9256].¶
SR policy POL1 <headend, color, endpoint>
Candidate-path CP1 <protocol-origin = 20, originator =
100:1.1.1.1, discriminator = 1>
Preference 200
Weight W1, SID-List1 <SID11...SID1i>
Weight W2, SID-List2 <SID21...SID2j>
Candidate-path CP2 <protocol-origin = 20, originator =
100:2.2.2.2, discriminator = 2>
Preference 100
Weight W3, SID-List3 <SID31...SID3i>
Weight W4, SID-List4 <SID41...SID4j>
¶
As specified in [I-D.ietf-pce-segment-routing-policy-cp], CP1 and CP2 are signaled as separate state-report elements and each has a unique PLSP-ID, assigned by the PCC. Let us assign PLSP-ID 100 to CP1 and PLSP-ID 200 to CP2.¶
The state-report for CP1 can be encoded as:¶
<state-report> =
<LSP PLSP_ID=100>
<ASSOCIATION>
<END-POINT>
<PATH-ATTRIB Path_ID=1 <WEIGHT-TLV Weight=W1>>
<ERO SID-List1>
<PATH-ATTRIB Path_ID=2 <WEIGHT-TLV Weight=W2>>
<ERO SID-List2>
¶
The state-report for CP2 can be encoded as:¶
<state-report> =
<LSP PLSP_ID=200>
<ASSOCIATION>
<END-POINT>
<PATH-ATTRIB Path_ID=1 <WEIGHT-TLV Weight=W3>>
<ERO SID-List3>
<PATH-ATTRIB Path_ID=2 <WEIGHT-TLV Weight=W4>>
<ERO SID-List4>
¶
The above sample state-report elements only specify the minimum mandatory objects, of course other objects like SRP, LSPA, METRIC, etc., are allowed to be inserted.¶
Note that the syntax¶
<PATH-ATTRIB Path_ID=1 <WEIGHT-TLV Weight=W1>>¶
, simply means that this is PATH-ATTRIB object with Path ID field set to "1" and with a MULTIPATH-WEIGHT TLV carrying weight of "W1".¶
Suppose there are 3 paths: A, B, C. Where A,B are primary and C is to be used only when A or B fail. Suppose the Path IDs for A, B, C are respectively 1, 2, 3. This would be encoded in a state-report as:¶
<state-report> =
<LSP>
<ASSOCIATION>
<END-POINT>
<PATH-ATTRIB Path_ID=1 <BACKUP-TLV B=0, Backup_Paths=[3]>>
<ERO A>
<PATH-ATTRIB Path_ID=2 <BACKUP-TLV B=0, Backup_Paths=[3]>>
<ERO B>
<PATH-ATTRIB Path_ID=3 <BACKUP-TLV B=1, Backup_Paths=[]>>
<ERO C>
¶
Note that the syntax¶
<PATH-ATTRIB Path_ID=1 <BACKUP-TLV B=0, Backup_Paths=[3]>>¶
, simply means that this is PATH-ATTRIB object with Path ID field set to "1" and with a MULTIPATH-BACKUP TLV that has B-flag cleared and contains a single backup path with Backup Path ID of 3.¶
Consider the following Composite Candidate Path, taken from
[RFC9256].¶
SR policy POL100 <headend = H1, color = 100, endpoint = E1>
Candidate-path CP1 <protocol-origin = 20, originator =
100:1.1.1.1, discriminator = 1>
Preference 200
Weight W1, SR policy <color = 1>
Weight W2, SR policy <color = 2>
¶
This is signaled in PCEP as:¶
<LSP PLSP_ID=100>
<ASSOCIATION>
<END-POINT>
<PATH-ATTRIB Path_ID=1
<WEIGHT-TLV Weight=W1>
<COLOR-TLV Color=1>>
<ERO (empty)>
<PATH-ATTRIB Path_ID=2
<WEIGHT-TLV Weight=W2>
<COLOR-TLV Color=2>>
<ERO (empty)>
¶
Consider the two opposite-direction SR Policies between end-points H1 and E1.¶
SR policy POL1 <headend = H1, color, endpoint = E1>
Candidate-path CP1
Preference 200
Bidirectional Association = A1
SID-List = <H1,M1,M2,E1>
SID-List = <H1,M3,M4,E1>
Candidate-path CP2
Preference 100
Bidirectional Association = A2
SID-List = <H1,M5,M6,E1>
SID-List = <H1,M7,M8,E1>
SR policy POL2 <headend = E1, color, endpoint = H1>
Candidate-path CP1
Preference 200
Bidirectional Association = A1
SID-List = <E1,M2,M1,H1>
SID-List = <E1,M4,M3,H1>
Candidate-path CP2
Preference 100
Bidirectional Association = A2
SID-List = <E1,M6,M5,H1>
¶
The state-report for POL1, CP1 can be encoded as:¶
<state-report> =
<LSP PLSP_ID=100>
<BIDIRECTIONAL ASSOCIATION = A1>
<PATH-ATTRIB PathID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePathID=3>>
<ERO <H1,M1,M2,E1>>
<PATH-ATTRIB PathID=2 R-flag=0
<OPPDIR-PATH-TLV OppositePathID=4>>
<ERO <H1,M3,M4,E1>>
<PATH-ATTRIB PathID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePathID=1>>
<ERO <E1,M2,M1,H1>>
<PATH-ATTRIB PathID=4 R-flag=1
<OPPDIR-PATH-TLV OppositePathID=2>>
<ERO <E1,M4,M3,H1>>
¶
The state-report for POL1, CP2 can be encoded as:¶
<state-report> =
<LSP PLSP_ID=200>
<BIDIRECTIONAL ASSOCIATION = A2>
<PATH-ATTRIB PathID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePathID=3>>
<ERO <H1,M5,N6,E1>>
<PATH-ATTRIB PathID=2 R-flag=0
<OPPDIR-PATH-TLV OppositePathID=0>>
<ERO <H1,M7,M8,E1>>
<PATH-ATTRIB PathID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePathID=1>>
<ERO <E1,M6,M5,H1>>
¶
The state-report for POL2, CP1 can be encoded as:¶
<state-report> =
<LSP PLSP_ID=100>
<BIDIRECTIONAL ASSOCIATION = A1>
<PATH-ATTRIB PathID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePathID=3>>
<ERO <E1,M2,M1,H1>>
<PATH-ATTRIB PathID=2 R-flag=0
<OPPDIR-PATH-TLV OppositePathID=4>>
<ERO <E1,M4,M3,H1>>
<PATH-ATTRIB PathID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePathID=1>>
<ERO <H1,M1,M2,E1>>
<PATH-ATTRIB PathID=4 R-flag=1
<OPPDIR-PATH-TLV OppositePathID=2>>
<ERO <H1,M3,M4,E1>>
¶
The state-report for POL2, CP2 can be encoded as:¶
<state-report> =
<LSP PLSP_ID=200>
<BIDIRECTIONAL ASSOCIATION = A2>
<PATH-ATTRIB PathID=1 R-flag=0
<OPPDIR-PATH-TLV OppositePathID=3>>
<ERO <E1,M6,M5,H1>>
<PATH-ATTRIB PathID=2 R-flag=1
<OPPDIR-PATH-TLV OppositePathID=0>>
<ERO <H1,M7,M8,E1>>
<PATH-ATTRIB PathID=3 R-flag=1
<OPPDIR-PATH-TLV OppositePathID=1>>
<ERO <H1,M5,N6,E1>>
¶
Note to the RFC Editor - remove this section before publication, as well as remove the reference to [RFC7942].¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
Organization: Cisco Systems Implementation: IOS-XR PCC and PCE Description: Circuit-Style SR Policies Maturity Level: Supported feature Coverage: Multiple Segment-Lists and reverse paths in SR Policy Contact: mkoldych@cisco.com¶
Organization: Ciena Corp Implementation: Head-end and controller Maturity Level: Proof of concept Coverage: Full Contact: byadav@ciena.com¶
Organization: Huawei Technologies Co.,Ltd. Implementation: Huawei's Router and Controller Maturity Level: Proof of concept Coverage: Partial Contact: tanren@huawei.com¶
IANA is requested to make the assignment of a new value for the existing "PCEP Objects" registry as follows:¶
+--------------+-------------+-------------------+-----------------+ | Object-Class | Name | Object-Type | Reference | | Value | | Value | | +--------------+-------------+-------------------+-----------------+ | 45 | PATH-ATTRIB | 1 | This document | +--------------+-------------+-------------------+-----------------+¶
IANA is requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" registry as follows:¶
+------------+-----------------------------------+-----------------+ | TLV Type | TLV Name | Reference | | Value | | | +------------+-----------------------------------+-----------------+ | 60 | MULTIPATH-CAP | This document | +------------+-----------------------------------+-----------------+ | 61 | MULTIPATH-WEIGHT | This document | +------------+-----------------------------------+-----------------+ | 62 | MULTIPATH-BACKUP | This document | +------------+-----------------------------------+-----------------+ | 63 | MULTIPATH-OPPDIR-PATH | This document | +------------+-----------------------------------+-----------------+ | TBD1 | MULTIPATH-FORWARD-CLASS | This document | +------------+-----------------------------------+-----------------+¶
IANA is requested to make the assignment of a new value for the existing "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers registry for the following errors:¶
+------------+-----------------------------------+-----------------+ | Error-Type | Error-Value | Reference | +------------+-----------------------------------+-----------------+ | 10 | 38 - Conflicting Path ID | This document | +------------+-----------------------------------+-----------------+ | 19 | 20 - Not supported path backup | This document | +------------+-----------------------------------+-----------------+ | 19 | 21 - Non-empty path | This document | +------------+-----------------------------------+-----------------+¶
IANA is requested to create a new sub-registry to manage the Flag field of the MULTIPATH-CAP TLV, called "Flags in MULTIPATH-CAP TLV". New values are to be assigned by Standards Action [RFC8126]¶
+------------+-----------------------------------+-----------------+ | Bit | Description | Reference | +------------+-----------------------------------+-----------------+ | 0-12 | Unassigned | This document | +------------+-----------------------------------+-----------------+ | 13 | 0-flag: support for processing | This document | | | MULTIPATH-OPPDIR-PATH TLV | | +------------+-----------------------------------+-----------------+ | 14 | B-flag: support for processing | This document | | | MULTIPATH-BACKUP TLV | | +------------+-----------------------------------+-----------------+ | 15 | W-flag: support for processing | This document | | | MULTIPATH-WEIGHT TLV | | +------------+-----------------------------------+-----------------+¶
IANA is requested to create a new sub-registry to manage the Flag field of the PATH-ATTRIBUTE object, called "Flags in PATH-ATTRIBUTE Object". New values are to be assigned by Standards Action [RFC8126]¶
+------------+-----------------------------------+-----------------+ | Bit | Description | Reference | +------------+-----------------------------------+-----------------+ | 0-12 | Unassigned | This document | +------------+-----------------------------------+-----------------+ | 13-15 | O-flag: Operational state | This document | +------------+-----------------------------------+-----------------+¶
IANA is requested to create a new sub-registry to manage the Flag field of the MULTIPATH-BACKUP TLV, called "Flags in MULTIPATH-BACKUP TLV". New values are to be assigned by Standards Action [RFC8126]¶
+------------+-----------------------------------+-----------------+ | Bit | Description | Reference | +------------+-----------------------------------+-----------------+ | 0-14 | Unassigned | This document | +------------+-----------------------------------+-----------------+ | 15 | B-flag: Pure backup | This document | +------------+-----------------------------------+-----------------+¶
IANA is requested to create a new sub-registry to manage the flag fields of the MULTIPATH-OPPDIR-PATH TLV, called "Flags in the MULTIPATH-OPPDIR-PATH TLV". New values are to be assigned by Standards Action [RFC8126]¶
+------------+-----------------------------------+-----------------+ | Bit | Description | Reference | +------------+-----------------------------------+-----------------+ | 0-12 | Unassigned | This document | +------------+-----------------------------------+-----------------+ | 14 | L-flag: Link co-routed | This document | +------------+-----------------------------------+-----------------+ | 15 | N-flag: Node co-routed | This document | +------------+-----------------------------------+-----------------+¶
None at this time.¶
Thanks to Dhruv Dhody for ideas and discussion. Thanks to Yuan Yaping for review comments.¶
Andrew Stone Nokia Email: andrew.stone@nokia.com Chen Ran ZTE Email: chen.ran@zte.com.cn¶