draft-ietf-pce-association-diversity-09.txt | draft-ietf-pce-association-diversity-10.txt | |||
---|---|---|---|---|
PCE Working Group S. Litkowski | PCE Working Group S. Litkowski | |||
Internet-Draft Orange | Internet-Draft Orange | |||
Intended status: Standards Track S. Sivabalan | Intended status: Standards Track S. Sivabalan | |||
Expires: February 17, 2020 Cisco Systems, Inc. | Expires: March 2, 2020 Cisco Systems, Inc. | |||
C. Barth | C. Barth | |||
Juniper Networks | Juniper Networks | |||
M. Negi | M. Negi | |||
Huawei Technologies | Huawei Technologies | |||
August 16, 2019 | August 30, 2019 | |||
Path Computation Element Communication Protocol (PCEP) Extension for LSP | Path Computation Element Communication Protocol (PCEP) Extension for LSP | |||
Diversity Constraint Signaling | Diversity Constraint Signaling | |||
draft-ietf-pce-association-diversity-09 | draft-ietf-pce-association-diversity-10 | |||
Abstract | Abstract | |||
This document introduces a simple mechanism to associate a group of | This document introduces a simple mechanism to associate a group of | |||
Label Switched Paths (LSPs) via an extension to the Path Computation | Label Switched Paths (LSPs) via an extension to the Path Computation | |||
Element (PCE) communication Protocol (PCEP) with the purpose of | Element (PCE) communication Protocol (PCEP) with the purpose of | |||
computing diverse paths for those LSPs. The proposed extension | computing diverse paths for those LSPs. The proposed extension | |||
allows a Path Computation Client (PCC) to advertise to a PCE that a | allows a Path Computation Client (PCC) to advertise to a PCE that a | |||
particular LSP belongs to a disjoint-group, thus the PCE knows that | particular LSP belongs to a disjoint-group, thus the PCE knows that | |||
the LSPs in the same group need to be disjoint from each other. | the LSPs in the same group need to be disjoint from each other. | |||
skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
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 February 17, 2020. | This Internet-Draft will expire on March 2, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 15, line 23 ¶ | skipping to change at page 15, line 23 ¶ | |||
implementation should aim to select a path that allows disjointness. | implementation should aim to select a path that allows disjointness. | |||
5.6. Disjointness Computation Issues | 5.6. Disjointness Computation Issues | |||
There may be some cases where the PCE is not able to provide a set of | There may be some cases where the PCE is not able to provide a set of | |||
disjoint paths for one or more LSPs in the association. | disjoint paths for one or more LSPs in the association. | |||
When the T flag is set (Strict disjointness requested), if | When the T flag is set (Strict disjointness requested), if | |||
disjointness cannot be ensured for one or more LSPs, the PCE MUST | disjointness cannot be ensured for one or more LSPs, the PCE MUST | |||
reply to a Path Computation Request (PCReq) with a Path Computation | reply to a Path Computation Request (PCReq) with a Path Computation | |||
Reply (PCRep) message containing a NO-PATH object. In case of other | Reply (PCRep) message containing a NO-PATH object. In case of PCRpt | |||
PCEP message, the PCE MUST return a PCErr message with Error-Type 26 | message, the PCE MUST return a PCErr message with Error-Type 26 | |||
"Association Error" and Error-Value 7 "Cannot join the association | "Association Error" and Error-Value 7 "Cannot join the association | |||
group". Also, in case of network event leading to an impossible | group". Also, in case of network event leading to an impossible | |||
strict disjointness, the PCE MUST send a PCUpd message containing an | strict disjointness, the PCE MUST send a PCUpd message containing an | |||
empty ERO to the corresponding PCCs. In addition to the empty ERO | empty ERO to the corresponding PCCs. In addition to the empty ERO | |||
Object, the PCE MAY add the NO-PATH-VECTOR TLV ([RFC5440]) in the LSP | Object, the PCE MAY add the NO-PATH-VECTOR TLV ([RFC5440]) in the LSP | |||
Object. | Object. | |||
This document adds new bits in the NO-PATH-VECTOR TLV: | This document adds new bits in the NO-PATH-VECTOR TLV: | |||
bit "TBD7": when set, the PCE indicates that it could not find a | bit "TBD7": when set, the PCE indicates that it could not find a | |||
disjoint path for this LSP. | disjoint path for this LSP. | |||
bit "TBD8": when set, the PCE indicates that it does not support | bit "TBD8": when set, the PCE indicates that it does not support | |||
the requested disjointness computation. | the requested disjointness computation. | |||
When the T flag is unset, the PCE is allowed to relax disjointness by | When the T flag is unset, the PCE is allowed to relax disjointness by | |||
either applying a requested objective function (Section 5.4) if | applying a requested objective function (Section 5.4) if specified. | |||
specified. Otherwise the PCE is allowed to reduce the required level | Otherwise, if no objective function is specified, the PCE is allowed | |||
of disjointness (as it deems fit). The actual level of disjointness | to reduce the required level of disjointness as it deems fit. The | |||
computed by the PCE can be reported through the DISJOINTNESS-STATUS- | actual level of disjointness computed by the PCE can be reported | |||
TLV by setting the appropriate flags in the TLV. While the | through the DISJOINTNESS-STATUS-TLV by setting the appropriate flags | |||
DISJOINTNESS-CONFIGURATION-TLV defines the expected level of | in the TLV. While the DISJOINTNESS-CONFIGURATION-TLV defines the | |||
disjointness required by configuration, the DISJOINTNESS-STATUS-TLV | expected level of disjointness required by configuration, the | |||
defines the actual level of disjointness computed. | DISJOINTNESS-STATUS-TLV defines the actual level of disjointness | |||
computed. | ||||
There are some cases where the PCE may need to completely relax the | There are some cases where the PCE may need to completely relax the | |||
disjointness constraint in order to provide a path to all the LSPs | disjointness constraint in order to provide a path to all the LSPs | |||
that are part of the association. A mechanism that allows the PCE to | that are part of the association. A mechanism that allows the PCE to | |||
fully relax a constraint is considered by the authors as more global | fully relax a constraint is considered by the authors as more global | |||
to PCEP rather than linked to the disjointness use case. As a | to PCEP rather than linked to the disjointness use case. As a | |||
consequence, it is considered as out of scope of the document. | consequence, it is considered as out of scope of the document. | |||
All LSPs in a particular disjoint group MUST use the same combination | All LSPs in a particular disjoint group MUST use the same combination | |||
of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCEP | of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCEP | |||
End of changes. 6 change blocks. | ||||
14 lines changed or deleted | 15 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |