the comments around the P and I flags are
o) we have two levels of optionality in listing the protocol object and
usage level of the protocol object - however it is much more appropriate
to be sure that mandatory constraints have been taken rather than having
the optional having been taken into account
P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify
in a PCReq message sent to a PCE whether the object must be taken
into account by the PCE during path computation or is just optional.
When the P flag is set, 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 if not supported.
o) on the I flag issue is identical why include an object which has not
considered during computation ? there are so many things that the PCE
has not taken into account during computation so why bother ? it is imho
more important to include the mandatory object not taken into account
I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep
message to indicate to a PCC whether or not an optional object was
processed. The PCE MAY include the ignored optional object in its
reply and set the I flag to indicate that the optional object was
ignored during path computation. When the I flag is cleared, the PCE
indicates that the optional object was processed during the path
computation. The setting of the I flag for optional objects is
purely indicative and optional. The I flag MUST be cleared if the P
flag is set.
o) the result of all these flags is that a PCC can be wrapping around
unknown constraints create processing churn on the PCE;
If the PCE does not understand an object with the P Flag set or
understands the object but decides to ignore the object, the entire
PCEP message MUST be rejected and the PCE MUST send a PCErr message
with Error-Type="Unknown Object" or "Not supported Object".
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
