> This is start of a two week poll on making
draft-litkowski-pce-association-diversity-01 a PCE working group document.
Hi,
I support the adoption of this draft, because it is clear that this
function needs to be provided. But my review throws up a few things that
should be worked on. None of my issues needs hold up adoption of the
document so long as we can agree to look at them as the work goes
forward. Note that a few of my comments might lead to reducing the
available function, and other might suggest using existing mechanisms
rather than adding new features.
Thanks,
Adrian
===
Could the Abstract make it a little clearer whether this signaling is
to request a PCE to compute diverse group of LSPs, request that a PCE
compute the path of an LSP that is diverse from some other group of
existing LSPs, indicate to a PCC that it must set up a group of diverse
LSPs, indicate to a PCC that an LSP that is to be set up must be diverse
from some other group of LSPs, or report from a PCC to a PCE that a
group of LSPs are diverse.
In other words, give some indication of what the feature is for.
---
Similarly, the Introduction needs to give some more clue. When it says
"used to signal" it fails to indicate who signals to whom and at what
stage in the process.
---
The document needs to make it clear why the SVEC object is not a
suitable approach. I think this will follow from the previous two points
but it is important to mention SVEC and clarify the relationship to that
object which has previously been used to enable "related" computations.
---
The caption to Figure 1 might better read...
Figure 1 - Disjoint paths with different head-ends and tail-ends
---
"PCInit" should, I think, be "PCInitiate".
---
I want to note that diverse paths can often only be successfully computed
if they are computed as a batch. Therefore, a mechanism that allows one
PCC to request an LSP "disjoint from everything else in this group" is
flawed unless the PCE has some way to know the whole of the group.
Otherwise, the PCE will compute the path of the LSP as the CSPF because
the group is empty and will later get a second request ("compute a
second LSP disjoint from the group") that it might not be able to
satisfy. This problem is compounded by increasing the size of the
group without the PCE even knowing whether it has information about the
whole group.
That fact does not detract from the protocol mechanism, but does, I
think, mean that the use case of two or more separate PCCs (LERs)
requesting LSPs to be diverse from the group is either more complex (it
could use rerouting to achieve the results after performing a "global
concurrent reoptimization", or it could have additional protocol
mechanisms to scope the group), or subject to failures or suboptimal
results.
Note that SVEC, SVEC list, and GCO were previous attempts to address
this specific problem. Just as OFs were previous ways of expressing the
computation result desired.
---
In 4.1 you have...
A disjoint group can have two or more LSPs. But a PCE may be limited
in how many LSPs it can take into account when computing
disjointness: usually PCEs are able to compute a pair of disjoint
paths. If a PCE receives more LSPs in the group than it can handle
in its computation algorithm, it SHOULD apply disjointness
computation to only a subset of LSPs in the group. The subset of
disjoint LSPs will be decided by the implementation.
I think it would be good to strike ": usually PCEs are able to compute a
pair of disjoint paths". That is an implementation detail and actually
has no bearing on the protocol mechanism you define. That is, even if a
PCE can only compute one path, the "subset" of one will work.
(Personally, I think PCEs should be able to handle arbitrary groups, but
I understand some algorithms differ.)
What is missing, however, is how the PCE in this case reports that it
did not perform the requested function, but still supplied paths. That
is, the paths are not what was requested, but are supplied as though
they were. I believe the PCE MUST report this fact so that the PCC can
decide whether or not to use the paths.
---
Similarly
Associating a particular LSP to multiple disjoint groups is
authorized from a protocol perspective, however there is no insurance
that the PCE will be able to compute properly the multi-disjointness
constraint.
So the PCE that cannot handle this case needs to have a formal response
that lets the PCC know that something undesired has happened.
---
What is the interaction of the P flag and the OF?
If the OF says, for example, use the least load path, and yet the P flag
is set, what should the PCE do?
Perhaps this is what your text is trying to talk about.
Maybe then, this isn't specifically the "shortest path" flag, but is
more a "satisfy all constraints and objective functions first without
considering the diversity constraint" flag.
Even so, you should talk about what happens if there are two paths that
equally satisfy the other constraints and OFs (consider ECMP) but where
the use of one allows diversity, and the use of the other does not.
(Hint: it is very easy to draw networks where this happens.)
---
How does the strictness requirement interact with the case (above) of
not being able to compute for the full set at once?
---
Suppose I ask for node disjoint but am willing to settle for link
disjoint. How do I express this?
It would be {node, but not strict} + {link, strict}
But I see no way to express this.
---
If I say "not strict" can a PCE simply ignore me, or does it "do its
best"? And do you define "best" for a group of LSPs? Fewest LSPs that
are disjoint? Fewest points of non-disjointness across the group?
Sounds like a few new OFs to me.
And how does the PCE report what is not quite as requested?
---
I think you have a new security consideration to include. There needs to
be some authorisation associated with a group. Otherwise a "rogue" PCC
can sabotage someone else's group by adding to it a strict request for
an LSP that cannot possibly be disjoint. This would, as I understand it
cause the whole group to be in error.
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
