Extension for Stateful PCE to allow Optional
Processing of PCE Communication Protocol (PCEP) ObjectsHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinac.l@huawei.comHuawei TechnologiesH1, Huawei Xiliu Beipo Village, Songshan LakeDongguanGuangdong523808Chinazhenghaomian@huawei.comCiscoslitkows.ietf@gmail.com
Routing
PCE Working GroupThis document introduces a mechanism to mark some of the Path
Computation Element (PCE) Communication Protocol (PCEP) objects as
optional during PCEP messages exchange for the Stateful PCE model to
allow relaxing some constraints during path computation and setup.
This document introduces this
relaxation to stateful PCE and updates RFC 8231. describes the Path Computation Element
Communication Protocol (PCEP) which enables the communication between a
Path Computation Client (PCC) and a Path Control Element (PCE), or
between two PCEs based on the PCE architecture .PCEP Extensions for Stateful PCE Model
describes a set of extensions to PCEP to enable active control of
Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and
Generalzied MPLS (GMPLS) tunnels. describes the
setup and teardown of PCE-initiated LSPs under the active stateful PCE
model, without the need for local configuration on the PCC, thus
allowing for dynamic control. defined the P flag (Processing-Rule) in the
Common Object Header to allow a PCC to specify in a Path Computation
Request (PCReq) message (sent to a PCE) whether the object must be taken
into account by the PCE during path computation or is optional. The I
flag (Ignore) is used by the PCE in a Path Computation Reply (PCRep)
message to indicate to a PCC whether or not an optional object was
considered by the PCE during path computation. Stateful PCE specified that the P and I flags of the PCEP objects
defined in is to be set to zero on transmission
and ignored on receipt, since they are exclusively related to path
computation requests. The behavior for P and I flag in other messages
defined in and other extension was not
specified. This document clarifies how the P and I flag could be used in
the stateful PCE model to identify optional objects in the Path
Computation State Report (PCRpt) , the Path
Computation Update Request (PCUpd) , and the LSP
Initiate Request (PCInitiate) message.This document updates with respect to usage
of the P and I flag as well as the handling of unknown objects in the
stateful PCEP message exchange.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 when, and only
when, they appear in all capitals, as shown here. describes the handling of unknown objects as
per the setting of the P flag for the PCReq message. Further, defined the usage of the LSP Error Code TLV in the
PCRpt message in response to failed LSP Update Request via the PCUpd
message (for example, due to an unsupported object/TLV).This document clarifies the procedure of marking some objects as
'optional to be processed' by the PCEP peer in the stateful PCEP
messages. Furthermore, this document updates the procedure for handling
unknown objects in the stateful PCEP messages based on the P flag.The PCRpt message is used to report the current state of an LSP. As
part of the message both the <intended-attribute-list> and
<actual-attribute-list> is encoded (see ). For example, the <intended-attribute-list>
could include the METRIC object to indicate a limiting constraint (Bound 'B'
flag set) for the Path Delay Variation metric . In some scenarios, it would be useful to state
that this limiting constraint can be relaxed by the PCE in case it
cannot find a path. Similarly in the case of an association group
such as Disjoint Association , the PCE may need to completely relax the
disjointness constraint in order to provide a path to all the LSPs
that are part of the association. In these case it would be useful to
mark the objects as 'optional' and it could be ignored by the PCEP
peer. Also, it would be useful for the PCEP speaker to learn if the
PCEP peer has relaxed the constraint and ignored the processing of the
PCEP object.Thus, this document simply clarifies, how the already existing P
and I flag in the PCEP common object header could be used during the
stateful PCEP message exchange. Further it should be noted that
similar to handling of P and I flag in , the
flag is applicable to full PCEP Object and could not be applied to the
granularity of an optional TLV encoded in the PCEP Object.A PCEP speaker indicates its ability to support the handling of the
P and I flag in the stateful PCEP message exchange during the PCEP
initialization phase, as follows. When the PCEP session is
established, a PCC sends an Open message with an OPEN object that
contains the STATEFUL-PCE-CAPABILITY TLV, as defined in . A new flag, the R (RELAX) flag, is added in this
TLV to indicate the support for relaxing the processing of some
objects via the use of the P and I flag in the PCEP common object
header.R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag
indicates that the PCEP Speaker is willing to send and receive PCEP
objects with the P and I flags in the PCEP common object header for
the stateful PCE messages. In case the bit is unset, it indicates that
the PCEP Speaker would not handle the P and I flags in the PCEP common
object header for stateful PCE messages.The R flag MUST be set by both a PCC and a PCE to indicate support
for the handling of the P and I flag in the PCEP common object header
to allow relaxing some constraints by marking objects as optional to
process. If the PCEP speaker did not set the R flag but receives PCEP
objects with P or I bit set, it MUST behave as per the processing rule
in i.e., the bits are simply ignored.The P flag in the PCRpt message allows a
PCC to specify to a PCE whether the object must be taken into
account by the PCE (during path computation, re-optimization, or
state maintenance) or is optional o process. When the P flag is set
in the PCRpt message received on a PCEP session on which R bit was
set by both peers, the object MUST be taken into account by the PCE.
Conversely, when the P flag is cleared, the object is optional and
the PCE is free to ignore it. The P flag for the mandatory objects
such as the LSP and the ERO (Explicit Route Object) object (intended path) MUST be set in
the PCRpt message. If a mandatory object is received with the P flag
set incorrectly according to the rules stated above, the receiving
peer MUST send a PCErr message with Error-Type=10 (Reception of an
invalid object) and Error-value=1 (reception of an object with P
flag not set). On a PCEP session on which R bit was set by both
peers, the PCC SHOULD set the P flag by default, unless a local
configuration or local policy indicates that some constraints
(corresponding PCEP objects) can be marked as optional and could be
ignored by the PCE.The P flag in the PCUpd message and the
PCInitiate message allows a PCE to specify
to a PCC whether the object must be taken into account by the PCC
(during path setup) or is optional to process. When the P flag is
set in the PCUpd/PCInitiate message received on a PCEP session on
which R bit was set by both peers, the object MUST be taken into
account by the PCC. Conversely, when the P flag is cleared, the
object is optional and the PCC is free to ignore it. The P flag for
the mandatory objects such as the SRP (Stateful PCE Request Parameters), the LSP and the ERO MUST be
set in the PCUpd/PCInitiate message. If a mandatory object is
received with the P flag set incorrectly according to the rules
stated above, the receiving peer MUST send a PCErr message with
Error-Type=10 (Reception of an invalid object) and Error-value=1
(reception of an object with P flag not set). By default, the PCE
SHOULD set the P flag, unless a local configuration or local policy
indicates that some constraints (corresponding PCEP objects) can be
marked as optional and could be ignored by the PCC.The I flag in the PCUpd message allows a
PCE to indicate to a PCC whether or not an optional object was
processed. The PCE MAY include the ignored optional object in its
update request and set the I flag to indicate that the optional
object was ignored. When the I flag is cleared, the PCE indicates
that the optional object was processed.Note that when a PCE is unable to find the path that meets all
the constraints as per the PCEP Object that cannot be ignored (i.e.
P flag is set), the PCUpd message MAY optionally include the PCEP
Objects that caused the path computation to fail along with the with
the empty ERO.The I flag in the PCRpt message allows a
PCC to indicate to a PCE whether or not an optional object was
processed in response to an LSP Update Request (PCUpd) or LSP
Initiate Request (PCInitiate). The PCC MAY include the ignored
optional object in its report and set the I flag to indicate that
the optional object was ignored at PCC. When the I flag is cleared,
the PCC indicates that the optional object was processed. The I flag
has no meaning if the PCRpt message is not in response to a PCUpd or
PCInitiate message (i.e. without the SRP object in the PCRpt
message).Note that when a PCC is unable to setup the path that meets all
the parameters as per the PCEP Object that cannot be ignored (i.e. P
flag is set), the PCRpt message MAY optionally include the PCEP
Objects that caused the path setup to fail along with the
LSP-ERROR-CODE TLV indicating the reason
for the failure.The I flag has no meaning in the PCinitiate message and is ignored.Delegation is an operation to grant a PCE temporary rights to
modify a subset of parameters on one or more LSPs by a PCC as
described in . Note that for the delegated
LSPs, the PCE can update and mark some objects as ignored even when
the PCC had set the P flag during delegation. Similarly, the PCE can
update and mark some object as a must to process even when the PCC had
not set the P flag during delegation.The PCC MUST acknowledge this by sending the PCRpt message with the
P flag set as per the PCE expectation for the corresponding object. In
case PCC cannot accept this, it would react as per the processing
rules of unacceptable update in .This document updates the handling of unknown objects in the
stateful PCEP messages as per the setting of the P flag in the common
object header in a similar way as , i.e. if a
PCEP speaker does not understand an object with the P flag set or
understands the object but decides to ignore the object, the entire
stateful PCEP message MUST be rejected and the PCE MUST send a PCErr
message with Error-Type="Unknown Object" or "Not supported Object"
. In case the P flag is not set, the PCEP
speaker is free to ignore the object and continue with message
processing as defined. defined LSP Error Code TLV to be carried
in PCRpt message in the LSP object to convey error information. This
document does not change that procedure.This document clarifies how the already existing P and I flag in PCEP
common object header could be used during stateful PCEP exchanges. It
updates the unknown object error handling in stateful PCEP message
exchange. These changes on their own do not add any new security
concerns. The security considerations identified in , , and continue to apply.As per , it is RECOMMENDED that these PCEP
extensions only be activated on authenticated and encrypted sessions
across PCEs and PCCs belonging to the same administrative authority,
using Transport Layer Security (TLS) as per the
recommendations and best current practices in
(unless explicitly set aside in ). defines the STATEFUL-PCE-CAPABILITY TLV;
per that RFC, IANA created a "STATEFUL-PCE-CAPABILITY TLV Flag Field"
subregistry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's
Flag field. IANA is requested to allocate a new bit in the
subregistry, as follows:[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.]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 . 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 , "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".At the time of posting the -04 version of this document, there are no
known implementations of this mechanism. It is believed that some
vendors are considering implementations, but these plans
are too vague to make any further assertions.An operator MUST be allowed to configure the capability to support
relaxation of constraints in the stateful PCEP message exchange. They
SHOULD also allow configuration of related LSP constraints (or
parameters) that are optional to process.An implementation SHOULD allow the operator to view the capability
defined in this document. To serve this purpose, the PCEP YANG module
could be extended in the
future.Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in .Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in .Mechanisms defined in this document do not imply any new
requirements on other protocols.Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in .Thanks to Jonathan Hardwick for discussion and suggestions around
this draft.Thanks to Oscar Gonzalez de Dios and Mike Koldychev for the review
comments.