The only reasons to mark the constraints in the PC reply IMO are:
a) for a mandatory constraint either when it was not
recognized or could not
be otherwise supported (e.g. an unknown color was specified)
b) for an optional constraint when it was removed according
to a signaled or
policed constraint relaxation strategy which made the computation
successful.
Regards,
Igor
So, I recommend to have two flags (say, P and I). One of them
should be used to mark mandatory constraints, while another -
optional constraints.
As already commented to Dimitri, this is related to
constraint relaxation
and is completely beyond the scope of this document as agreed
one year ago
on this list. There are various solutions for constraints
relaxation that
need to be discussed. By the way it could work as is by sending two
requests, one with mandatory constraints and the other with
all (mandatory +
optional) constraints...
Recommend to make an assumption that PCE will run path
computation at most two times:
We will never make such recommendation, this is definitely a local
implementation issue.
Regards,
JL
1) trying to accommodate all constraints;
2) in case 1) fails, removing all optional constraints
PCE should return:
a) successful response without flags when 1) succeeds;
b) successful response with flag I when 2) succeeds;
3) negative response with no flags when 2 fails.
Igor
----- Original Message -----
From: "LE ROUX Jean-Louis RD-CORE-LAN"
<[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, July 14, 2006 10:46 AM
Subject: RE: [Pce] P & I flags
Hi Dimitri,
-----Message d'origine-----
De : dimitri papadimitriou [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 14 juillet 2006 15:44
À : [EMAIL PROTECTED]
Objet : [Pce] P & I flags
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
As clearly pointed out in the same setion of the draft, if
a mandatory
constraint cannot be handled the PCE replies with PCErr message
"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".
If the PCE can handle all mandatory constraints it replies
with a PCRep
message (either positive or negative if there is no path),
else it sends a
PCErr message.
Hence the PCC knows whether mandatory constraints have 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 ?
I don't catch your point, the PCC may want to know the
constraints that were
not taken into account during path computation, this sounds
quite important
isn'it?
there are so
many things that the PCE has not taken into account during
computation so why bother ?
Hum I don't follow you here "there are so many things...",
What do you mean?
it is imho
more important to include the mandatory object not taken
into account
If a mandatory object is not taken into account, you cannot
compute the path
and you send an error message. I agree with you that this
would be useful to
include within the PCErr the set of objects not supported,
this can be
clarified in next revision.
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;
OK, if you mean that we should include the unsupported
object(s) within the
PCErr, then we are in sync
Thanks for the comment
Regards
JL
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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
