< draft-ietf-pce-multipath-04.txt   draft-ietf-pce-multipath-05.txt >
PCE Working Group M. Koldychev PCE Working Group M. Koldychev
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Sivabalan Intended status: Standards Track S. Sivabalan
Expires: 29 August 2022 Ciena Corporation Expires: 1 October 2022 Ciena Corporation
T. Saad T. Saad
V. Beeram V. Beeram
Juniper Networks, Inc. Juniper Networks, Inc.
H. Bidgoli H. Bidgoli
Nokia Nokia
B. Yadav B. Yadav
Ciena Ciena
S. Peng S. Peng
Huawei Technologies Huawei Technologies
G. Mishra G. Mishra
Verizon Inc. Verizon Inc.
25 February 2022 30 March 2022
PCEP Extensions for Signaling Multipath Information PCEP Extensions for Signaling Multipath Information
draft-ietf-pce-multipath-04 draft-ietf-pce-multipath-05
Abstract Abstract
Path computation algorithms are not limited to return a single Path computation algorithms are not limited to return a single
optimal path. Multiple paths may exist that satisfy the given optimal path. Multiple paths may exist that satisfy the given
objectives and constraints. This document defines a mechanism to objectives and constraints. This document defines a mechanism to
encode multiple paths for a single set of objectives and constraints. encode multiple paths for a single set of objectives and constraints.
This is a generic PCEP mechanism, not specific to any path setup type This is a generic PCEP mechanism, not specific to any path setup type
or dataplane. The mechanism is applicable to both stateless and or dataplane. The mechanism is applicable to both stateless and
stateful PCEP. stateful PCEP.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 August 2022. This Internet-Draft will expire on 1 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 48 skipping to change at page 2, line 48
5.1. Capability Negotiation . . . . . . . . . . . . . . . . . 10 5.1. Capability Negotiation . . . . . . . . . . . . . . . . . 10
5.2. Path ID . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Path ID . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Signaling Multiple Paths for Loadbalancing . . . . . . . 11 5.3. Signaling Multiple Paths for Loadbalancing . . . . . . . 11
5.4. Signaling Multiple Paths for Protection . . . . . . . . . 12 5.4. Signaling Multiple Paths for Protection . . . . . . . . . 12
6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 13 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 13
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. SR Policy Candidate-Path with Multiple Segment-Lists . . 13 7.1. SR Policy Candidate-Path with Multiple Segment-Lists . . 13
7.2. Two Primary Paths Protected by One Backup Path . . . . . 14 7.2. Two Primary Paths Protected by One Backup Path . . . . . 14
7.3. Composite Candidate Path . . . . . . . . . . . . . . . . 15 7.3. Composite Candidate Path . . . . . . . . . . . . . . . . 15
7.4. Opposite Direction Tunnels . . . . . . . . . . . . . . . 15 7.4. Opposite Direction Tunnels . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
8.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 18
8.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. Ciena Corp . . . . . . . . . . . . . . . . . . . . . . . 18
8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.4. Flags in the Multipath Capability TLV . . . . . . . . . . 19 9.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 18
8.5. Flags in the Path Attribute Object . . . . . . . . . . . 19 9.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 19
8.6. Flags in the Multipath Backup TLV . . . . . . . . . . . . 19 9.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 19
8.7. Flags in the Multipath Opposite Direction Path TLV . . . 20 9.4. Flags in the Multipath Capability TLV . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9.5. Flags in the Path Attribute Object . . . . . . . . . . . 20
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 9.6. Flags in the Multipath Backup TLV . . . . . . . . . . . . 20
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 9.7. Flags in the Multipath Opposite Direction Path TLV . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Path Computation Element (PCE) Communication Protocol (PCEP) Path Computation Element (PCE) Communication Protocol (PCEP)
[RFC5440] enables the communication between a Path Computation Client [RFC5440] enables the communication between a Path Computation Client
(PCC) and a Path Control Element (PCE), or between two PCEs based on (PCC) and a Path Control Element (PCE), or between two PCEs based on
the PCE architecture [RFC4655]. the PCE architecture [RFC4655].
PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set
of extensions to PCEP that enable active control of Multiprotocol of extensions to PCEP that enable active control of Multiprotocol
skipping to change at page 7, line 39 skipping to change at page 7, line 39
desired. The fraction of flows a specific ERO/RRO carries is derived 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/ from the ratio of its weight to the sum of all other multipath ERO/
RRO weights. RRO weights.
When the MULTIPATH-WEIGHT TLV is absent from the PATH-ATTRIB object, When the MULTIPATH-WEIGHT TLV is absent from the PATH-ATTRIB object,
or the PATH-ATTRIB object is absent from the <intended-path>/<actual- 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". path>, then the Weight of the corresponding path is taken to be "1".
4.4. Multipath Backup TLV 4.4. Multipath Backup TLV
This document introduces a new MULTIPATH-BACKUP TLV that is optional This document introduces a new MULTIPATH-BACKUP TLV that MAY be
and can be present in the PATH-ATTRIB object. present in the PATH-ATTRIB object.
This TLV is used to indicate the presence of a backup path that is This TLV is used to indicate the presence of a backup path that is
used for protection in case of failure of the primary path. The used for protection in case of failure of the primary path. The
format of the MULTIPATH-BACKUP TLV is: format of the MULTIPATH-BACKUP TLV is:
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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 39 skipping to change at page 8, line 39
B: If set, indicates a pure backup path. This is a path that only B: If set, indicates a pure backup path. This is a path that only
carries rerouted traffic after the protected path fails. If this carries rerouted traffic after the protected path fails. If this
flag is not set, or if the MULTIPATH-BACKUP TLV is absent, then the flag is not set, or if the MULTIPATH-BACKUP TLV is absent, then the
path is assumed to be primary that carries normal traffic. path is assumed to be primary that carries normal traffic.
Backup Path ID(s): a series of 4-octet identifier(s) that identify 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. the backup path(s) in the set that protect this primary path.
4.5. Multipath Opposite Direction Path TLV 4.5. Multipath Opposite Direction Path TLV
This document introduces a new MULTIPATH-OPPDIR-PATH TLV that is This document introduces a new MULTIPATH-OPPDIR-PATH TLV that MAY be
optional and can be present in the PATH-ATTRIB object. present in the PATH-ATTRIB object. This TLV encodes a many-to-many
mapping between forward and reverse paths within a PCEP Tunnel.
This TLV is used to indicate whether the given path is a forward path Many-to-many mapping means that a single forward path MAY map to
or a reverse path in its PCEP Tunnel, as well as give information multiple reverse paths and conversely that a single reverse path MAY
about the opposite-direction path(s) of the given path. Note that map to multiple forward paths. Many-to-many mapping can happen for
all reverse paths MUST have the I-flag (Informational) set in the an SR Policy, when a Segment List contains Node Segment(s) which
PATH-ATTRIB object, to indicate that these are not to be installed traverse parallel links at the midpoint. The reverse of this Segment
into forwarding by the PCC. 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
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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (MBZ) | Flags |L|N| | Reserved (MBZ) | Flags |L|N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opposite Direction Path ID | | Opposite Direction Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 34 skipping to change at page 13, line 34
(<PATH-ATTRIB><RRO>) (<PATH-ATTRIB><RRO>)
[<actual-path>]) [<actual-path>])
7. Examples 7. Examples
7.1. SR Policy Candidate-Path with Multiple Segment-Lists 7.1. SR Policy Candidate-Path with Multiple Segment-Lists
Consider the following sample SR Policy, taken from Consider the following sample SR Policy, taken from
[I-D.ietf-spring-segment-routing-policy]. [I-D.ietf-spring-segment-routing-policy].
SR policy POL1 <headend, color, endpoint> SR policy POL1 <headend, color, endpoint>
Candidate-path CP1 <protocol-origin = 20, originator = Candidate-path CP1 <protocol-origin = 20, originator =
100:1.1.1.1, discriminator = 1> 100:1.1.1.1, discriminator = 1>
Preference 200 Preference 200
Weight W1, SID-List1 <SID11...SID1i> Weight W1, SID-List1 <SID11...SID1i>
Weight W2, SID-List2 <SID21...SID2j> Weight W2, SID-List2 <SID21...SID2j>
Candidate-path CP2 <protocol-origin = 20, originator = Candidate-path CP2 <protocol-origin = 20, originator =
100:2.2.2.2, discriminator = 2> 100:2.2.2.2, discriminator = 2>
Preference 100 Preference 100
Weight W3, SID-List3 <SID31...SID3i> Weight W3, SID-List3 <SID31...SID3i>
Weight W4, SID-List4 <SID41...SID4j> Weight W4, SID-List4 <SID41...SID4j>
As specified in [I-D.ietf-pce-segment-routing-policy-cp], CP1 and CP2 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 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, assigned by the PCC. Let us assign PLSP-ID 100 to CP1 and
PLSP-ID 200 to CP2. PLSP-ID 200 to CP2.
The state-report for CP1 can be encoded as: The state-report for CP1 can be encoded as:
<state-report> = <state-report> =
<LSP PLSP_ID=100> <LSP PLSP_ID=100>
<ASSOCIATION> <ASSOCIATION>
<END-POINT> <END-POINT>
<PATH-ATTRIB Path_ID=1 <WEIGHT-TLV Weight=W1>> <PATH-ATTRIB Path_ID=1 <WEIGHT-TLV Weight=W1>>
<ERO SID-List1> <ERO SID-List1>
<PATH-ATTRIB Path_ID=2 <WEIGHT-TLV Weight=W2>> <PATH-ATTRIB Path_ID=2 <WEIGHT-TLV Weight=W2>>
<ERO SID-List2> <ERO SID-List2>
The state-report for CP2 can be encoded as: The state-report for CP2 can be encoded as:
<state-report> = <state-report> =
<LSP PLSP_ID=200> <LSP PLSP_ID=200>
<ASSOCIATION> <ASSOCIATION>
<END-POINT> <END-POINT>
<PATH-ATTRIB Path_ID=1 <WEIGHT-TLV Weight=W3>> <PATH-ATTRIB Path_ID=1 <WEIGHT-TLV Weight=W3>>
<ERO SID-List3> <ERO SID-List3>
<PATH-ATTRIB Path_ID=2 <WEIGHT-TLV Weight=W4>> <PATH-ATTRIB Path_ID=2 <WEIGHT-TLV Weight=W4>>
<ERO SID-List4> <ERO SID-List4>
The above sample state-report elements only specify the minimum The above sample state-report elements only specify the minimum
mandatory objects, of course other objects like SRP, LSPA, METRIC, mandatory objects, of course other objects like SRP, LSPA, METRIC,
etc., are allowed to be inserted. etc., are allowed to be inserted.
Note that the syntax Note that the syntax
<PATH-ATTRIB Path_ID=1 <WEIGHT-TLV Weight=W1>> <PATH-ATTRIB Path_ID=1 <WEIGHT-TLV Weight=W1>>
, simply means that this is PATH-ATTRIB object with Path ID field set , 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". to "1" and with a MULTIPATH-WEIGHT TLV carrying weight of "W1".
7.2. Two Primary Paths Protected by One Backup Path 7.2. Two Primary Paths Protected by One Backup Path
Suppose there are 3 paths: A, B, C. Where A,B are primary and C is 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 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 are respectively 1, 2, 3. This would be encoded in a state-report
as: as:
<state-report> = <state-report> =
<LSP> <LSP>
<ASSOCIATION> <ASSOCIATION>
<END-POINT> <END-POINT>
<PATH-ATTRIB Path_ID=1 <BACKUP-TLV B=0, Backup_Paths=[3]>> <PATH-ATTRIB Path_ID=1 <BACKUP-TLV B=0, Backup_Paths=[3]>>
<ERO A> <ERO A>
<PATH-ATTRIB Path_ID=2 <BACKUP-TLV B=0, Backup_Paths=[3]>> <PATH-ATTRIB Path_ID=2 <BACKUP-TLV B=0, Backup_Paths=[3]>>
<ERO B> <ERO B>
<PATH-ATTRIB Path_ID=3 <BACKUP-TLV B=1, Backup_Paths=[]>> <PATH-ATTRIB Path_ID=3 <BACKUP-TLV B=1, Backup_Paths=[]>>
<ERO C> <ERO C>
Note that the syntax Note that the syntax
<PATH-ATTRIB Path_ID=1 <BACKUP-TLV B=0, Backup_Paths=[3]>> <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 , 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 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. contains a single backup path with Backup Path ID of 3.
7.3. Composite Candidate Path 7.3. Composite Candidate Path
Consider the following Composite Candidate Path, taken from Consider the following Composite Candidate Path, taken from
[I-D.ietf-spring-segment-routing-policy]. [I-D.ietf-spring-segment-routing-policy].
SR policy POL100 <headend = H1, color = 100, endpoint = E1> SR policy POL100 <headend = H1, color = 100, endpoint = E1>
Candidate-path CP1 <protocol-origin = 20, originator = Candidate-path CP1 <protocol-origin = 20, originator =
100:1.1.1.1, discriminator = 1> 100:1.1.1.1, discriminator = 1>
Preference 200 Preference 200
Weight W1, SR policy <color = 1> Weight W1, SR policy <color = 1>
Weight W2, SR policy <color = 2> Weight W2, SR policy <color = 2>
This is signaled in PCEP as: This is signaled in PCEP as:
<LSP PLSP_ID=100> <LSP PLSP_ID=100>
<ASSOCIATION> <ASSOCIATION>
<END-POINT> <END-POINT>
<PATH-ATTRIB Path_ID=1 <PATH-ATTRIB Path_ID=1
<WEIGHT-TLV Weight=W1> <WEIGHT-TLV Weight=W1>
<COLOR-TLV Color=1>> <COLOR-TLV Color=1>>
<ERO (empty)> <ERO (empty)>
<PATH-ATTRIB Path_ID=2 <PATH-ATTRIB Path_ID=2
<WEIGHT-TLV Weight=W2> <WEIGHT-TLV Weight=W2>
<COLOR-TLV Color=2>> <COLOR-TLV Color=2>>
<ERO (empty)> <ERO (empty)>
7.4. Opposite Direction Tunnels 7.4. Opposite Direction Tunnels
Consider the two opposite-direction SR Policies between end-points H1 Consider the two opposite-direction SR Policies between end-points H1
and E1. and E1.
SR policy POL1 <headend = H1, color, endpoint = E1> SR policy POL1 <headend = H1, color, endpoint = E1>
Candidate-path CP1 Candidate-path CP1
Preference 200 Preference 200
Bidirectional Association = A1 Bidirectional Association = A1
SID-List = <H1,M1,M2,E1> SID-List = <H1,M1,M2,E1>
SID-List = <H1,M3,M4,E1> SID-List = <H1,M3,M4,E1>
Candidate-path CP2 Candidate-path CP2
Preference 100 Preference 100
Bidirectional Association = A2 Bidirectional Association = A2
SID-List = <H1,M5,M6,E1> SID-List = <H1,M5,M6,E1>
SID-List = <H1,M7,M8,E1> SID-List = <H1,M7,M8,E1>
SR policy POL2 <headend = E1, color, endpoint = H1> SR policy POL2 <headend = E1, color, endpoint = H1>
Candidate-path CP1 Candidate-path CP1
Preference 200 Preference 200
Bidirectional Association = A1 Bidirectional Association = A1
SID-List = <E1,M2,M1,H1> SID-List = <E1,M2,M1,H1>
SID-List = <E1,M4,M3,H1> SID-List = <E1,M4,M3,H1>
Candidate-path CP2 Candidate-path CP2
Preference 100 Preference 100
Bidirectional Association = A2 Bidirectional Association = A2
SID-List = <E1,M6,M5,H1> SID-List = <E1,M6,M5,H1>
The state-report for POL1, CP1 can be encoded as: The state-report for POL1, CP1 can be encoded as:
<state-report> = <state-report> =
<LSP PLSP_ID=100> <LSP PLSP_ID=100>
<BIDIRECTIONAL ASSOCIATION = A1> <BIDIRECTIONAL ASSOCIATION = A1>
<PATH-ATTRIB PathID=1 <PATH-ATTRIB PathID=1 R-flag=0
<OPPDIR-PATH-TLV R-flag=0 OppositePathID=3>> <OPPDIR-PATH-TLV OppositePathID=3>>
<ERO <H1,M1,M2,E1>> <ERO <H1,M1,M2,E1>>
<PATH-ATTRIB PathID=2 <PATH-ATTRIB PathID=2 R-flag=0
<OPPDIR-PATH-TLV R-flag=0 OppositePathID=4>> <OPPDIR-PATH-TLV OppositePathID=4>>
<ERO <H1,M3,M4,E1>> <ERO <H1,M3,M4,E1>>
<PATH-ATTRIB PathID=3 <PATH-ATTRIB PathID=3 R-flag=1
<OPPDIR-PATH-TLV R-flag=1 OppositePathID=1>> <OPPDIR-PATH-TLV OppositePathID=1>>
<ERO <E1,M2,M1,H1>> <ERO <E1,M2,M1,H1>>
<PATH-ATTRIB PathID=4 <PATH-ATTRIB PathID=4 R-flag=1
<OPPDIR-PATH-TLV R-flag=1 OppositePathID=2>> <OPPDIR-PATH-TLV OppositePathID=2>>
<ERO <E1,M4,M3,H1>> <ERO <E1,M4,M3,H1>>
The state-report for POL1, CP2 can be encoded as: The state-report for POL1, CP2 can be encoded as:
<state-report> = <state-report> =
<LSP PLSP_ID=200> <LSP PLSP_ID=200>
<BIDIRECTIONAL ASSOCIATION = A2> <BIDIRECTIONAL ASSOCIATION = A2>
<PATH-ATTRIB PathID=1 <PATH-ATTRIB PathID=1 R-flag=0
<OPPDIR-PATH-TLV R-flag=0 OppositePathID=3>> <OPPDIR-PATH-TLV OppositePathID=3>>
<ERO <H1,M5,N6,E1>> <ERO <H1,M5,N6,E1>>
<PATH-ATTRIB PathID=2 <PATH-ATTRIB PathID=2 R-flag=0
<OPPDIR-PATH-TLV R-flag=0 OppositePathID=0>> <OPPDIR-PATH-TLV OppositePathID=0>>
<ERO <H1,M7,M8,E1>> <ERO <H1,M7,M8,E1>>
<PATH-ATTRIB PathID=3 <PATH-ATTRIB PathID=3 R-flag=1
<OPPDIR-PATH-TLV R-flag=1 OppositePathID=1>> <OPPDIR-PATH-TLV OppositePathID=1>>
<ERO <E1,M6,M5,H1>> <ERO <E1,M6,M5,H1>>
The state-report for POL2, CP1 can be encoded as: The state-report for POL2, CP1 can be encoded as:
<state-report> = <state-report> =
<LSP PLSP_ID=100> <LSP PLSP_ID=100>
<BIDIRECTIONAL ASSOCIATION = A1> <BIDIRECTIONAL ASSOCIATION = A1>
<PATH-ATTRIB PathID=1 <PATH-ATTRIB PathID=1 R-flag=0
<OPPDIR-PATH-TLV R-flag=0 OppositePathID=3>> <OPPDIR-PATH-TLV OppositePathID=3>>
<ERO <E1,M2,M1,H1>> <ERO <E1,M2,M1,H1>>
<PATH-ATTRIB PathID=2 <PATH-ATTRIB PathID=2 R-flag=0
<OPPDIR-PATH-TLV R-flag=0 OppositePathID=4>> <OPPDIR-PATH-TLV OppositePathID=4>>
<ERO <E1,M4,M3,H1>> <ERO <E1,M4,M3,H1>>
<PATH-ATTRIB PathID=3 <PATH-ATTRIB PathID=3 R-flag=1
<OPPDIR-PATH-TLV R-flag=1 OppositePathID=1>> <OPPDIR-PATH-TLV OppositePathID=1>>
<ERO <H1,M1,M2,E1>> <ERO <H1,M1,M2,E1>>
<PATH-ATTRIB PathID=4 <PATH-ATTRIB PathID=4 R-flag=1
<OPPDIR-PATH-TLV R-flag=1 OppositePathID=2>> <OPPDIR-PATH-TLV OppositePathID=2>>
<ERO <H1,M3,M4,E1>> <ERO <H1,M3,M4,E1>>
The state-report for POL2, CP2 can be encoded as: The state-report for POL2, CP2 can be encoded as:
<state-report> = <state-report> =
<LSP PLSP_ID=200> <LSP PLSP_ID=200>
<BIDIRECTIONAL ASSOCIATION = A2> <BIDIRECTIONAL ASSOCIATION = A2>
<PATH-ATTRIB PathID=1 <PATH-ATTRIB PathID=1 R-flag=0
<OPPDIR-PATH-TLV R-flag=0 OppositePathID=3>> <OPPDIR-PATH-TLV OppositePathID=3>>
<ERO <E1,M6,M5,H1>> <ERO <E1,M6,M5,H1>>
<PATH-ATTRIB PathID=2 <PATH-ATTRIB PathID=2 R-flag=1
<OPPDIR-PATH-TLV R-flag=1 OppositePathID=0>> <OPPDIR-PATH-TLV OppositePathID=0>>
<ERO <H1,M7,M8,E1>> <ERO <H1,M7,M8,E1>>
<PATH-ATTRIB PathID=3 <PATH-ATTRIB PathID=3 R-flag=1
<OPPDIR-PATH-TLV R-flag=1 OppositePathID=1>> <OPPDIR-PATH-TLV OppositePathID=1>>
<ERO <H1,M5,N6,E1>> <ERO <H1,M5,N6,E1>>
8. IANA Considerations 8. Implementation Status
8.1. PCEP Object
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".
8.1. Cisco Systems
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
8.2. Ciena Corp
Organization: Ciena Corp
Implementation: Head-end and controller
Maturity Level: Proof of concept
Coverage: Full
Contact: byadav@ciena.com
9. IANA Considerations
9.1. PCEP Object
IANA is requested to make the assignment of a new value for the IANA is requested to make the assignment of a new value for the
existing "PCEP Objects" registry as follows: existing "PCEP Objects" registry as follows:
+--------------+-------------+-------------------+-----------------+ +--------------+-------------+-------------------+-----------------+
| Object-Class | Name | Object-Type | Reference | | Object-Class | Name | Object-Type | Reference |
| Value | | Value | | | Value | | Value | |
+--------------+-------------+-------------------+-----------------+ +--------------+-------------+-------------------+-----------------+
| TBD2 | PATH-ATTRIB | 1 | This document | | TBD2 | PATH-ATTRIB | 1 | This document |
+--------------+-------------+-------------------+-----------------+ +--------------+-------------+-------------------+-----------------+
8.2. PCEP TLV 9.2. PCEP TLV
IANA is requested to make the assignment of a new value for the IANA is requested to make the assignment of a new value for the
existing "PCEP TLV Type Indicators" registry as follows: existing "PCEP TLV Type Indicators" registry as follows:
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| TLV Type | TLV Name | Reference | | TLV Type | TLV Name | Reference |
| Value | | | | Value | | |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| TBD1 | MULTIPATH-CAP | This document | | TBD1 | MULTIPATH-CAP | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| TBD3 | MULTIPATH-WEIGHT | This document | | TBD3 | MULTIPATH-WEIGHT | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| TBD4 | MULTIPATH-BACKUP | This document | | TBD4 | MULTIPATH-BACKUP | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| TBD9 | MULTIPATH-OPPDIR-PATH | This document | | TBD9 | MULTIPATH-OPPDIR-PATH | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
8.3. PCEP-Error Object 9.3. PCEP-Error Object
IANA is requested to make the assignment of a new value for the IANA is requested to make the assignment of a new value for the
existing "PCEP-ERROR Object Error Types and Values" sub-registry of existing "PCEP-ERROR Object Error Types and Values" sub-registry of
the PCEP Numbers registry for the following errors: the PCEP Numbers registry for the following errors:
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| Error-Type | Error-Value | Reference | | Error-Type | Error-Value | Reference |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 10 | TBD5 - Conflicting Path ID | This document | | 10 | TBD5 - Conflicting Path ID | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 19 | TBD7 - Not supported path backup | This document | | 19 | TBD7 - Not supported path backup | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 19 | TBD8 - Non-empty path | This document | | 19 | TBD8 - Non-empty path | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
8.4. Flags in the Multipath Capability TLV 9.4. Flags in the Multipath Capability TLV
IANA is requested to create a new sub-registry to manage the Flag 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". field of the MULTIPATH-CAP TLV, called "Flags in MULTIPATH-CAP TLV".
New values are to be assigned by Standards Action [RFC8126] New values are to be assigned by Standards Action [RFC8126]
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| Bit | Description | Reference | | Bit | Description | Reference |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 0-12 | Unassigned | This document | | 0-12 | Unassigned | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 13 | 0-flag: support for processing | This document | | 13 | 0-flag: support for processing | This document |
| | MULTIPATH-OPPDIR-PATH TLV | | | | MULTIPATH-OPPDIR-PATH TLV | |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 14 | B-flag: support for processing | This document | | 14 | B-flag: support for processing | This document |
| | MULTIPATH-BACKUP TLV | | | | MULTIPATH-BACKUP TLV | |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 15 | W-flag: support for processing | This document | | 15 | W-flag: support for processing | This document |
| | MULTIPATH-WEIGHT TLV | | | | MULTIPATH-WEIGHT TLV | |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
8.5. Flags in the Path Attribute Object 9.5. Flags in the Path Attribute Object
IANA is requested to create a new sub-registry to manage the Flag IANA is requested to create a new sub-registry to manage the Flag
field of the PATH-ATTRIBUTE object, called "Flags in PATH-ATTRIBUTE field of the PATH-ATTRIBUTE object, called "Flags in PATH-ATTRIBUTE
Object". New values are to be assigned by Standards Action [RFC8126] Object". New values are to be assigned by Standards Action [RFC8126]
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| Bit | Description | Reference | | Bit | Description | Reference |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 0-12 | Unassigned | This document | | 0-12 | Unassigned | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 13-15 | O-flag: Operational state | This document | | 13-15 | O-flag: Operational state | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
8.6. Flags in the Multipath Backup TLV 9.6. Flags in the Multipath Backup TLV
IANA is requested to create a new sub-registry to manage the Flag IANA is requested to create a new sub-registry to manage the Flag
field of the MULTIPATH-BACKUP TLV, called "Flags in MULTIPATH-BACKUP field of the MULTIPATH-BACKUP TLV, called "Flags in MULTIPATH-BACKUP
TLV". New values are to be assigned by Standards Action [RFC8126] TLV". New values are to be assigned by Standards Action [RFC8126]
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| Bit | Description | Reference | | Bit | Description | Reference |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 0-14 | Unassigned | This document | | 0-14 | Unassigned | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 15 | B-flag: Pure backup | This document | | 15 | B-flag: Pure backup | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
8.7. Flags in the Multipath Opposite Direction Path TLV 9.7. Flags in the Multipath Opposite Direction Path TLV
IANA is requested to create a new sub-registry to manage the flag IANA is requested to create a new sub-registry to manage the flag
fields of the MULTIPATH-OPPDIR-PATH TLV, called "Flags in the fields of the MULTIPATH-OPPDIR-PATH TLV, called "Flags in the
MULTIPATH-OPPDIR-PATH TLV". New values are to be assigned by MULTIPATH-OPPDIR-PATH TLV". New values are to be assigned by
Standards Action [RFC8126] Standards Action [RFC8126]
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| Bit | Description | Reference | | Bit | Description | Reference |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 0-12 | Unassigned | This document | | 0-12 | Unassigned | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 14 | L-flag: Link co-routed | This document | | 14 | L-flag: Link co-routed | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
| 15 | N-flag: Node co-routed | This document | | 15 | N-flag: Node co-routed | This document |
+------------+-----------------------------------+-----------------+ +------------+-----------------------------------+-----------------+
9. Security Considerations 10. Security Considerations
None at this time. None at this time.
10. Acknowledgement 11. Acknowledgement
Thanks to Dhruv Dhody for ideas and discussion. Thanks to Dhruv Dhody for ideas and discussion.
11. Contributors 12. Contributors
Andrew Stone Andrew Stone
Nokia Nokia
Email: andrew.stone@nokia.com Email: andrew.stone@nokia.com
12. References 13. References
12.1. Normative References 13.1. Normative References
[I-D.draft-rajagopalan-pce-pcep-color] [I-D.draft-rajagopalan-pce-pcep-color]
Rajagopalan, B., Beeram, V. P., Peng, S., Xiong, Q., Rajagopalan, B., Beeram, V. P., Peng, S., Xiong, Q.,
Koldychev, M., and G. Mishra, "Path Computation Element Koldychev, M., and G. Mishra, "Path Computation Element
Protocol(PCEP) Extension for Color", Work in Progress, Protocol(PCEP) Extension for Color", Work in Progress,
Internet-Draft, draft-rajagopalan-pce-pcep-color-01, 14 Internet-Draft, draft-rajagopalan-pce-pcep-color-01, 14
November 2021, <https://www.ietf.org/archive/id/draft- November 2021, <https://www.ietf.org/archive/id/draft-
rajagopalan-pce-pcep-color-01.txt>. rajagopalan-pce-pcep-color-01.txt>.
[I-D.ietf-pce-segment-routing-policy-cp] [I-D.ietf-pce-segment-routing-policy-cp]
skipping to change at page 21, line 12 skipping to change at page 22, line 12
Bidgoli, "PCEP extension to support Segment Routing Policy Bidgoli, "PCEP extension to support Segment Routing Policy
Candidate Paths", Work in Progress, Internet-Draft, draft- Candidate Paths", Work in Progress, Internet-Draft, draft-
ietf-pce-segment-routing-policy-cp-06, 22 October 2021, ietf-pce-segment-routing-policy-cp-06, 22 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-pce-segment- <https://www.ietf.org/archive/id/draft-ietf-pce-segment-
routing-policy-cp-06.txt>. routing-policy-cp-06.txt>.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", Work in P. Mattes, "Segment Routing Policy Architecture", Work in
Progress, Internet-Draft, draft-ietf-spring-segment- Progress, Internet-Draft, draft-ietf-spring-segment-
routing-policy-18, 17 February 2022, routing-policy-22, 22 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-spring- <https://www.ietf.org/archive/id/draft-ietf-spring-
segment-routing-policy-18.txt>. segment-routing-policy-22.txt>.
[I-D.koldychev-pce-operational] [I-D.koldychev-pce-operational]
Koldychev, M., Sivabalan, S., Peng, S., Achaval, D., and Koldychev, M., Sivabalan, S., Peng, S., Achaval, D., and
H. Kotni, "PCEP Operational Clarification", Work in H. Kotni, "PCEP Operational Clarification", Work in
Progress, Internet-Draft, draft-koldychev-pce-operational- Progress, Internet-Draft, draft-koldychev-pce-operational-
05, 19 February 2022, <https://www.ietf.org/archive/id/ 05, 19 February 2022, <https://www.ietf.org/archive/id/
draft-koldychev-pce-operational-05.txt>. draft-koldychev-pce-operational-05.txt>.
[I-D.schmutzer-pce-cs-sr-policy] [I-D.schmutzer-pce-cs-sr-policy]
Schmutzer, C., Filsfils, C., Ali, Z., and F. Clad, Schmutzer, C., Filsfils, C., Ali, Z., Clad, F., and P.
"Circuit Style Segment Routing Policies", Work in Maheshwari, "Circuit Style Segment Routing Policies", Work
Progress, Internet-Draft, draft-schmutzer-pce-cs-sr- in Progress, Internet-Draft, draft-schmutzer-pce-cs-sr-
policy-00, 30 September 2021, policy-01, 7 March 2022, <https://www.ietf.org/archive/id/
<https://www.ietf.org/archive/id/draft-schmutzer-pce-cs- draft-schmutzer-pce-cs-sr-policy-01.txt>.
sr-policy-00.txt>.
[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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
skipping to change at page 22, line 17 skipping to change at page 23, line 23
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664, Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019, DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>. <https://www.rfc-editor.org/info/rfc8664>.
12.2. Informative References 13.2. Informative References
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655, Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
 End of changes. 37 change blocks. 
167 lines changed or deleted 219 lines changed or added

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