Hi,
So I think that we're now all in sync wrt to the P & I bits semantic.
* The P flag is used by a PCC to indicate to the PCE that a
constraint X MUST NOT be ignored. Consequently, if the PCE does not
support/understand such constraint X, it MUST send a PCErr (as
clearly stated in the document).
* The I flag is used by the PCE to indicate to the PCC whether a
constraint Y marked as optional in the request has been taken into
account, which can be very useful in several cases.
Now, the issue discussed in this thread was related to constraint
relaxation, which is an important topic and I've personally been
supporting such feature for a while but there was no consensus on the
list on this topic (see the archives), thus, as pointed out by JL,
this was left out of the main PCEP spec. Of course, feel free to
continue some discussion on the list on this topic.
Thanks.
JP.
On Jul 16, 2006, at 7:27 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote:
Hi Dimitri,
-----Message d'origine-----
De : dimitri papadimitriou [mailto:[EMAIL PROTECTED]
Envoyé : lundi 17 juillet 2006 00:04
À : LE ROUX Jean-Louis RD-CORE-LAN
Cc : [EMAIL PROTECTED]; Igor Bryskin; [EMAIL PROTECTED]
Objet : Re: [Pce] P & I flags
hi j-l
LE ROUX Jean-Louis RD-CORE-LAN wrote:
Hi Dimitri,
-----Message d'origine----- De : dimitri papadimitriou
[mailto:[EMAIL PROTECTED] Envoyé : dimanche 16 juillet 2006
18:25 À : Igor Bryskin Cc : LE ROUX Jean-Louis RD-CORE-LAN;
[EMAIL PROTECTED]; [EMAIL PROTECTED] Objet : Re:
[Pce] P &
I flags
igor, j-l
to indicate optional/non-optional you need one flag like i
indicate
in my reply to j-l - let's say the P flag
NO, why do you want to change the semantic if the P flag? this
semantic is required...
call it I flag if you want the point is that the Error should
be generated once an object (from its class or type) is not
recognized
Humm no, I flag is already used!
Call it O flag if you like
if you have that a too high rejection rate could result from
optional constraints such behaviour should be inferred by no
further looking into the object
in the reply - where you have a third level of indirection
since you
can send a positive or a negative answer you can have one of the
following
a) positive response with both optional and non-optional
b) positive
response with non-optional only c) negative response
however, as far as my reading goes, ALL non-optional
constraints MUST
be taken into account while SOME of the optional
constraints MAY be
taken into account
No, all recognized and supported constraints MUST be taken into
account during path computation, whatever the P flag value.
The P flag
simply indicates what to do when a constraint is not
recognized/unsupported.
again call it I flag, point remains, a negative answer shall
come only from not finding a result from mandatory constraints
Dimitri, please see my previous answer. I understand the semantic
you define, it was discussed one year ago as part of a constraint
relaxation thread (less constrained path), and the result of this
thread was that there there was no consensus, some people were
against, hence we removed the requirement from the generic PCECP
req id, and also we removed text on less constrained path from the
PCEP spec, and decided to address it latter.
This should be defined in a separate ID once the requirement is
clearly expressed.
By the way there are various options for handling optional
constraints and more generally constraint relaxation. For instance
the PCC may also send two requests, one with only mandatory
constraints and another with optional constraints...
and a positive result may include more than the set of
mandatory constraints
Ah, this is interesting...and what sub-set of optional constraints
is selected if not all optional constaints can be satisfied? Again
we are discussing constraint relaxation here and this is beyond the
scope of this doc...
the fact that an error is issued should then be the result of
the non-support of a mandatory constraint
Yes, indeed this is current P flag processing
all together this makes one flag - and this only because
there is a difference between optional object support and
optional processing
hence one could consider that list in the reply corresponds to the
list of considered constraints and since the requestor knows these
are optional or not there is no need for a second flag - this
prevents back tracking of optional information - and restrict
confirmation to the mandatory constraints
ps: are you serious when considering a message length of 2^32 ?
Yes, 2^16 may not be enought, think about an NMS that would send a
request for tens of thousands of LSPs.
what does make the NMS PCC different from an LSR ?
Please keep it simple, you were asking why do we need 2^32, and
I answered that 2^16 may not be enough, and I took, as pure
illustration, the example of an NMS acting as PCC, and sending a
PCReq for a synchronized path computation of tens of K LSPs, ie a
PCReq with tens of K requests (I simply took the example of NMS
PCC, as an NMS is likely to request synchronized path computation
of many more LSPs, than an LSR would do).
i think
there is a difference between the set of command issued to
the NMS and the resulting set of PCC requests an NMS will generate
Who says the contrary? And what is the point here?
Thanks,
JL
thanks,
- dimitri.
Thanks,
JL
thanks, - dimitri.
Igor Bryskin wrote:
Hi JL,
I have a question. Suppose, a path computation request has
two constraints:
link colors and link bandwidth. Suppose the path
computation fails.
The question is how the PCE can figure out what is the
reason of this
computation failure? As an implementer of a Path
Computation Engine I
always found it a difficult problem. Normally, presented
with a path
computation request with link type constraints as in the
example I am
describing, a PCE would prune out the arcs form the
network graph
associated with links that do not satisfy at least one of the
constraints, and after that run some algorithm. If the
algorithm fails
the only thing is clear that there are no links with
proper colors
that have enough bandwidth, that is, entire set of
constraints cannot
be satisfied. But it is impossible to say which constraint in
particular has caused the failure. Even if you start removing
constraints one by one and rerunning the algorithm (which
would be
very unpractical to do), you will find out that it does not
help. The path computation of the example may succeed in
both these
iterations because:
a) there are links with proper colors; b) there are links with
enough bandwidth.
The bottom line is that path computation fails because of
the entire
set of constraints rather than because of one or several of
them, and
it is unrealistic to think that PCE in its negative reply
would mark
constraints which cause the failure.
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.
Recommend to make an assumption that PCE will run path
computation at
most two times:
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
.
.
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
